Discovery: Build or find a simpler alternative to Redux

[jmakowski1123]

Problem

The use of Redux is encouraged via frontend-platform, but given the size of most MFEs, it is likely overkill

Product/Platform Value

Ultimately, this impacts adoption: the easier it is to develop new features, the more useful the platform will be.

Acceptance Criteria

Related or in-progress work

2U has written up an ADR for the Enterprise line of MFEs that summarizes the issue nicely and also proposes a solution. (A solution that is already in production in some of those MFEs.)

Opencraft has proposed providence as an alternative to Redux, but no coordinated effort has yet happened to futher its adoption.

Contingencies

[brian-smith-tcril]

This feels like something that should be addressed on an MFE by MFE basis to me. Some MFEs rely heavily on state management, in which case redux or a replacement makes sense. Some MFEs could probably just have Redux completely ripped out and still work with vanilla react state management.

Good next steps:

• Make a list of all the MFEs using redux
• Determine which MFEs need comprehensive state management
• Determine which MFEs could have redux ripped out without too much trouble
• Make issues on the respective MFE repos with plans for future state management, link those issues back to this issue.

[arbrandes]

@brian-smith-tcril, those are good ideas for next steps. I would also suggest, if the list of MFEs that don't need comprehensive state management is significant:

• Review light(er?) Redux alternatives, including Opencraft's providence, and choose one to recommend.
• Write an ADR with that recommendation and put it up for review

[adamstankiewicz]

For what it's worth, the edX for Business (Enterprise) MFEs have largely moved away from Redux in favor of vanilla React with context/hooks. A brief ADR about our decision for the Enterprise MFEs is captured here.

The Enterprise MFEs (listed below) are also arguably some of the more complex MFEs given how many page routes they currently support.

• frontend-app-learner-portal-enterprise
• frontend-app-admin-portal (still relies on Redux for a couple of things, but not much anymore)

[arbrandes]

@adamstankiewicz, that ADR is a great read. As far as I'm concerned it can be used as both the definition of this issue and one possible solution - though the fact it's already used in production is a very good indicator it might be the solution.

Thanks!

[adamstankiewicz]

[inform] I just recently ran an internal Frontend Study Group within 2U to explore how to build a simple UI with 4 different approaches, predominantly comparing implementations with vanilla React to Redux for state management. The final example showcases how to use context selectors to help mitigate the concern around unnecessary component re-renders when working with context.

I moved the wiki page for the study group session into the Open edX Confluence FED space for visibility related to this issue, if helpful: Patterns with React Hooks & Context (compared to Redux)

One of the primary goals was to inform folks about context selectors:

• RFCs about context selectors in core React:
  • https://github.com/reactjs/rfcs/pull/119
  • https://github.com/reactjs/rfcs/pull/150
• use-context-selector (Github)
  • Makes context selectors available in userland today.
  • We are currently experimenting with using context selectors in production for at least one feature within the frontend-app-admin-portal MFE.

[adamstankiewicz]

though the fact it's already used in production is a very good indicator it might be the solution.

@arbrandes It's worth mentioning that without the ability to subscribe to only a slice of a context value in truly vanilla React yet (without the help of something like use-context-selector), the hooks + context pattern does require engineers to be more cognizant of re-rendering issues in their application during implementation in order to prevent them where using a state management library (Redux or otherwise) largely abstracts this away.

We've also found that complexity increases as more context providers are introduced, where you end up with multiple layers of contexts that makes it a bit difficult to reason about the flow of data in the application. If a component requires data from more than one context provider in the component tree at once (e.g., we have some components that subscribe to 3-5 context providers at once), it makes test writing a bit more complicated because you need to ensure the component is wrapped in all those context providers with an appropriate value for each. We're experimenting with creating test utilities and helpers to begin addressing the latter issue.

Tradeoffs with everything :) That said, I don't know if vanilla hooks + context is the solution without exploring other options and mitigating some concerns.

[davidjoy]

We should be really careful not to build a bespoke version of a global state management library when a widely used one already exists in the broader community. I'm skeptical that we'd be better off building and supporting our own state management libraries, and that that would somehow be better for adoption than an industry standard. We can either spend our resources and time trying to make a slick solution to this ourselves, or we can let the entire JS community do it for us by continuing to evolve and improve redux, redux toolkit, etc.

[bradenmacdonald]

For what it's worth, I personally moved away from using Redux entirely several years ago and for another large frontend that I've been working on for a couple years (https://github.com/neolace-dev/neolace) I used vanilla React (context + hooks) along with SWR which is a super lightweight hook for fetching data with a ton of nice features. I've been super happy with this approach.

[adamstankiewicz]

Another library possibly worth considering is TanStack Query (previously known as react-query). It's similar in many ways to the SWR library @bradenmacdonald suggested above, but a bit more feature-rich and seemingly gives more granular control in comparison.