-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
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
refactor(theme-{classic,common}): split navbar into smaller components + cleanup + swizzle config #6895
Conversation
✔️ [V2] 🔨 Explore the source changes: 44d447a 🔍 Inspect the deploy log: https://app.netlify.com/sites/docusaurus-2/deploys/62349f65599869000892d320 😎 Browse the preview: https://deploy-preview-6895--docusaurus-2.netlify.app |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-6895--docusaurus-2.netlify.app/ |
Size Change: +2.58 kB (0%) Total Size: 804 kB
ℹ️ View Unchanged
|
# Conflicts: # project-words.txt
ready for a review we can keep components as unsafe for now, and eventually mark some as safe later after getting some user feedback? |
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.
The diff looks good to me! Wondering if this and its sisters should be marked as breaking changes since we changed the theme-common APIs?
Also, I think we can improve the swizzle CLI and ask the user to choose a subset of components (instead of always ejecting everything) in case of swizzling nested components?
export default function NavbarColorModeToggle({ | ||
className, | ||
}: Props): JSX.Element | null { |
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 wonder if this layer of abstraction is useful? Supposing the entire purpose of ColorModeToggle
is to toggle color modes, should we just move the hook calls to ColorModeToggle
instead and remove this component?
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.
There is value to have design system components (ColorModeToggle) to be very simple and have limited dependencies (ie not using any context). This makes it much easier to test then in isolation, add them to Storybook and other things that I plan to do.
This abstraction is likely to be temporary anyway if we provide a NavbarColorModeItem. For now I assume it's good enough, as this component is not marked as safe anyway
The general idea is that each call site should also be responsible to integrate the toggle on a case-by-case basis. For example, rendering null in case toggle is disabled might not be the best solution in all cases: it really depends on the parent component layout.
If we have later an option to have a sidebar color mode toggle, we'd create a similar SidebarColorModeToggle component, allowing the user to easily have distinct toggle designs for navbar/sidebar
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 see, makes sense
return ( | ||
<NavbarContentLayout | ||
left={ | ||
// TODO stop hardcoding 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.
I think we should do that here, or at least in an immediate follow-up PR. I was asked about how we can change the color mode toggle position and the mobile toggle position. Also in https://docusaurus.canny.io/feature-requests/p/mobile-navbar-toggle-on-righttrailing-edge.
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.
yes we should definitely give more flexibility here
It is a potential breaking change and probably requires some work so I'd rather have another follow-up PR to do so, eventually, find a way to be retro compatible (like normalizing the config and auto adding color mode toggle + search)?
About the mobile sidebar toggle, it probably doesn't make much sense to place it in other places than top right/left, but we can also give similar flexibility 🤷♂️
packages/docusaurus-theme-classic/src/theme/Navbar/MobileSidebar/SecondaryMenu/index.tsx
Outdated
Show resolved
Hide resolved
// TODO BAD, temporary type hack | ||
T extends {position?: 'left' | 'right'}, |
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.
Why is this bad? It looks pretty sufficient to me
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.
If we didn't have the NavbarItem duplicate/incompatible types this wouldn't be necessary.
I'll keep the todo for now as IMHO we should only accept a NavbarItem type (unless we have another reason to use structural typing to split other kinds of items? In which case this util should be moved/renamed and made generic?)
I was also thinking about this. In theory theme-common APIs are not documented and considered internal but at the same time it is a significant refactor that can break existing user code so not sure what to do 🤷♂️
Subfolders are not copied anymore by default, and I was thinking that an option |
Note: I didn't include the NavbarItems in this refactor. Should we nest everything related to the Navbar inside the navbar folder? Should we create a "root" folder for all the major scopes of the theme?
I think it can be useful but also quite disruptive for existing users, it may not have to happen immediately, we can keep this refactor for a later major version? (I guess it's quite unlikely that we disagree on this FS structure anyway) |
# Conflicts: # packages/docusaurus-theme-classic/src/theme/LayoutProviders/index.tsx # packages/docusaurus-theme-classic/src/theme/Navbar/index.tsx # packages/docusaurus-theme-common/src/utils/colorModeUtils.tsx
I agree. "design system" would be for reusable components like paginators and breadcrumbs, right |
yes, and we should try to encapsulate most of the Infima code there (apart things for spacing / layout etc) |
going to merge this it's not perfect and can't be marked as safe for swizzle, but still better than before |
Breaking change
The theme Navbar components have been significantly updated so if you have swizzled them, you may need to re-eject them.
Motivation
Have you read the Contributing Guidelines on pull requests?
yes
Test Plan
preview as before