-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
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
[material] Remove dependency to @mui/base #42907
Conversation
mnajdova
commented
Jul 11, 2024
- I have followed (at least) the PR section of the contributing guide.
Netlify deploy previewhttps://deploy-preview-42907--material-ui.netlify.app/ @material-ui/utils: parsed: +152.12% , gzip: +70.16% Bundle size reportDetails of bundle changes (Toolpad) |
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.
Looks good
@@ -27,6 +27,9 @@ export const projectSettings: ProjectSettings = { | |||
getHookInfo: getBaseUiHookInfo, | |||
translationLanguages: LANGUAGES, | |||
skipComponent: () => false, | |||
skipHook: (filename) => { | |||
return filename.match(/(useSlotProps)/) !== 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.
This hook was anyway not documented, so I've added this option to skip, otherwise the docgen generation failed. It's an optional prop it won't break other ts projects.
@aarongarciah this is ready for final review. Changes after the approval:
|
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 for the review @aarongarciah. Next steps:
I will move with the next steps. |
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.
What's the motivation for this change? It seems that the PR description is missing context.
@@ -27,6 +27,7 @@ module.exports = [ | |||
{ pathname: '/material-ui/api/checkbox' }, | |||
{ pathname: '/material-ui/api/chip' }, | |||
{ pathname: '/material-ui/api/circular-progress' }, | |||
{ pathname: '/material-ui/api/click-away-listener' }, |
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'm confused about this. Would it mean we will have:
@mui/material/ClickAwayListener
@mui/base/ClickAwayListener
@base_ui/react/ClickAwayListener
. I mean, I imagine we need it https://stackoverflow.com/questions/32553158/detect-click-outside-react-component
@@ -125,6 +128,7 @@ module.exports = [ | |||
{ pathname: '/material-ui/api/tab-panel' }, | |||
{ pathname: '/material-ui/api/tabs' }, | |||
{ pathname: '/material-ui/api/tab-scroll-button' }, | |||
{ pathname: '/material-ui/api/textarea-autosize' }, |
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.
Same idea as above with https://stackoverflow.com/questions/454202/creating-a-textarea-with-auto-resize
From the exposure to this change and dive discussed in mui/mui-x#13823 can we revert this PR and go in the opposite direction? I also got confused in #42604 (comment), we shouldn't have 3 versions at any point in time. As a side note, we need the git history of those components, it's missing after this PR. It seems that having those modules in @mui/base, hosted in http://github.com/mui/material-ui would already to be a clear step forward, with no real downsides. |
What exactly is the opposite direction?
Right, I would assume by moving the component to Mateiral UI, we won't need to do any updates on @mui/base, the initial plan is to no longer release this package, mark it as private, and eventually remove the code once we have @base_ui.
The motivation for the change is that we will no longer need to make updates on @mui/base, not about where the components are being documented.
I am not sure which if any of these components will live in Base UI, and what would be the form of these. What is the value of adding legacy stuff in Base UI, if these are only used in Material UI and Base UI do not plan to support these or plans to change the API around them. I will let @colmtuite and @michaldudak answer on this, but in my opinion this was not an option, hence I went with moving them to Material UI. |
I can fix this in #43028, I've applied the changes needed for the NoSsr, but I will wait with updating all components until we have a decision on how to move forward. |
This makes sense to me, and is what the majority of the team have been planning for at least the past few months. I figure we would just take each util/package, figure out the most appropriate place for it to belong, and move it there. Then that team are responsible for it. Sometimes, the most appropriate place will be Base UI, sometimes, Material UI, sometimes X, and potentially sometimes a shared utils lib. But corrupting the new Base UI lib by prematurely abstracting legacy utils/components to it—when we don't know if they belong there long-term—is the worst path we could take. It's much worse than duplicating things in multiple locations. |