Если разделять стили на визуальные и структурные/каркасные то можно сделать для них разные стратегии кастомизации по умолчанию

Стратегии

visual

Заменяются полностью. Можно импортировать Component.classesили мб даже Component.stylesчтобы сохранить стоковые стили тоже. Сохранять визуальные стили опасно, т.к. это делает миграцию на мажорные версии сильно сложнее Часто лучше скопипастить оригинальные визуальные стили и поправить как нужно

frame

Из коробки вообще не кастомизируются. При непосредственном использовании в «бизнес-логике» они не должны затрагиваться Но они должны поддаваться кастомизации внутри библиотеки чтобы создавать производные компоненты.

? А что еслив бизнес-логике требуется такой компонент с изменёнными каркасными стилями

лучше написать свой или запросить сделать его в библиотеке

Другие опасности и тонкости

• иногда в .rootчто-то завёрнуто, тогда его установка будет ломать все внутренние стили
  • не давать пользователю root, вместо этого className. Не удобно с withStyles
  • не заворачивать ничего в root. Не удобно с .root > .child
  • изменить для root стратегию и сохранять исходные стили всегда. Как сделать сброс?
• вложенные MUI компоненты со своими classes конфликтуют
  • делать всегда вложенные classes?
  • делать отдельные fooClasses, barClasses,,,
• некоторые классы предусмотрены для задания пользователем, а другие не очень для этого подходят. Как их разделить?
• MUI не сбрасывает свои классы при установке classes. а sun сбрасывает, а так же экспортирует defaultClassesдля сохранения. Не консистентно. Как сбрасывать в MUI?
• классы дочерних компонентов и их состояний описываются в перемежку
  • если придерживаться конвенции .root, .child, .childState, то с этим можно жить (БЭМ-БЭМ, ага)

related: Usage/Config segregation