Redux is a state container manager which helps to build applications with consistency and ability to run in different environments. It is based on Flux architecture and has actions, creators, and reducers. Actions are JS objects attached with type property defining the type of action and acts as the source of data for the store. Action creators as suggested by the name are the functions to create actions. Each action creator calls a reducer to receive the data and update the state. Logic lies under actions whereas reducers are used to update the state. It also allows editing the live code with a time-traveling debugger ensuring a great developer experience.
Similar to Redux, MobX is also a state container manager but reactive. MobX introduces new concepts like observables – properties of the state object, observers – React components to monitor the state changes and actions – triggers a change in the observables.
Both are open-source libraries and used for client-side state management. They are not tied to a specific framework and have extensive support for React/React Native frameworks. Both support time-travel debugging via the redux-devtools-extension.
- Solid conventions: The enforced strict rules makes it beneficial for large team app development.
- Immutable State: It applies the changes to a copy of the current state and returns a new object.
- Time travel: It allows to perform actions like redo, undo and time travel by keeping copies of past state changes eg. snapshots of time.
- Dev tools: To test and monitor the state changes, it has a good set of development tools.
- A state is predictable and stored in a single object tree.
- Hot reloading out of the box.
- Ability to log everything.
- Easy to debug and test without a browser.
- There is only one way for data to flow.
- It takes a while to learn and implement
- Due to strict rules, sometimes it hinders to gain momentum from functional programming.
- Lack of documentation.
- It doesn’t support decorators yet.
- Lots of code: Redux has a lot of boilerplate.
- No batching to update the state, the state is updated immediately leading to unnecessary renders, more code, and conditions.
- An extra library known as thunks is required to perform any event after the action because the state is updated immediately. It allows action creators to return functions.
- References are difficult to manage as actions have to be moved outside the components, making any defined refs within the components useless.
- Work becomes slower in order to follow a pattern.
- Steep learning curve
- Better choice than Redux for a small project.
- Faster development
- Decent community
- The learning curve is very low. No need to understand a new data flow to get started.
- Less refactoring and boilerplate
- Open to any architecture
- No thunks or middlewares
- Stores can be anything as simple as possible, maybe an object.
- No need to learn or understand the concept of Flux
- A user has the choice for how to maintain state making it more flexible.
- With a large team and enforcing an architecture becomes necessary else it may lead to mess each person doing things in his own way.
- An observable array is wrapped in an ObservableArray object. So whenever you need to pass it to the component allowing only pure arrays, they need to make pure by array slicing.
- Easy to build anything even in a poor way.
MobX or Redux?
If you are planning a project with a large team, you should go with Redux because that will enforce coding convention making it easier to maintain. However, if it has to be maintained by you, or a handful team, MobX will be preferable. The developer community of Redux is way ahead making it favorite but Mobx is an impressive alternative to it.