Move from Redux to Mobx

[lhennerley]

Below is an extract of an internal Wiki page by one of our engineers @kraine93, who is a part of our "front end workstream" - all the guys in our work stream agreed with the summary and raised a PR to our starter pack to switch from Redux to Mobx.

Intro

As a part of a project using the framework, some time is being taken to evaluate how we are using React to ensure we have the right framework to support our projects going forward.

Before starting the first screen, we need to decide on a state management solution by evaluating MobX as opposed to the current implementation of Redux Toolkit.

Interesting Reads:

https://habr.com/en/post/480692/

https://blog.logrocket.com/redux-vs-mobx/

https://mobx-react.js.org/recipes-context#multiple-global-stores

2 Different Approaches

Redux & MobX solve the same problem, but approach it in different ways and with a different structure and data flow.

Redux: A single immutable store for your application. State is never updated directly, instead manipulated by dispatching actions which update the global state inside a reducer. Redux-saga is used to initiate side-effects such as API access, etc.

A ‘slice’ of state in Redux Toolkit with actions/reducers, & the ‘saga’ that triggers the side effect.

MobX: Multiple stores that use observables to track changes to state. State can therefore be directly modified and doing so triggers component updates. Side-effects can be triggered as a reaction to changes in state.

A store in MobX with observable properties can be modified directly and trigger side-effects, component updates & @computed properties. Using reaction we can trigger an API call on first load, and when the currentPage or filter values change.

Pros & Cons

MobX

Pros:

• Lightweight
• Fairly straightforward syntax
• All state logic for a store is contained in one file
• Flexible approach / different usage patterns

Cons:

• Possibly too flexible - need to decide on one approach and use it globally
• Components need to be defined as an observer (possible refactoring if we move away from mobx in future)
• Not easy to debug since updates happen auto-magically

Redux (Toolkit & Saga)

Pros:

• Structured approach - separation of concerns
• More widely used / bigger community
• More predictable due to pure / immutable state
• Actions & side-effects are defined separately

Cons:

• More boilerplate code
• Functional programming concept is more of a learning curve

Overall thoughts

MobX was quite easy to implement and the main benefit seems to be it's simplicity.

I was able to get it working in a similar configuration to redux toolkit, ie. we can have multiple stores combined in a root store, and then access each store individually as we need it by using a hook. Also means we no longer need a store provider wrapper. 

MobX promotes use of its observable state properties over having local useState, as updating the observables directly will automatically keep all your components up to date.

There is an optional parameter to enable state changes only in actions (making it more structured and similar to redux) which is something we could consider, otherwise changes can be made directly into the state (not a negative just a different approach).

Either solution will work, however MobX may be easier to understand for most people, as long as we decide on the correct structure/approach and then stick with it.