-
-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(v2): global data + useGlobalData + docs versions dropdown #2971
Conversation
Deploy preview for docusaurus-2 ready! Built with commit 525b0c2 |
This reverts commit f657b4c
# Conflicts: # packages/docusaurus-module-type-aliases/src/index.d.ts # packages/docusaurus-plugin-content-docs/src/__tests__/metadata.test.ts # packages/docusaurus-plugin-content-docs/src/index.ts # packages/docusaurus-theme-classic/src/theme/DocPage/index.tsx # packages/docusaurus-theme-classic/src/theme/DocSidebar/index.tsx # packages/docusaurus-theme-classic/src/theme/Layout/index.tsx # packages/docusaurus-theme-classic/src/theme/Navbar/index.tsx
…+ try to fix remaining merge bugs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think global data is unavoidable. Gatsby's GraphQL schema is in fact global data which is queryable by every page.
Hence we need to introduce ways to make it more robust, possibly via namespacing. It'd be horrible if plugins overwrote each other's global data due to colliding keys.
I mentioned before that we want to allow multiple docs plugins in a website but the current versioning approach is global, which makes it impossible to do so. We should avoid the same mistake with global data.
# Conflicts: # packages/docusaurus-types/src/index.d.ts # packages/docusaurus/src/client/App.tsx # packages/docusaurus/src/server/index.ts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My only question is the renaming from links
to items
. Is it a necessary change? The helpful error message is super good though, so I'm not opposed to renaming.
// TODO temporary (@alpha-58) | ||
links: Joi.any().forbidden().messages({ | ||
'any.unknown': | ||
'themeConfig.navbar.links has been renamed as themeConfig.navbar.items', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 😊
The renaming is not required but I think items makes more sense than links, now that navbar items have custom types.
I imagine we'd have more navbar item types in the future, including custom ones provided by the user, and maybe the ability for plugins to provide some
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it!
thanks :) |
This PR implements the ability to switch from one doc version to the other, directly from the navbar, without loosing "context" (ie, the doc you are on):
To do this, some infra needed to be built:
docsVersionDropdown
type)Relevant docs:
useGlobalData
,usePluginData
,useAllPluginInstancesData
)Breaking changes:
themeConfig.navbar.links
renamed tothemeConfig.navbar.items
(with custom error msg to help user)