Redux vs MobX: Which Is Best for Your Project?
The code for the projects mentioned in this article can be found on GitHub:
If you enjoy this post, you might also like to sign up for SitePoint Premium and watch our course on working with forms using React and Redux.
What Do Redux and MobX Have in Common?
First, let’s look at what they both have in common. They:
- are open-source libraries
- provide client-side state management
- support time-travel debugging via the redux-devtools-extension
- are not tied to a specific framework
- have extensive support for React/React Native frameworks.
4 Reasons to Use MobX
Let’s now look at the main differences between Redux and MobX.
1. Easy to learn and use
For a beginner, you can learn how to use MobX in just 30 minutes. Once you learn the basics, that’s it. You don’t need to learn anything new. With Redux, the basics are easy too. However, once you start building more complex applications, you’ll have to deal with:
- handling async actions with redux-thunk
- simplifying your code with redux-saga
- defining selectors to handle computed values, etc.
With MobX, all these situations are “magically” taken care of. You don’t need additional libraries to handle such situations.
2. Less code to write
To implement a feature in Redux, you need to update at least four artifacts. This includes writing code for reducers, actions, containers and components. This is particularly annoying if you’re working on a small project. MobX only requires you to update at least two artifacts (i.e. the store and the view component).
3. Full support for object-oriented programming
If you prefer writing object-oriented code, you’ll be pleased to know you can use OOP to implement state management logic with MobX. Through the use of decorators such as
4. Dealing with nested data is easy
In MobX, it’s recommended to store your data in a denormalized form. MobX can keep track of the relations for you, and will automatically re-render changes. By using domain objects to store your data, you can refer directly to other domain objects defined in other stores. In addition, you can use (@)computed decorators and modifiers for observables to easily solve complex data challenges.
3 Reasons Not to Use MobX
1. Too much freedom
Redux is a framework that provides strict guidelines on how you write state code. This means you can easily write tests and develop maintainable code. MobX is a library and has no rules on how to implement it. The danger with this is that it’s very easy to take shortcuts and apply quick fixes that can lead to unmaintainable code.
2. Hard to debug
MobX’s internal code “magically” handles a lot of logic to make your application reactive. There’s an invisible area where your data passes between the store and your component, which makes it difficult to debug when you have a problem. If you change state directly in components, without using
@actions, you’ll have a hard time pinpointing the source of a bug.
3. There could be a better alternative to MobX
In software development, new emerging trends appear all the time. Within a few short years, current software techniques can quickly loose momentum. At the moment, there are several solutions competing with both Redux and Mobx. A few examples are Relay/Apollo & GraphQL, Alt.js and Jumpsuit. Any of these technologies has the potential to become the most popular. If you really want to know which one is best for you, you’ll have to try them all.
Continue reading %Redux vs MobX: Which Is Best for Your Project?%