-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
[core] Replace @mui/base with @mui/utils + @mui/material #13823
Conversation
Deploy preview: https://deploy-preview-13823--material-ui-x.netlify.app/ |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Co-authored-by: Lukas <[email protected]> Signed-off-by: Marija Najdova <[email protected]>
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Signed-off-by: Marija Najdova <[email protected]>
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
I've taken the chance to update the PR.
I think that we mostly need agreement from @mui/xcharts if they are good with reverting to |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@@ -2,7 +2,7 @@ import * as React from 'react'; | |||
import PropTypes from 'prop-types'; | |||
import clsx from 'clsx'; | |||
import { styled, SxProps, Theme } from '@mui/system'; | |||
import { unstable_composeClasses as composeClasses } from '@mui/utils'; | |||
import composeClasses from '@mui/utils/composeClasses'; |
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.
Nice, looks like we can have the flattening of imports as it's own PR.
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.
It's one of the goal of #13401 but it's blocked because we use the unstable_
part which is really not nice
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.
Ah right, I have missed this. We can't make this change for demos in the docs.
But for the source, it looks great.
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.
By the way, it's a small argument in favor of named import:
You can do:
import { unstable_composeClasses } from '@mui/utils/composeClasses'
With default import we'd need to do this to keep the info:
import { unstable_composeClasses } from '@mui/utils/unstable_composeClasses'
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.
Now, I guess I that we can do
import composeClasses from '@mui/utils/composeClasses'; | |
import unstable_composeClasses from '@mui/utils/composeClasses'; |
and call it a day.
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.
That's a fragile convention 😆
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.
Or we could say all of those are public APIs at this point anyway. I mean, how can someone build a custom Material UI component that feels native without composeClasses
? Good luck, which is not OK.
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 need a way to share some private stuff, especially as our amount of component increases.
But yeah some (most ?) of the APIs in @mui/utils
could probably be public and stable by now.
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.
But yeah some (most ?) of the APIs in @mui/utils could probably be public and stable by now.
Agree, these are here for years already.
I am happy to revert these changes, and we can progressivly replace these with @base_ui imports in the upcoming months. It's up to you, I will wait on your decision before doing the changes in the PR. |
@@ -66,7 +66,6 @@ | |||
"date-fns-jalali": "^2.30.0-0", | |||
"dayjs": "^1.11.11", | |||
"doctrine": "^3.0.0", | |||
"d3-scale-chromatic": "^3.1.0", |
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.
It's already defined in line 64.
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.
Thank you for all the effort! 💯 🙏
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
This PR removes the dependency to @mui/base in favor of @mui/utils. @mui/base is not being actively working on, so depending on it creates internal problems in the Core repo, especially in this period when we have two active branches.
It is not required to merge this PR, everything that you had before will still work, however we don't plan to continue to do releases of @mui/base, all fixes are going to be done directly in @mui/utils and @mui/material. I will leave it up to the MUI X team to decide on what's best as a next step.