[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 ea60c29

[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?

[ZeeshanTamboli]

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

@DiegoAndai ^

[ZeeshanTamboli]

@DiegoAndai Just a ping to review this further in case you missed the notification.

[ZeeshanTamboli]

@DiegoAndai

• Can we apply it to the Collapse transition as well?

The Collapse transition uses a styled JSX component instead of React.cloneElement, so ownerState is not forwarded to the DOM since it is already omitted in the styled API. Additionally, the incoming ownerState is overridden by Collapse's ownerState here.

• May I ask you to add tests for this?

Added in Accordion test file because this is the component whose transition child is directly an HTML element and ownerState was getting propagated.

[DiegoAndai]

Additionally, the incoming ownerState is overridden by Collapse's ownerState here.

Yes, that was the previous solution to this same problem, but I would prefer that it had this PR's implementation, I think it's easier to understand and less fragile. Also, having all transition components be as consistently implemented as possible would be good.

[ZeeshanTamboli]

Yes, that was the previous solution to this same problem, but I would prefer that it had this PR's implementation, I think it's easier to understand and less fragile. Also, having all transition components be as consistently implemented as possible would be good.

@DiegoAndai Made the change.

[DiegoAndai]

Thanks @ZeeshanTamboli, looks good.

I have one final request.

May I ask you to add a regression test for the issue in #40653. We should've added it in #41187.

The regression test can be extracted for this example:

• Broken in 5.15.4: https://codesandbox.io/p/sandbox/cold-firefly-dpmqj7?file=%2Fsrc%2FDemo.tsx%3A1%2C1-61%2C1
• Fixed now: https://codesandbox.io/p/sandbox/44401-example-for-test-ypgx4r]

The Switch input and text can be removed for the regression test, they're there only for demonstration purposes.

Thanks in advance!

[DiegoAndai]

Thanks @ZeeshanTamboli!

[DiegoAndai]

Just saw the broken test 😅

Test fixed

[ZeeshanTamboli]

@DiegoAndai All passing now