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
A limitation of Docusaurus V1 is that in order to include a page in multiple sidebars, you have to have a clone of the page. Otherwise, the page doesn't know which sidebar it would belong to when opened, and wouldn't know what to render on the side - i.e. which context it's appearing in.
There are three solutions:
Update to Docusaurus V2.
Write a mirror script which is run pre-build or on manual request and creates mirror entries of desired pages, add mirrors manually to sidebar.
Write a pre-build parser which reads page metadata and builds the menus from that.
The first option is not feasible right now, too much work before we have all the content.
Options 2 and 3 both ignore the problem from the intro paragraph - the page being rendered will have to default to one context, potentially creating minor confusion. I.e. open "guideX" from Product API, but the same guide is linked in the Article API menus. If you click it from Article API, the sidebar being rendered will be from Product API, creating a disjointed experience.
A solution to this would be to write a JS hack which copies the sidebar and overwrites from localstorage (functionality already exists) on links with certain CSS selectors.
Because a recipe can appear in more than 1 menu, mirroring might prove to be too chaotic. A page appearing in 3 menus would require us to add the pages into three menus, and there would be two mirror files created, not one. This gets more complex as pages appear in more menus.
Right now I'm leaning towards option 3, which would use something like:
A limitation of Docusaurus V1 is that in order to include a page in multiple sidebars, you have to have a clone of the page. Otherwise, the page doesn't know which sidebar it would belong to when opened, and wouldn't know what to render on the side - i.e. which context it's appearing in.
There are three solutions:
The first option is not feasible right now, too much work before we have all the content.
Options 2 and 3 both ignore the problem from the intro paragraph - the page being rendered will have to default to one context, potentially creating minor confusion. I.e. open "guideX" from Product API, but the same guide is linked in the Article API menus. If you click it from Article API, the sidebar being rendered will be from Product API, creating a disjointed experience.
A solution to this would be to write a JS hack which copies the sidebar and overwrites from localstorage (functionality already exists) on links with certain CSS selectors.
Because a recipe can appear in more than 1 menu, mirroring might prove to be too chaotic. A page appearing in 3 menus would require us to add the pages into three menus, and there would be two mirror files created, not one. This gets more complex as pages appear in more menus.
Right now I'm leaning towards option 3, which would use something like:
... to insert the links into the
build
files after build processing is done, but option 2 sounds okay too if automated properly.Leaving this open-ended, for now we'll limit things to one menu per page.
The text was updated successfully, but these errors were encountered: