Skip to content
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

[material-ui] Deprecate *Component and *Props props #41281

Open
25 of 39 tasks
DiegoAndai opened this issue Feb 26, 2024 · 17 comments
Open
25 of 39 tasks

[material-ui] Deprecate *Component and *Props props #41281

DiegoAndai opened this issue Feb 26, 2024 · 17 comments
Assignees
Labels
deprecation New deprecation message package: material-ui Specific to @mui/material

Comments

@DiegoAndai
Copy link
Member

DiegoAndai commented Feb 26, 2024

Part of #40417

Description

Deprecate *Component and *Props props in v6, planned for removal in v7.

  • These are deprecated in favor of the slot pattern: slots and slotProps
  • If the slots or slotProps props do not exist:
    • They must be implemented in the same PR in which the deprecation is added
    • They should have the same type as the deprecated prop
  • The PR introducing the deprecation must also add:

Example PR

Contributing

Feel free to take any components that still need to be done or in progress. Please mention this issue in your PR so we can link it in the description and keep it up to date.

Components to migrate

ordered by page views

Additional tasks

Search keywords: deprecation material-ui

@DiegoAndai DiegoAndai added deprecation New deprecation message package: material-ui Specific to @mui/material ready to take Help wanted. Guidance available. There is a high chance the change will be accepted labels Feb 26, 2024
@DiegoAndai DiegoAndai self-assigned this Feb 26, 2024
@harry-whorlow
Copy link
Contributor

@DiegoAndai Hi man, hope all is well!

Can you mark speed dial as under way 40698. I'll be adding to it over the coming weeks 🤟

@DiegoAndai
Copy link
Member Author

@harry-whorlow done 🙌🏼

@DiegoAndai
Copy link
Member Author

Utils for the codemods of these deprecations were added in #41685. This makes implementing the codemods easier.

@harry-whorlow
Copy link
Contributor

@DiegoAndai I think I'll take up menu next, I'll create a pull request in the coming days. 🤟

@harry-whorlow
Copy link
Contributor

My draft for menu, if you could mark menu as 'in progress' that would be awesome. 🤟

@DiegoAndai
Copy link
Member Author

DiegoAndai commented May 30, 2024

Hey everyone! With the core team, we've been discussing that composition might be a better API than slots for these props' use cases. It hasn't been decided yet if we will take this approach, but until we have more clarity, I'm marking this issue as on hold.

For v6, we should revert the deprecation messages we've added. Is someone here interested in opening a PR for that? It should only revert the deprecation messages, not the code itself.

Note that #41279 is not on hold. We will continue with that one, as having two names for the same thing (components and slots) doesn't make sense.

I'm sorry if you had open PRs and this disappoints you 😓 but we should strive for the best API 🙌🏼 🚀. For the moment, let's close open PRs. I'll keep you updated.

@DiegoAndai DiegoAndai added on hold There is a blocker, we need to wait and removed ready to take Help wanted. Guidance available. There is a high chance the change will be accepted labels May 30, 2024
@DiegoAndai DiegoAndai moved this from In progress to Backlog in Material UI May 30, 2024
@lhilgert9
Copy link
Contributor

For v6, we should revert the deprecation messages we've added. Is someone here interested in opening a PR for that? It should only revert the deprecation messages, not the code itself.

@DiegoAndai I could do this.

@harry-whorlow
Copy link
Contributor

harry-whorlow commented Dec 16, 2024

Morning if it's okay with you guys I'll pick up the Modal: missing migration guide and codemod ticket to get back up to speed. 🤟

[edit]: I think the checklist needs to be updated, as it appears the codemod and docs are there.
Screenshot 2024-12-16 at 11 00 27

Screenshot 2024-12-16 at 11 03 39

If were moving with this again then I'll pick up Radio and give it a go.

@alexey-kozlenkov
Copy link
Contributor

alexey-kozlenkov commented Dec 16, 2024

@DiegoAndai greetings! I see there are more tickets being linked to this one lately. Perhaps this current issue has been given any more thoughts from the core team and there is some decision now (together with #37585) ?

@DiegoAndai
Copy link
Member Author

DiegoAndai commented Jan 15, 2025

@siriwatknp given @oliviertassinari's performance concerns, I added a task to this issue to measure useSlot's impact on performance. May I ask you to prioritize measuring it and see if we need to take action? Ideally, we should measure all components, but if not possible, let's prioritize by usage.

@siriwatknp
Copy link
Member

siriwatknp commented Jan 17, 2025

Based on the benchmark (in ms) using CardHeader comparison between 6.3.0 vs 6.4.0 (using useSlot):

For CardHeader, the useSlot increase the time to render ~0.2-0.3ms per instance.

Below is the details of the benchmark:

row: number of instances
column: Material UI version

normal 6.3.0 6.4.0 diff diff(%)
100 17.59 20.7 3.11 17.68%
1000 187.87 216.37 28.5 15.17%
x6 slowdown 6.3.0 6.4.0 diff diff(%)
100 108.66 129.31 20.65 19.00%
1000 1127.56 1344.11 216.55 19.21%

Benchmark is done on Apple M3 Pro

I'd say this is acceptable for v7. What's your thought @DiegoAndai cc @mnajdova

@DiegoAndai
Copy link
Member Author

@siriwatknp a couple more things I think we should try:

  • The CardHeader has six slots. May I ask you to test with components that have fewer slots so we can understand how the amount of useSlot hooks used impacts these metrics? Testing with a component with 2 slots and one with 4 slots would be ideal.
  • The Slider uses useSlotProps instead of useSlot. May I ask you to compare its performance if we use useSlot? useSlotProps seems to be a simpler implementation of the hook, so I would like to understand if their performance is different as well.
  • May I ask you to spend some time digging into useSlot to understand if we can optimize anything to reduce this 15-20% difference we see in the test above?

@siriwatknp
Copy link
Member

@DiegoAndai Yes, I'm benchmarking some more components.

@siriwatknp
Copy link
Member

siriwatknp commented Jan 20, 2025

@DiegoAndai I was wrong. The performance difference of the previous benchmark comes from the IconButton, not the CardHeader. In the previous benchmark, I use this markup:

<CardHeader
  key={i}
  avatar={<Avatar aria-label="recipe">R</Avatar>}
  action={
    <IconButton aria-label="settings">
      <MoreVertIcon />
    </IconButton>
  }
  title="Shrimp and Chorizo Paella"
  subheader="September 14, 2016"
/>

After I replace Avatar and IconButton with div and button, the performance has no difference between 6.3.0 and 6.4.0.
Here is a new benchmark (time to render in ms using 1000 instances of CardHeader).

v6.3.0 v6.4.0 diff diff(%)
normal 152.72 148.36 -4.36 -2.85%
with avatar 177.68 180.21 2.53 1.42%
with avatar + button 212.29 209.21 -3.08 -1.45%

As you can see, I split them into 3 scenarios:

  1. CardHeader with title and subheader props
  2. CardHeader with title and subheader props + avatar prop
  3. CardHeader with title and subheader props + avatar prop + action prop

CardHeader has 6 slots and there is no difference in performance. I think the migration is safe to do.


More details on the IconButton, in v6.4.0 the loading is introduced but not optimized (render extra element even loading is false). I will create a separate PR to optimized this using the similar approach I did to Button.

@harry-whorlow
Copy link
Contributor

harry-whorlow commented Jan 23, 2025

@DiegoAndai if this task is moving again, can my #42218 be reopened?

[edit] ah, I see its already been done in #44913, if its cool with you guys I'll pick up snack bar then

@DiegoAndai
Copy link
Member Author

@harry-whorlow please go ahead. Let us know when you open a PR.

cc: @siriwatknp

@DiegoAndai
Copy link
Member Author

@siriwatknp just a heads up: I added a task to check before closing this issue:
Replace the use of *Component and *Props internally, for example: https://github.com/mui/material-ui/blob/master/packages/mui-material/src/Autocomplete/Autocomplete.js#L688

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecation New deprecation message package: material-ui Specific to @mui/material
Projects
Status: In progress
Development

No branches or pull requests

5 participants