feat: Sidebar enhancements

[canerakdas]

Description

With this PR, the links in the Sidebar have been grouped to make it easier for devs to find the content they are looking for.

Additionally, the version select has been changed from the inline variant to the default version. As part of this update, the heights of the selects and the ToC on mobile resolutions have also been aligned to maintain visual consistency

Validation

Before / After

---

---

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
api-docs-tooling	Ready	Preview	Mar 5, 2026 4:31pm

[avivkeller]

While I like the idea, I have two concerns:

1. What about non-core projects? These files won't be defined.
2. What happens if one of these files has a different path of a file is added.

IMO it makes more sense to, in the future, define a "category" in the YAML metadata of a file, and use that category here.

[Copilot]

Pull request overview

This PR enhances the sidebar by grouping navigation links into logical categories (e.g., "Getting Started", "Networking & Protocols") instead of a single flat list, and updates the version select from the inline variant to the default variant for visual consistency.

Changes:

• New SIDEBAR_GROUPS constant defining categorized page groupings, with uncategorized pages falling back to "Other"
• buildSideBarGroups function added to map flat docPages into grouped sidebar navigation
• CSS override to remove the minimum width on the select component in the sidebar

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/generators/web/ui/constants.mjs	Adds SIDEBAR_GROUPS array defining navigation group names and their associated page URLs
src/generators/web/ui/components/SideBar/index.jsx	Imports SIDEBAR_GROUPS, adds buildSideBarGroups helper, replaces flat group with grouped output, and removes inline prop from Select
src/generators/web/ui/index.css	Adds a CSS rule to reset the min-width on the version select's combobox button

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[avivkeller]

It's also worth noting that having markdown files supply their own categories will be beneficial for the learn content, which has different categories, and will be processed in doc-kit eventually (once doc kit supports categories + authors)

[canerakdas]

1. What about non-core projects? These files won't be defined.

All files will be listed under "Other" in such cases

2. What happens if one of these files has a different path of a file is added.

If the file added or the file is not located here, it will still be listed under "Other"

It's also worth noting that having markdown files supply their own categories will be beneficial for the learn content, which has different categories, and will be processed in doc-kit eventually (once doc kit supports categories + authors)

I think grouping things this way makes the most sense.

From the PR side, I can either remove the category creation part and keep other minor changes, or we can mark it as deprecated and keep the feature during a transition period, IDK

I think we might also need this grouping for index.html as well

[avivkeller]

From the PR side, I can either remove the category creation part and keep other minor changes, or we can mark it as deprecated and keep the feature during a transition period, IDK

How about we do this transition period you mentioned, like we did for the type map.

For now, while the documentation is changing, we use this, but if the documentation provides its category via YAML metadata, we use that? That way, this both satisfies the current documentation, and the future learn content?

[avivkeller]

e.g.

The YAML metadata in a given file can have a category="My Category"

[avivkeller]

Which means we build the groups in jsx-ast, and pass them in place of docPages.