chore(jsref): change Proxy/handler group to Proxy/Proxy

[caugner]

Description

Drop the Proxy/Proxy entry from the JS reference sidebar's Proxy related-pages group (it is already listed as the constructor), and remove the now-dead Proxy/Proxy → Proxy/handler remap in slug_to_object_name.

Motivation

The Proxy/handler page never existed — only a redirect to Proxy/Proxy. The sidebar was emitting a "Related pages" link to /Proxy/Proxy labelled Proxy/handler, producing 16 templ-redirected-link flaws across the Proxy reference pages. Proxy/Proxy is already shown on the Proxy sidebar as the constructor, so listing it again under "Related pages" is redundant.

Additional details

Before (rendered Proxy sidebar tail):

…<li class="section"><span>Related pages</span></li><li class="section"><a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/Proxy"><code>Proxy/handler</code></a></li>

After: the "Related pages" entry is gone; the constructor link to Proxy/Proxy remains. Local build of Proxy/index.md drops from 1 issue to 0.

Screenshots

Before	After

Related issues and pull requests

Fixes #706

[github-actions]

1467594 was deployed to: https://rari-pr707.review.mdn.allizom.net/

[caugner]

Took: 17.073273883s - 0 changes in 0 of 14415 files (0.0%)

I realize now that sidebar changes are excluded by default:

rari/crates/diff-test/src/main.rs

Line 248 in d5b3680

|| key == "doc.sidebarHTML" && !args.sidebars

[LeoMcA]

This means we lose the instance sidebar on /en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/Proxy:

prod:

this pr (checked out locally):

[caugner]

Good catch, I'll open a new PR with a different approach.

[caugner]

Good catch, I'll open a new PR with a different approach.

I had considered keeping Proxy/handler without linking, but since it is actually used in place of Proxy/Proxy, I think it makes more sense to keep the Proxy/Proxy grouping. Maybe rather the short-titles of those handler pages should include handler. to avoid confusion.

[caugner]

Maybe I should have started with this:

@mdn/javascript Are you able to explain if Proxy/handler is intentionally used as the group name? Would it be okay to change the link text to Proxy/Proxy instead, and possibly update the short-title of those handler pages to include the handler. prefix?

PS: Alternatively, it should be possible to have a Proxy/Proxy/handler intermediate page, which could be listed as a Related page for Proxy, and have its instance methods below it.

[Josh-Cena]

It was just a placeholder identifier that's not supposed to map to any real page. I don't have strong opinions about how it's implemented, but these pages should show up as obviously separate from the Proxy group itself.

[caugner]

these pages should show up as obviously separate from the Proxy group itself.

Currently, the slug structure suggests that these belong to the Proxy/Proxy group. Would that be acceptable?

Having an unlinked Proxy/handler group would mean it cannot be linked under "Related pages", and it would be slightly more work to support this in the macro.

[Josh-Cena]

I would not want the status that these are two sidebars, and that they are cross-linked with "Related pages", to change. Alternatively, I could be okay if these pages are integrated into the main Proxy sidebar as subpages of the Proxy() constructor.

[caugner]

Thanks @Josh-Cena, I opened #728 to use a single sidebar for Proxy/*, grouping the handler trap pages as "Handler methods".

Closing this in favor of that PR.