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
[base] Make CSS class prefixes consistent #33411
Changes from all commits
9ed8620
06f6b49
4dfa187
4d63740
e3c5339
2d75867
35010b0
4166ffb
1d9dedd
f683f20
c7d5d97
5e56e7b
aa63bbb
895a882
81b4026
fc66d45
4a7c414
61babab
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,7 @@ | ||
import { generateUtilityClass, generateUtilityClasses } from '@mui/base'; | ||
import { | ||
unstable_generateUtilityClass as generateUtilityClass, | ||
unstable_generateUtilityClasses as generateUtilityClasses, | ||
} from '@mui/utils'; | ||
|
||
Comment on lines
+1
to
5
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Off-topic I don't fully remember: what's the long-term goal with One example: import { unstable_useId as useId } from '@mui/utils'; which makes me wonder if it would make sense to:
in order to better sell the value proposition of MUI Base as a set of baseline helpers to create React components, including React utils. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't remember us deciding on the shape of this library. To me, it should be a private package (I wouldn't say "alpha" or "unstable" - it's just internal). In the case of this PR, I changed the imports of We can discuss it in the next meeting. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@michaldudak I personally prefer this option too.
Developers use the source of the components as a reference for how to create new ones. So if we bypass @mui/base in the source, I think that it would mean that @mui/utils is not an internal help for @mui/base and @mui/system but a public API they will install on their own. e.g. what MUI X is doing. But why not, we could imagine that @mui/utils is also part of MUI Base, and documented there too. |
||
export interface BreadcrumbsClasses { | ||
/** Styles applied to the root element. */ | ||
|
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.
As far as I know, the X components depend on this API. Could you double check please before removing the API?
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 they depend on the @mui/utils, not sure to be honest.
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.
Their components depend on the implementation from @mui/material. But indeed there's one usage from Base, in the API docs builder. I created a PR to use the implementation from @mui/utils: mui/mui-x#6216
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 PR in X is now merged in, so I believe this one is safe to be merged in as well.