[material-ui] Prevent ownerState propagation for transition slots

[ZeeshanTamboli]

Found this while investigating an issue—check the console error about ownerState.

Before: Sandbox
After: Sandbox

You can also see it in the local Accordion docs at http://localhost:3000/material-ui/react-accordion/.

The workaround in #40418 was removed in favor of #41187, but #41187 doesn’t handle custom transition slots like Fade and Zoom.

This PR introduces a new shouldAppendOwnerState option in useSlot, preventing ownerState from being appended unnecessarily, instead of appending and then removing it.

[mui-bot]

Netlify deploy preview

https://deploy-preview-44401--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 7ea5845

[DiegoAndai]

Hey @ZeeshanTamboli, thanks for working on this.

We do want the ownerState to be available for the transition slots. That way, users can consume it when building their custom transitions. The responsibility of filtering ownerState would be on the developer.

The fix here should be to filter out the ownerState inside the Fade and Zoom components. Because those are our transition components, the responsibility of not forwarding ownerState incorrectly should be handled on each one. Does this make sense?

[ZeeshanTamboli]

Hey @ZeeshanTamboli, thanks for working on this.

We do want the ownerState to be available for the transition slots. That way, users can consume it when building their custom transitions. The responsibility of filtering ownerState would be on the developer.

The fix here should be to filter out the ownerState inside the Fade and Zoom components. Because those are our transition components, the responsibility of not forwarding ownerState incorrectly should be handled on each one. Does this make sense?

Oh, I thought the ownerState passed to the slotProps callback through resolveComponentProps in useSlot was sufficient. For example:

slotProps={{ transition: ({ expanded }) => (expanded ? 300 : null) }}

For non-transition slots, I assumed ownerState was appended for use in the styled API for styling.

Is that not the case?

The responsibility of filtering ownerState would be on the developer.

Do we document this somewhere?

[DiegoAndai]

Oh, I thought the ownerState passed to the slotProps callback through resolveComponentProps in useSlot was sufficient.

For non-transition slots, I assumed ownerState was appended for use in the styled API for styling.
Is that not the case?

Both of these are useful, but IMO don't cover all use cases. Making the parent's ownerState available as a prop provides more flexibility. There's also an argument for not providing the ownerState but only certain properties of it. This is another thing we need to decide regarding the slot pattern cc: @siriwatknp

Do we document this somewhere?

No. Documentation about slots could and should be much better. We're working on improving that, but first, we want to implement the missing slots throughout the components.

[ZeeshanTamboli]

@DiegoAndai What's your take on the recent pushed change to destructure ownerState?