Open PuruVJ opened 3 months ago
The nav.js automatically sets the "next" section: Since we already highlight which section you're on, you probably don't need it anyway:
Another advantage this PR is to potentially have more than 1 nesting. There are some situations where an extra +1 nest would be nice (albeit more-rare).
Finally, there are situations where a static "next" doesn't apply, resulting in inconsistent footers. For example, the next chapter may be module code that could fork into 1 section for Rust, 1 section for C#.
I like it.
EDIT: However, I do recall the entire docs architecture may be revamped soon? This could be a moot PR, if that's the case. For example, in the current state:
spacetime-web
)However, I do recall the entire docs architecture may be revamped soon?
I wasn't aware of that 😅. I'll be on standby on this
https://github.com/clockworklabs/spacetime-docs/pull/53 shows how much we need a consistent structure and automatic generation.
Problem
Currently any and all docs have to be specified in nav.js file. This is extra redundancy.
Solution
We get rid of nav.js. Split the documentation into sections with .md files being the page slugs, and meta.json for section title.
Structure:
This will require setting up redirects for the overview routes, (which is like a 10 line piece of code), but the advantage is that our URLs will become consistent. Currently some urls have 0, some have 1 slug, some have 2, some even have 3. This will make em all just 2 fixed slugs, which is easier to reason with.
How about title of a chapter?
This will be defined in the frontmatter:
This lets us add future config right within the content(manual next or previous, tags, version separation, etc)
Prerequisites
Need the remix rewrite to become the prod site, as rewriting now will make it incompatible with the current site.
Final complete structure:
All directories get a meta.json to specify the category title.
Can we keep it variable-depth?
Instead of /modules/rust-quickstart, can we stay with
/modules/rust/quickstart
? We can, but then we'd have to rectify the depth artificially in the sidebar config too, which means we're back to configuration which is prone to breaking.What about redirects?
Redirects will be done server-side in the new site, so the change will be instantaneous and will not have any flickering.
Redirects will look something along these lines: