-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
[Chip] Migrate to emotion #24649
[Chip] Migrate to emotion #24649
Conversation
@material-ui/core: parsed: +0.48% , gzip: +0.27% |
[classes[`iconColor${capitalize(color)}`]]: color !== 'default', | ||
}), | ||
}); | ||
icon = ( |
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.
Watch out, here you are creating a wrapper around the original component. We have two options of how to solve this:
- Add the styles in the root using the class selector for this slot - we would be increasing the specificity with this :\
- Another option would be to use the
as
prop to render theiconProp
, something like:
<ChipIcon
{...iconProp.props}
as={iconProp.type}
styleProps={styleProps}
className={clsx(classes.icon, iconProp.props.className)}
/>
Here is an example with working example - https://codesandbox.io/s/sad-wood-m4vfh?file=/src/App.js
I would vote for option 2, it should be the one without introducing any breaking changes. cc @oliviertassinari let me know if you agree.
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 case with the icon looks identical to the case with the avatar. I think that we should increase the specificity anytime we use cloneElement. I can search the issue that we had it the past with the avatar that lead to increasing the specificity.
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.
#18156 should give more context.
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.
We can always try option 2 and see how it goes
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 am always more scared to introduce bigger specificity, I'd say let's try not to if we see the problem we can do it later.. I am pretty sure we are soon going to receive complain if something is not working.. :)
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 that's the case then let's go with the bigger specificity
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.
@natac13 sorry for the confusion let's go with increasing the specificity, the root would contain the styles for the avatar
, icon
, and delteIcon
. The label
is anyway a different 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.
No worries. Ill make the changes. I hope 🤞🏻
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.
Basically, if we want to support custom external icons, we need to consider the following:
- With emotion, we get the specificity order with prop cascading: option 2 is OK
- With JSS, and sc with are getting the specificity with import order, CSS rules specificity is order dependent on chips #16374 (comment) shares an issue we had in the past. It was related to dead-code elimination. In order to get it to work, developers have to import the icon and the chip in the right order, it's error-prone and not obvious. @dtassone experienced this problem first hand with the data grid recently. option 2 is borderline
- With CSS we are getting injection order, developers will configure it to have more specificity, they won't have any luck. option 2 is KO
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.
@oliviertassinari would be nice if you can also do a final review - @natac13 already implemented the changes with increasing the specificity, looks good 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.
Left some suggestions, also don't forget to remove from the avatar element the classes that are already included in the useUtilityClasses
I still cannot figure out the 4 tests that are failing. |
Taking a look Edited: it was a matter of typo - fixed with 11bff3d |
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.
Few final comments, let's see after this if we will have some visual regressions, if not I believe we can merge :)
Is this just based off the testing, or do you manually check it visually? |
I am mostly depending on argos for visual tests, unless the component has some state, then I try to test out the other states too. This one looks good |
It has allowed me to find one mistake with `outlined${capitalize(variant)}`
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 could only find one mistake in the mapping of overridesResolver
with outlinedOutlined
. I have pushed a commit.
#24405
Will need a bit of help with this one.