On my view. I think we should use Mobx instead of Redux.
1. Easy to learn and use: With MobX, all these situations are “magically” taken care of. You don’t need additional libraries to handle such situations.
Mobx library has a lot of solutions for mentioned problems. It is based on 3 points: state, derivations and actions.
2. Don’t need to write much code: MobX only requires you to update at least 2 artifacts (i.e. the store and the view component). With Redux, you need to update at least four artifacts (reducers, actions, containers and components)
3. Mobx has good support for object-oriented programming:
I agree with you with those points, but it aslo has some disadvantages
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.
it’s 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.
I don’t think so Redux is heavily influenced by Functional Programming principles:
It encourages use of “pure” functions, wants you to handle your data “immutably” (ie, make copies and modify the copies, don’t directly update the original values), and focuses on explicit definitions of data flow and update logic.
It gives you features like the ability to do “time-travel debugging” (stepping back and forth between individual updates to your state, or loading in a copy of the app state from a customer crash report to see what was going on).
Idiomatic Redux code “normalizes” nested or relational objects, like a database. Each item is defined in one place, and other parts of your data would refer to that item by ID only, leaving lookups for later
The usual complaint is that there’s too much boilerplate code, and that typical Redux usages involves things like string constants and switch statements.
Use it when you want to explicitly track the flow of data through your application, or want to see exactly why your application wound up in a certain state.
When I first saw both of them I liked mobx, didn’t fully understand redux and used mobx in a small project. Mobx makes to mutate your observable object through actions and run all observers. But when I wrote a lot of code, it became hard to understand the code, debugging was painful. I couldn’t find best practices for making different requests.
For the next project I used redux and I loved it. It is a bit hard to understand, but when you get into it, you are surprised how simple it is. The only frustration was in writing a lot of code, so I started developing this library https://github.com/iamawebgeek/redux-data-entity