Add a function to get sidebar data

[LuHugo]

What version of starlight are you using?

0.11.2

What is your idea?

The ability to override default components in the current version is great, but the sidebar data is still a bit annoying. There is no function to query the sidebar. It would be great if you could add a query for sidebar based on slug or path. For example: getSidebarBySlug or getSidebarByPath.

const currentSidebar = getSidebarBySlug(slug)

// or
const currentSidebar = getSidebarByPath(path)

Or add an identification field (such as path or directory ) to the group type data of the returned sidebar data to filter the sidebar data to be displayed when rewriting the component.

const sidebarData = [
  {
    type: 'link',
    label: 'Welcome to Starlight',
    href: '/',
    isCurrent: false,
    badge: undefined,
    attrs: {}
  },
  {
    type: 'group',
    label: 'reference',
    path: '/reference/',
    entries: [ [Object], [Object] ],
    collapsed: false
  },
 {
    type: 'group',
    label: 'getting start',
    path: '/guide/gettingstart/',
    entries: [ [Object], [Object] ],
    collapsed: false
  }
];

// Filter sidebar data
const currentSidebar = sidebarData.filter(...)

The above method is obviously not perfect. There may be a better way to filter out the required sidebar data.

Why is this feature necessary?

Display different sidebars according to different routes

Do you have examples of this feature in other projects?

No response

Participation

• I am willing to submit a pull request for this feature.

[delucis]

The .filter() version should already be possible by filtering items based on their children.

For example, this would find all the groups that contain links to /reference/* pages:

sidebar.filter((item) => {
	return (
		item.type === 'group' &&
		item.entries.some(
			(subitem) => subitem.type === 'link' && subitem.href.startsWith('/reference/')
		)
	);
});

[LuHugo]

Yes, the current version can filter. Currently, I use a loop to add the path attribute to all groups, and then filter out the data based on the current route. However, if the group is nested too deeply or there are too many options, it may affect the page rendering speed. . Therefore, I hope there is an implementation that can simply obtain the sidebar data under the current route.

[delucis]

I think anything we build would be doing the same recursive loops so wouldn’t improve the performance?

With your getSidebarBySlug(slug) idea how exactly does that work/what does it do?

[LuHugo]

Yes, recursive loops should be unavoidable in the current version. Maybe we can start when the data is generated. For example, all groups of data are flattened into an array, and each group has a path field. Then we can filter out the group data that matches the path field based on the current navigation of the web page.

When I gave these two examples, I thought the code logic of getSidebarBySlug and getSidebarByPath should be the same. The path field of group data in the sidebar can be matched based on the incoming path or slug.

This is the simplest way I can think of at this stage. Maybe a better way is to start with configuration.

[LuHugo]

After I ran the build, I looked at the generated page code in the dist folder. The filtered sidebar has been generated. The sidebar filtering is not performed when the page is displayed, so now the recursive loop filtering process for the sidebar is performed. Logic has no performance impact on the display of the page. I know I completely misunderstood.

[HiDeoo]

As filtering is already possible using the approach mentioned by Chris and the performance issue was a misunderstanding, I will close this discussion.