[poll] Class names pattern

[michaldudak]

Following up on the discussion started in #33260, we need to decide how the class names applied on Material UI, MUI Base, and Joy UI components should look like.

See #33260 (comment) for areas we're trying to optimize for

[mapache-salvaje]

I voted for MuiButton across all component libraries for the sake of maximizing the compatibility between them—as I see it, this would be optimizing for devs who start building with e.g. Material UI but then decide they'd rather use Joy or Base later on. It would make it that much easier for them to switch to one of our other libraries rather than leaving our ecosystem entirely for one of our competitors.

[cherniavskii]

And Material UI reuses some Base components, so if we use different prefixes for Material UI and Base - it will not be obvious which prefix to use to customize the component

[mapache-salvaje]

That's a good point!

[cherniavskii]

What about users that use more than one library in the same project?
For example, they started with Material UI and then started incremental migration to Joy.
It won't be possible to differentiate global theme overrides between Material UI and Joy if prefixes are the same, right?

[michaldudak]

This made me come up with yet another solution - keep Mui<ComponentName>, regardless of the product + add a product-specific class (perhaps only on the root slot), such as MuiMd, MuiJoy, MuiBase. This way, we won't introduce any breaking changes.

[mapache-salvaje]

The more I think about the options, the more I like MuiMdButton, MuiJoyButton, MuiBaseButton. If I could vote twice this would be my second vote. 😁 It works really nicely from a branding perspective, and it's a fairly intuitive pattern (Md would be something new, but it's easily understood in context and could help to clarify the difference between Mui and Md 😜).

[cherniavskii]

What does it mean for Base components used in Material UI components?
Would they have both MuiMd- and MuiBase- classes?
For more complex components with nested elements, would that mean that for every MuiBase- prefixed class name we should add MuiMd- prefixed one?
cc @michaldudak

[michaldudak]

@cherniavskii Base components that are simply re-exported from other packages would have the Base prefix. Styled components that use Base ones (such as Material UI's Popper that's built on top of PopperUnstyled) would have only Material UI / Joy prefix.

[oliviertassinari]

I voted for MuiButton, JoyButton, BaseButton, the least worse option 😁

• I don't like the Mui renforces for Material UI = MUI but anything different would be a non negligeable breaking change, so I think a no-go.
• I don't like that base class name doesn't match its imports. But developers will likely write CSS selectors with the import API anyway for type safety, e.g. buttonUnstyledClasses.root. This class name is shorter (hopefully long enough to not conflict), and match the product name like the others when you open the devtools.

If I could add another option, I would vote for MuiButton, JoyButton, BaseButtonUnstyled.

[mapache-salvaje]

• I don't like the Mui renforces for Material UI = MUI but anything different would be a non negligeable breaking change, so I think a no-go.

Shoot, you're right about that.

[michaldudak]

If I could add another option, I would vote for MuiButton, JoyButton, BaseButtonUnstyled.

I updated the options. Please vote again.

I don't like that base class name doesn't match its imports

This could be solved another way - by dropping the Unstyled suffix from Base components.
We've already seen an opinion from the community member that they'll look better without the suffix.

[michaldudak]

I voted for the newly added "MuiButton, regardless of the product + project-specific class (Mui-Md, Mui-Joy, Mui-Base)". It keeps the class names simple and familiar, does not introduce breaking changes in Material UI, and allows customization per product if needed.

[oliviertassinari]

Could we have an example of what the DOM is going to look like for say, a text field?

[michaldudak]

This could be either

<div class="Mui-Md MuiInputBase-root MuiOutlinedInput-root MuiInputBase-colorPrimary MuiInputBase-formControl css-1x5jdmq">
  <input id="outlined-basic" type="text" class="MuiInputBase-input MuiOutlinedInput-input css-1x5jdma" />
  <fieldset aria-hidden="true" class="MuiOutlinedInput-notchedOutline css-1x5jdmz">
    <legend>
      <span>Outlined</span>
    </legend>
  </fieldset>
</div>

or

<div class="Mui-Md MuiInputBase-root MuiOutlinedInput-root MuiInputBase-colorPrimary MuiInputBase-formControl css-1x5jdmq">
  <input id="outlined-basic" type="text" class="Mui-Md MuiInputBase-input MuiOutlinedInput-input css-1x5jdma" />
  <fieldset aria-hidden="true" class="Mui-Md MuiOutlinedInput-notchedOutline css-1x5jdmz">
    <legend>
      <span>Outlined</span>
    </legend>
  </fieldset>
</div>

I think the first option makes more sense as you could have a slot populated with a component from another library (say, Joy's Input in a Material UI's Autocomplete). Using the first option would lead to less ambiguous code:

<div class="Mui-Md MuiAutocomplete-root">
  <input class="MuiAutocomplete-input Mui-Joy MuiInput-root" />
</div>

vs

<div class="Mui-Md MuiAutocomplete-root">
  <input class="Mui-Md MuiAutocomplete-input Mui-Joy MuiInput-root" />
  <!-- ^ is the .MuiInput-root from Joy or MD? -->
</div>