Add shouldForwardProp to theme

[andrehil]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Summary 💡

I'm using a custom property to create custom variants for OutlinedInput.
The problem is that I need to pass the property to the component for the theme to have it, but the property ends up being rendered to the DOM.

Examples 🌈

Component usage:

<OutlinedInput state="error />

Theme:

{
  "MuiOutlinedInput":{
    "variants":[
      {
        "props":{
          "state":"error"
        },
        "style":{
          "my_custom_styles":"go here"
        }
      }
    ]
  }
}

Motivation 🔦

The motivation is the same as the function shouldForwardProp that exists in styled.
Avoid rendering unnecessary properties to DOM.

[michelengelen]

This would be a great feature to have and I am currently having the same issue. Is there anyone working on this and if not could you maybe point me to the respective place in the codebase where this could be added? I could add that feature myself in that case.

cc @siriwatknp

Thanks in advance!

[Armisael2k]

Any updates?

[andrehil]

Please don't let this one die :)

[siriwatknp]

@mnajdova A new use case for the variants API. This case needs to style based on the ownerState, not just props.

[trungutt]

We'd like to have this too

[rishavpandey43]

Hi @mnajdova

Is there any update on this, its really very helpful feature.

[mnajdova]

The issue itself looks like a duplicate of #19466, it's about supporting additional props in the components. The decision is about whether creating a wrapper component as an API is easier/more intuitive in comparison with a new API about specifying which props should be propagated. I am tagging @aarongarciah so we can include this in the planning for the next theming customization/experience. If we decide to add this support in one of the next majors, we can likely backport it in v6 too.

[michelengelen]

Duplicate of #19466

[rishavpandey43]

@mnajdova IMO, we can create a wrapper component and it's good when we have some additional features to add.

But for simple changes like just giving support of maxWidth in the TableCell component we will create a wrapper where we're simply returning the same component and nothing new is being done. I think adding this new functionality might be great.

[ChristianGrete]

We have the same problem, for example, that we introduce the prop dense for the IconButton via theming and module augmentation for a button variant with less padding, which technically works great, but the boolean prop is forwarded to the DOM, resulting in the following error message in Chrome:

Warning: Received `true` for a non-boolean attribute `dense`.

If you want to write it to the DOM, pass a string instead: dense="true" or dense={value.toString()}.

As far as I understand, there should be a way to override which props are forwarded in the theme for a component, like shouldForwardProps in styled. Since we maintain a whole design system's component library based on MUI, a wrapper component is not a good alternative here, as it would have to have the same feature set as an original MUI component when consumed, because this is what our users expect. A custom component therefore always means a certain overhead of code and an alternative import source of a component actually provided by MUI, which could be avoided with such a functionality.