Add link to filter page for JS

[HazAT]

Add this page https://docs.sentry.io/platforms/javascript/configuration/filtering/#decluttering-sentry

to here

[getsantry[bot]]

Routing to @getsentry/product-owners-docs for triage ⏲️

[natikgadzhi]

Looks like the Next Pages block is rendered with <PageGrid nextPages?:boolean, exclude?: string[], header?: string/>, which takes all children pages of the current page and renders that list.

This thing already supports excludes — we can add inclusion support, and pass the link as included for the JavaScript platform page.

Problem is, JavaScript platform page is inherited, so we can't just slam it in there. Propagating this as a config value for the platform (hey, include these links in the "next steps" on the platform page) also seems like an overkill.

Perhaps we could make a page alias so that it sits under JavaScript and shows up in the list of pages?

[shanamatthews]

Hey @natikgadzhi -

We actually hate the PageGrid component - who wants to see the sidebar re-listed as next steps? The "fix" for this one will probably just be to get rid of it and manually add & populate a next steps section with just markdown.

[natikgadzhi]

The "fix" for this one will probably just be to get rid of it and manually add & populate a next steps section with just markdown.

We could do it in two ways:

• We could add another config value to a platform config.yml or front matter, name it nextStepsLinks and make it an array of arbitrary links.

  If it's empty, render the existing <PageGrid />.

  The neat part here is that we can make this change in platforms/common/index.mdx, and all platforms that use inherited template will pick it up — we will just need to add the config key to them.

• Or we could make a separate platforms/javascript/index.mdx, similarly to #8331 and #8332, and just add the list of custom links in that page markup, instead of using PageGrid just there.

  I don't know if that's the path that the team wants to take yet — @stephanie-anderson seems to work on that approach. I'm cautious of doing one-off changes like this issue fix specifically, because it might be confusing to maintain in the future.

  As of today, the PHP and Rust templates, for example, already differ from the inherited one — they render the list of supported frameworks inline (see #6977), but the inherited common template only renders an alert directing users to take a look at the sidebar.

What's the best approach here?

[shanamatthews]

I was imagining something like option 2, since I've been influenced by Stephanie's thinking, however option 1 sounds great.

If you have time to work on this, I think pursuing option 1 would be my preference!

[natikgadzhi]

Sounds good! I'll spike on approach 1, but if we end up not merging it, or changing course — no hard feelings, too.

[a-hariti]

maybe use something like this in the yaml file of the parent page:

next_steps:
  - child-one
  - child-two
  - ../sibling/child??