Compare MobX and Redux

Tram Ho

Previously, I had time to work with Redux in state management, after that, I had the opportunity to know mobx. But until now there is a chance to experience to use it in the project. From my experience and reading some articles, I would like to allow a little comparison about MobX and Redux in state management in React projects.

1) One Store and Multiple Store

Store is simply defined as 1 place you will use to store all data of the app.

For Redux, it is a large store used to store the entire state, but in some large-scale apps, you can see that the big store will be divided into smaller reducers for easier management, but even so It is still used in the spirit that there is only 1 store.

And in MobX, you can use multiple stores to store and manage your state so that you can see the most effective.

2) Plain data and Observable data

Redux simply stores the data and if you expect the app to re-render when the data changes, you will most likely have to do it.

Unlike Redux, Mobx uses observable to store data, which means that if you change the data stored by observable, you change it, it will re-render without having to touch a lot. That’s convenient, for example:

Your App will be re-rendered with new data after the demo has changed. 3) Immutable data and custom data

In Redux, the state will always be immutable, when the store receives a state it will return a corresponding new state, and not change the receiving state, for example:

As the example above, you can see that Redux will return us a new state, and not change the old state, so we can treat Redux to act as a pure function. In the previous example with MobX, we could directly change the state’s data.

4) Accessibility

Through these comparisons, you can vaguely realize that MobX can be used more gently, with less code, and the re-render app has been handled by MobX for you. Whereas with Redux, it could be a long story (of course, the code is also long). So MobX is much more accessible, but it’s no coincidence Redux is still a popular tool for state management. We learn it in the next reason

5) Debug

In Redux, if you want to change a state, instead of dispatching the corresponding action, then with the newly received state, we also have to deal with it to affect the re-rendering of the app. Although there are so many steps, but when debugging, you can ‘chisel’ each step to see where the bug is and handle it there. Moreover, even if you do another project, if that project uses Redux, this process will not change its core. As for MobX, to be honest, you can still go through the action to change the state in mobx, but no one will force you to. You can create your own process for each of your projects. Even in a project there may be many different processes. Another important thing, because MobX automatically checks the rendering, if there is a bug, during re-render, you will not be able to investigate each layer like redux.

6) Medium and large projects

For small and medium projects, you can customize, use many state management methods and do not worry about maintenance time, and fix bugs => MobX suitable for small and medium projects. But with big projects? Is it not used? Of course. However, in large projects, the process unification, maintenance, and management are raised to a new level, it requires consistency, consistency, tightness. like how venom sells onions to TA)

After this article, surely you also have a better overview of MobX and Redux, if you have something wrong, hope you can have additional comments below, thank you for reading the article of yourself.

The article has a link:

Share the news now

Source : Viblo