Maintain prev/next links while having hidden: false

[simonhyll]

What version of starlight are you using?

0.7.3

What is your idea?

Make the hidden attribute in a pages sidebar configuration not disable its prev/next links, hidden should just hide the page from the sidebar since we already have the prev and next attributes for disabling those.

Why is this feature necessary?

I have a lot of pages of varying folder depths and use autogenerate to create the sidebar configuration. This works great for any pages that show up in the sidebar, however, there are a bunch of pages I deliberately don't want showing up in the sidebar to keep it overviewable. To navigate to hidden pages you enter an overview page instead with collections of LinkCards on them. This creates a much nicer more minimalistic sidebar, the only issue is that since they are marked as hidden the prev/next links no longer get generated for them, so you really do have to click the LinkCards to navigate to them.

This means that the only current solution for me to hide pages from the sidebar while maintaining the prev/next links is to handle them manually, which is of course not a scaleable solution at all.

Then of course there's a related issue that will arise from my solution to the problem, namely that the prev/next links will not be based on the order that the pages appear in the overview page. One solution to that might be by re-using the order attribute to determine where they end up, though that again isn't the most scaleable solution. The optimal solution would be some manner of scraping for links in the parent page to determine the order in which the pages appear.

Do you have examples of this feature in other projects?

No response

Participation

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

[simonhyll]

Side note, part of the reason this is desired for me in the first place is because I have a little script set up for navigating the pages using the arrow keys, which depends on the existence of the prev/next buttons.

[simonhyll]

In case this causes too many issues it would also be acceptable to just have to specify prev: true and next: true on all pages where they should be kept despite being marked hidden: true. That way current behavior where having hidden: true removing all the prev/next links can be preserved but still offers the option of easy maintenance when you wanna preserve prev/next

[delucis]

Thanks for the feature request @simonhyll. This does seem to be a pretty tricky one. My concern here is probably how it introduces quite a bit of additional complexity when thinking about how these features work.

Currently, you generate a sidebar and prev/next arrows align with that 1:1 unless a page provides explicit overrides.

With this proposed model, we'd introduce a behaviour where one sidebar option — hidden — has an impact on the sidebar but not on prev/next links, effectively introducing a "shadow" sidebar that we never see, but that is used for deciding what pages to use for prev/next.

That kind of complexity seems pretty likely to lead to confusion for users because you're asking them to keep in their head what an entire additional sidebar might look like, made worse by the fact you need to go check a bunch of individual files to actually work out what's going on.

Your idea of a boolean toggle to opt in to this, sounds a bit better, but does still suffer from some of this mental overhead.

Given you still feel this might not get ordering right, I wonder if specifying prev/next overrides explicitly as is already supported might not be better? Another option we could consider if that feels a bit verbose, would be to allow a reference by ID in that field, e.g. prev: path/to/page.md. Astro knows how to set up relations like that, so could be a good solution to keeping things terse while avoiding the confusing implicit behaviour of a "shadow" sidebar. Does that sound like it might solve your use case at least somewhat satisfactorily?

[simonhyll]

prev: path/to/page.md wouldn't change much in my case because it'd still involve a lot of manual labour making sure the pages point to their prev/next pages properly. For my use-case I'd still have to look into writing a script that does it for me automagically. For a small project with just a couple hidden pages it's fine, but when you get a couple dozen pages in there it starts to get incredibly tedious to manually sit and fix the flow of pages as you start to move them around even just a tiny bit.

Any solution that's based on manually maintaining prev/next links to other pages won't scale well enough and would require a utility script for generating it. It has to be reduced to a simple copy-paste friendly boolean value that can be added to all affected pages, or even a top level Starlight configuration for changing the behavior across the board, for it to solve my use-case.

I feel like I'm a bit alone in wanting this sort of navigation for pages in general, so this feature may very well be a lot of effort just to satisfy my desire for arrow based navigation between pages. I did look into the code for the sidebar and got pretty far with decoupling the behaviors, but it wasn't pretty at all and decided to scrap my version of it since it would've never been merged the way I wrote it. As you say they are reeeally tightly knit features. I'll look into making some manner of utility script for it.