Investigate Material-UI upgrade effort in Timliner

[Dananji]

Description

We've compiled multiple a11y issues based on the accessibility audits performed on timeliner (in both Avalon and standalone versions).

Some of these are rooted in material-ui components used in the timeliner code, e.g. MUI's slider and dialog components. These 2 are highlighted in the a11y issues compiled in the audits.
And looking at these components in the latest MUI version, these a11y issue seem to be fixed in the MUI code.

And this poses the question whether we should upgrade MUI in timeliner?
Going forward with the existing older version exposes the app to security vulnerabilities (these might not directly impact Avalon?), blocking access to bug fixes in MUI/ReactJS and other dependencies in Timeliner code, and making it more complex to upgrade in the future. At the same time we'll need to keep making fixes locally adding more code making it harder to maintain.

From my brief investigation the following dependencies will definitely need to be upgraded as a result of this migration. This would require a larger effort even if it's done in phases.

Package	Current	Required for MUI v7
React	16.8.6	18.0.0+
React-DOM	16.8.6	18.0.0+
React-Redux	5.0.7	8.0.0+ (for React 18)

And there maybe more minor dependencies that will need upgrading during migration, since we would be upgrading the base React version in timeliner.

Major breaking changes from a quick search;
In MUI,

• v3 -> v4
  • Changes to React ref forwarding
  • Style naming with respect to class-names
  • JSS framework updates
  • Changes to component APIs
• v4 -> v5
  • Package renaming and installation
  • Styling solution change (JSS to Emotion)
  • Theme structure and API changes
  • Some component-specific changes
• v5 -> v6
  • Minimal breaking changes in MUI, however changes to platform and bundle sizes are applied in this upgrade
• v6 -> v7
  • Changes to package structure
  • Removal of deprecated components, styling, and APIs
• React 16 → 18, ReactDOM.render() → ReactDOM.createRoot() and other related changes
• Changes to MUI's API and React upgrade might require class components to be converted into functional components
• Redux 5 -> 8, store setup and usage may need changes

Done Looks Like

• Compare the efforts to upgrade vs fixing the a11y issues without upgrading
• If continuing the upgrade path,
  • Investigate the best approach for the upgrade and devise a plan including testing
  • Identify whether there are any changes for the build process with the upgrade
  • Check for other breaking dependencies

[Dananji]

Reasons to upgrade from v3 -> v7:

• Security
  • MUI v3 is 6 years old (2018) with no security patches or bug fixes
  • Old dependencies have known vulnerabilities, which we are not able to address older libraries
  • Other dependencies are stuck on older versions
• Maintainability
  • MUI v3 has no active support
  • Harder to find solutions to issues that arises with v3 components, e.g. volume event handler bug that was fixed using JavaScript event API values
• Performance
  • MUI v7 has better tree-shaking and smaller bundle size
  • React-Redux 5 is outdated, limiting Redux tooling options which could affect performance
• Features
  • Access to updated MUI components
  • Better built-in accessibility support — some of the a11y fixes we're doing manually come out of the box, e.g. focus trapping in Dialog components

Reasons not to upgrade from v3 -> v7:

• Effort
  • This will take a much larger effort than fixing bugs as they come up
  • The effort might be a continuous block of time spanning across multiple sprints rather than smaller efforts to fix bugs as they arise
• Risk
  • There's a high chance for regressions, since this is a bigger jump
  • Some Timeliner components would need re-writing to use new hook architecture
  • The changes to the Redux and React will require major changes to the state management, which is complex as it is
  • Some MUI components have been completely redesigned, which would need a comprehensive understanding of the components to swap these to new components
  • Even with testing in phases, we could miss intricate bugs. E.g. state management upgrade
• It Works Today
  • Timeliner is functional on MUI v3 and React 16
  • We're successfully working around v3 issues as they come up
  • Avalon is not blocked on using Timeliner due to the out-dated dependencies
• Smaller gains compared to the effort
  • Most of the benefits (tree-shaking, smaller bundles, sx prop,..) that comes from upgrading are developer experience improvements, not particularly user-facing
  • MUI v3 has all the components needed to build Timeliner interface, so it doesn't need any added components in the latest version
  • Security risk is lower for Timeliner used inside Avalon?

Possible upgrade paths:

1. Direct upgrade from v3 -> v7

• This will take a continuous effort to finish the work, thus there will be no intermediate phases
• There's a high risk of breaking everything at once, which could make fixing things harder resulting in a much larger effort that is hard to plan
• There's no rollback path
• Testing will be harder, since everything is changed at once making it harder pinpoint issues in testing and then eventually fixing them

2. Incremental migration from v3 to stable versions in-between until we reach v7

• This will take longer, but the work can be split into phases therefore this can be done alternating between other work
• With each phase we'll have a stable app that can be tested hopefully with less issues for each testing phase
• Gives the option to rollback to a stable version, and pause if necessary without upgrading all the way to v7
• Dependency management in the intermediate phases could be difficult

Looking at these I think we have the option to migrate or not to migrate.

Summary:

• Migration will give us more flexibility to;
  • add new components to the interface and do changes easily
  • use latest features in React and MUI like built-in a11y features
  • reduce the security vulnerabilities in Timeliner (at least in standalone), possibly this is not a factor in Avalon?
• Timeliner doesn't require a migration because,
  • it is stable with the current versions of React and MUI, except for a couple small bugs from time to time. And these small bugs don't require as much effort compared to a migration
  • at the moment, there are no requirements for new feature work
  • Timeliner doesn't need the new components added to MUI since v3