Migrate to MUI v5

[WilliamKelley]

For almost a whole year now, Material-UI has been moving to v5 and leaving v4 in critical-fix-only mode. For at least the past few months, the maintainers have actually suggested new projects start with v5.

~The v5 branch, next, is currently in late alpha, v5.0.0-alpha.35, and will soon be coming into beta. Obviously v4 -> v5 will involve breaking changes which is acceptable, but the danger of adopting an alpha is accepting even more breaking changes between alpha. By the time beta comes, that danger will pass.~

~With that in mind however, I think we would be fine to adopt a late alpha without fear or many, or any, breaking changes that affect us before beta. This lack of danger is primarily due to how few components we have and that our customizations access api's that are well established and not liable to change -- unlike lab components, or just more in-depth props in general.~

[Edit: v5 is now in beta.]

Migrating to v5 would be beneficial for many reasons

• core ability to define custom variants and sizes for components at the theme level
• core integration of an emotion styled api (basically a super-set of styled-components)
• several, important to us, lab components move to core with stable api's: Autocomplete, Pagination, Alert, ToggleButton and probably important to us: AvatarGroup, Rating
• integration of date and time pickers from a community add-on to core-developed (includes breaking changes for a more stable, thoughtful API and styling)
• introduction of sx prop from emotion, available on any component for one-off styles -- replaces Box from v4 and is the best, easy alternative to inline styles

Resources:

• v5 RFC
• v5 documentation site
• v5 migration guide

We need to consider the situations of teams who

• currently use Spark
• want to use Spark in the future AND are using Material-UI v4

Since the next versions of Spark will contain breaking changes to almost every component, we really only need to consider the migration cost of consumer's existing usage of Mui v4 to v5, not Spark usage.

Questions for Consumers

• After reading through Mui's v5 migration guide, is the cost of migrating your current, non-Spark usage of Mui acceptable as a barrier to using Spark?

  • If not, 1) would you like us to maintain Spark for BOTH Mui v4 and v5?
  • or, 2) would you like for Spark to bundle Mui v5 as an internal dependency, and re-export all necessary parts of the package?
  • pros: you dont have to migrate existing v4 usage
  • cons: increased bundle size, hassle of Spark as a middle-man, potentially confusing

• Do you have any comments or requests you would like Spark to consider in regard to this migration?

[WilliamKelley]

Looks like v5-beta is scheduled for July 1st (milestone). Judging by the latest alpha PR, they're on track for that.

I think we should plan to migrate in July.

We need to come up with how to handle this for dependents.

Currently we depend on a peer of @material-ui/.... Keeping it this way would help the story of #75, right? Then we advise consumers to migrate their existing MUI use before updating us.

Thoughts?

[siriwatknp]

@WilliamKelley material-ui has migration to v5 docs. I will update it to be more of steps to follow soon. Once it is updated, would love to get your feedback.

[WilliamKelley]

@siriwatknp I appreciate it! I'll be sure to give feedback and ask other team members to do so as well

[seigler]

is the cost of migrating your current, non-Spark usage of Mui acceptable as a barrier to using Spark?

IMO for Prenda World this is "yes". Currently PW uses Material UI components in 110+ files, so the migration is substantial but worthwhile, since in addition to simplifying Spark development and maintenance, it will help us avoid doing new development on an old version of Mui.