For MobX newbies, take a quick look at this introduction written by MobX’s creator. You can also work through this tutorial to gain some practical experience.
The code for the projects mentioned in this article can be found on GitHub:
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 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 will have to deal with:
Handling async actions with redux-thunk
Simplifying your code with redux-saga
Define 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 are working on a small project. MobX only requires you to update at least 2 artifacts (i.e. the store and the view component).
3. Full support for object-oriented programming
4. Dealing with nested data is easy
In MobX, it is 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 which 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 will 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?%