You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
- introduction
- meta.json <----- This is a json file with { title: "Introduction" } as content
- overview.md. <----- This is URL: `/docs/introduction/overview`
- getting-started.md <----- This is URL: `/docs/introduction/getting-started`
- deploying
- meta.json
- testnet.md
- unity
- meta.json
- part-1.md
- part-2.md
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:
---title: Testnet---
<<CONTENT>>
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.
The numbers as prefixes are for ensuring the order of the navigation. The numbers are stripped altogether, and only used for filesystem sorting. Can be anything 2-digits. This lets the content authors to also take care of the pages order while authoring documents.
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.
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:
You can't locally host a preview of the result
You can't preview static /images that are stored on a completely different repo (spacetime-web)
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:
The text was updated successfully, but these errors were encountered: