-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[docs] Migrate TreeView demos #26146
Conversation
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
content: { | ||
const StyledTreeItemRoot = experimentalStyled(TreeItem)(({ theme }) => ({ | ||
color: theme.palette.text.secondary, | ||
[`& .${treeItemClasses.content}`]: { |
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.
Interesting, it's seems that we didn't use them in the past. What should we do going forward?
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.
My thinking was, if there are more styles, especially with multiple keys to style a component, styled()
looked like the better replacement (I just replaced the keys in the classes with the classes selectors). For trivial, one line changes I used the sx
prop.
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 like the concept of being able to trust already defined class names instead of typing and making a mistake on it.
It looks interesting to use the same technique that is already used in the creation of the 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.
My point was exactly on what @vicasas, the use of the classes object. No real preferences. I like how a plain string is YOLO and often good enough, but I also understand how having a JS object with IntelliSense that describe what each key is for can also help.
cc @vicasas that has worked on this type of efforts so far, in case he wants to review. |
Co-authored-by: Olivier Tassinari <olivier.tassinari@gmail.com>
'Mui-expanded': expanded, | ||
'Mui-selected': selected, | ||
'Mui-focused': focused, | ||
'Mui-disabled': disabled, |
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.
Interesting, for another example I remember that I used another form that perhaps should be discussed.
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 it is a bit of a different use-case, but I see your point. I would say that for the pseudo states, we should always rely on the pseudo classes, as we do with the core components, as sometimes it would be impossible to override some css rules if we don't bump the specificity when overriding.
For example, for the disabled state, the core components are defining the styles with:
'&.Mui-disabled': { ... },
If we don't bump the specificity in the overrides, we won't be able to override.
Migrates
TreeView
demos to emotion. One of One of #16947https://deploy-preview-26146--material-ui.netlify.app/components/tree-view/