-
-
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
[core] Update overridesResolver for slots #25850
Conversation
Bundle size will be reported once Azure build #26336 finishes. |
@oliviertassinari @eps1lon should I proceed with updating the components to use Option 1 ( |
👍 for option 1. I think that it will be cleared for developers that look at our sources for making overrides too. I'm confused about how the performance build was run but seeing no difference seems coherent, so all good from my end. |
It was run as described in #23895 In addition to this, local run gave pretty much the same results. |
I noticed now that I didn't remove the Edit: Actually it shouldn't affect perf, as we didn't have anything to deep merge depending on the styles. |
Closing this one, will be creating new PRs for converting components to this approach |
adding another benefit of option 1 compare to others is the flat css specificity. I think it is totally better than having nested css. The DX is also close to v4 (which I like) because if dev want to custom the MuiSlider: {
styleOverrides: {
track: {
boxShadow: 'inset 0 0 0 1px rgba(0,0,0,0.12)',
backgroundColor: '#fff',
}
}
} and they expect to see this in devtool. .css-MuiSlider-track {
....other css
boxShadow: inset 0 0 0 1px rgba(0,0,0,0.12);
backgroundColor: #fff
} |
@siriwatknp exactly, two main benefits that I could find are better readability + flatten specificity :) |
The only issue I could find is that sometimes, on components, where we allow users to use their own components instead of the slots we create with I could spot this issue by the first 10 components I've tried to migrate - #25853 I believe that in some places, we will still need to have the previous class overrides, for example on the |
Also I believe we should disable the |
@mnajdova yeah, that is one downside of the approach. I faced it when doing the migration for TreeItem. I need to fix the demo (Component override example) that the styles in child is no longer there. But may be it make sense because I override the whole Component so the styling should be my responsibility 🤔 |
We need to be careful when we need to keep the styles on the |
TL;DR
I proposed we go with Option 1 which is using
overridesResolver
per slot as original done in #25809 by @siriwatknp Perf compared to current implementation is way better and it is not slower compared to Option 2, but gives us much better readability + flatten specificity 🚀This PR set up benchmark test for the Slider component, where we can measure perf differences between two options of how we may define the
overridesResolver
for the slots components.Option 1 - use
overridesResolver
for each slot of the component:Option 2 - use one
overridesResolver
withoutdeepmerge
Benchmark Azure Job build - https://dev.azure.com/mui-org/Material-UI/_build/results?buildId=26337&view=logs&j=9ef21fd1-5d60-5fa4-f8b2-6dc79e173863&t=516d74c5-15a9-50a0-24d9-dba41a487a2d
Based on the benchmark, seems like both options are giving us way better perf over the current implementation that uses
deepmerge
🚀769.04 ±27.65ms -> 97 ±3%
769.04 ±27.65ms ->96 ±4%
As the perf difference between the two options is negligible, I'd say we go with Option 1, which gives us better readability and flatter specificity. Credits go to @siriwatknp for giving us this idea in #25809