When the sidebars are collapsed (or uncollapsed), their state is not saved like a toggle, which means that these sections will be collapsed (or uncollapsed) again if you go to pages outside the section in question.
Desired Behavior
The sidebar collapse behaviour should be more like a toggle, remembering the state set by one user even if the user navigates to pages outside that section.
Additional Context
Anyways, this seems to be default Starlight's configuration: the sidebar remains expanded if the user is on a page within the expanded tree; if not, the sidebar gets collapsed, allowing the user to focus on a clear structure.
If we really feel the need to have the sidebar acting like a toggle, we will need to have to implement a state management for the sidebar.
Potentially, a quite naive (but also perhaps the simplest) implementation would be to append a class name to the expanded list(s) and tweak the SidebarSublist.astro component to take into account that.
Anyways, we need to understand if there is a solid reason to do so. Overriding built-in components and implementing custom business logic makes the codebase more bugs-prone, also potentially harder to maintain.
When the sidebars are collapsed (or uncollapsed), their state is not saved like a toggle, which means that these sections will be collapsed (or uncollapsed) again if you go to pages outside the section in question.
Desired Behavior
The sidebar collapse behaviour should be more like a toggle, remembering the state set by one user even if the user navigates to pages outside that section.
Additional Context
Anyways, this seems to be default Starlight's configuration: the sidebar remains expanded if the user is on a page within the expanded tree; if not, the sidebar gets collapsed, allowing the user to focus on a clear structure.
If we really feel the need to have the sidebar acting like a toggle, we will need to have to implement a state management for the sidebar.
Potentially, a quite naive (but also perhaps the simplest) implementation would be to append a class name to the expanded list(s) and tweak the
SidebarSublist.astrocomponent to take into account that.Anyways, we need to understand if there is a solid reason to do so. Overriding built-in components and implementing custom business logic makes the codebase more bugs-prone, also potentially harder to maintain.