[material-ui] Add mergeSlotProps for extending components

[siriwatknp]

From #44350 (comment).

Docs: https://deploy-preview-44809--material-ui.netlify.app/material-ui/guides/composition/#forwarding-slot-props

Without the function, a lot of boilerplate code is required. I believe that users will create this kind of utility in their codebase because it's quite a common use case to extend Material UI components, so I think we should provide this utility called mergeSlotProps.

The mergeSlotProps resolves function type and then merge the props. Only the className that's concatenated to preserve the same behavior of slotProps, the rest will override the default ones. The usage is added to the docs.

mergeSlotProps(
  (ownerState) => ({ className: 'outside' }),
  { className: 'inside' },
)

// className = 'inside outside'

---

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

• docs/data/material/guides/composition/composition.md

@material-ui/core: parsed: +0.07% , gzip: +0.07%

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 6f669a8

[DiegoAndai]

Thanks for working on this @siriwatknp. I think it will be very useful now that we're standardizing the slots pattern.

[siriwatknp]

Thanks for working on this @siriwatknp. I think it will be very useful now that we're standardizing the slots pattern.

Yes, this PR will be used by some Material UI components too, e.g. a SwipeableDrawer where it extends the Drawer component.

[DiegoAndai]

LGTM

[Chee7ah]

Why is this utility implemented so that the first param overwrites the second: mergeSlotProps({ color: 'red' }, { color: 'blue' }) => { color: 'red' } instead of the other way around?

Previously I've been writing code like this to override the some of the default values while keeping the rest untouched:

slotProps={{
  ...props.slotProps,
  popper: {
    ...props.slotProps?.popper,
    disablePortal: true,
    placement: 'top',
  }),
}}

Assuming

props.slotProps === {
  popper: {
    disablePortal: false,
    placement: 'bottom',
  }
}

I ended up with

popper: {
  disablePortal: true,
  placement: 'top',
}

Now looking at mergeSlotProps and the example from the documentation...

mergeSlotProps(props.slotProps?.popper, {
  className: 'custom-tooltip-popper',
  disablePortal: true,
  placement: 'top',
})

...my expectation would be the same kind of behavior, that the default props I get from props.slotProps?.popper get overridden. However this is not the case. The fact that I manually specified disablePortal: true and placement: 'top' doesn't matter, because props.slotProps?.popper overrides it, I get

popper: {
  disablePortal: false,
  placement: 'bottom',
}

The docs do call out the actual behavior, that the first param overwrites the second, but to me this seems counterintuitive and easy to trip up on.

This utility also reminds me of Object.assign(), which again works the other way around.

[siriwatknp]

Why is this utility implemented so that the first param overwrites the second: mergeSlotProps({ color: 'red' }, { color: 'blue' }) => { color: 'red' } instead of the other way around?

Thanks for the feedback. My intention is to let TypeScript pickup the type from the first argument so that you can leverage the autocompletion/type correction when providing the second argument.

mergeSlotProps(props.slotProps?.popper, {
  // you will get type completion based on the types of `slotProps?.popper`.
})