-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
refactor(v2): better docs metadata #1815
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
Conversation
|
Deploy preview for docusaurus-2 ready! Built with commit 5269f01 |
|
Deploy preview for docusaurus-preview ready! Built with commit 0680354 |
|
Deploy preview for docusaurus-preview ready! Built with commit 5269f01 |
yangshun
left a comment
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.
Awesome perf wins! I'll look the data structure in more detail later and see whether we can improve the sidebar with this also.
Actually I was thinking of leaving this legacy plugin in and creating the new plugin with new components, that's why I added legacy to the name. Do you think that approach is necessary?
i think it will be hard to maintain two plugins with different component
actually the sidebar has been improved also. instead of doing the lookup table client side, we do it server side (at build time) instead. The sidebar component will only receive a very-easy-to-digest props of course more improvement can be done |
I don't intend to maintain the legacy one, just keep it there. But I guess we could just move things now. Only users who swizzled the doc components need to re-implement their doc components because the data structure has changed. No that many people swizzled I think.
Ah I meant the React component, to collapse categories if the page is not active, expand when item is active. I could tackle this later :) Feel free to merge first! |
Sure thing. To find current page you might want to pass
- <DocLegacySidebar docsSidebars={docsSidebars} sidebar={sidebar} />
+ <DocLegacySidebar location={location} docsSidebars={docsSidebars} sidebar={sidebar} />The sidebar content data structure will look like this. It's only either [
{
"type": "category",
"label": "Guides",
"items": [
{
"type": "link",
"label": "Creating Pages",
"href": "/docs/creating-pages"
},
{
"type": "link",
"label": "Styling and Layout",
"href": "/docs/styling-layout"
},
{
"type": "category",
"label": "Docs",
"items": [
{
"type": "link",
"label": "Markdown Features",
"href": "/docs/markdown-features"
},
{
"type": "link",
"label": "Sidebar",
"href": "/docs/sidebar"
}
]
},
{
"type": "link",
"label": "Blog",
"href": "/docs/blog"
},
{
"type": "link",
"label": "Analytics",
"href": "/docs/analytics"
}
]
}
] |
|
I'm working on it now, have a PR almost up! |
Motivation
This PR is an attempt to make our docs data structure to be more efficient while achieving the same functionality. This should solve scalability problem #1782
Previously, we have something called
docsMetadatathat contains all the metadata of all docs pages. It is used as a lookup table for certain doc page to convertidinto its correspondingmetadataliketitleandpermalink. This poses a huge problem because as the number of docs grow bigger, the client bundle size will increase linearly.Current docu v2 docs for example, the

docsMetadataitself is alrd ~15kbWith this PR, the docsMetadata is just ~2kb

In fact, this PR makes our build time much faster and consume less memory as well
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
prevandnextbutton is working properly