1. Easy to learn and use

‍
We used MobX over its rival Redux for a variety of reasons. Even though on directness and simplicity alone MobX has proven to be the superior alternative, some of the more critical use-cases where Redux proves to be a little more complex than MobX are listed below:
o    Handling async actions with redux-thunk
o    Simplifying your code with redux-saga
o    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, the handling of these is provided out of the box.

2. Less code to write

To implement a feature in Redux, you need to update up to four artefacts. This includes writing code for reducers, actions, containers and components. This is particularly cumbersome if you’re working on a small project. MobX only requires you to update two artefacts (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 @observable and @observer, you can easily make plain JavaScript components and their stores reactive. If you prefer functional programming, no problem — that’s supported as well. Redux, on the other hand, is heavily geared towards functional programming principles. However, you can use the redux-connect-decorator library if you want a class-based approach.

4. Dealing with nested data is easy

‍
In most JavaScript applications, you’ll find yourself working with relational or nested data. To be able to use it in a Redux store, you’ll have to normalize it first. Next, you have to write some more code to manage tracking of references in normalized data. In MobX, it’s recommended to store your data in a de-normalized 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.