MobX – Simple, scalable state management for React

I was able to rebuild a week's worth of Redux work in MobX within a day. And that's having never used it before.

What's crazy is how MobX is able to update React child components without updating the parent first. It knows which properties are accessed in each component, and ensures only the ones that rely on the changed data are updated.

I'd say give it a shot the next time you have a component with internal state. Not having to worry about the reducer or how the component gets updated is refreshing.

I have written a fairly big open source React + Redux application https://github.com/rwieruch/favesound-redux and refactored it to use MobX instead of Redux https://github.com/rwieruch/favesound-mobx I hope I can add some extra value to your post.

I agree that for most users Redux feels like a lot of boilerplate. At the same time I think most people underestimate were we came from. Personally I wrote a huge amount of Angular code before and at a certain point I felt very unhappy about the two-way data binding and state handling in Angular. It was unpredictable in a huge code base at some point. Then it was the time of Flux and in our company we introduced a stores and unidirectional data flow implementation of our own. Afterwards Redux got announced and we loved the clear constraints and lightweight API from the beginning. We use it now.

In a team of developers everyone can clearly follow state changes, the state itself and the places from where the state changes were triggered. Redux is scaleable and shouldn't be used for every small project which could live without a state management library and should use setState instead. Redux simply works, even though you have already a big amount of actions in production.

I think MobX is on the right path to give an alternative way for state management. For now I see a clear benefit to kick off smaller projects in smaller teams which don't rely on Redux' constraints and scaleability. Little feature op-tins like useStrict will help MobX to have a more scalable state management system. Otherwise in a growing code base it will feel like the old Angular days with two-way data binding. In the end that is the power of MobX, because it isn't opinionated: You can either mutate your state directly in a component or build a proper infrastructure around it to make it scale.

Adding some more:

Refactor a Redux Application to use MobX http://www.robinwieruch.de/mobx-react/

Large MobX React Application https://github.com/rwieruch/favesound-mobx

> It knows which properties are accessed in each component, and ensures only the ones that rely on the changed data are updated.

This is what blew me away. I understood that "computed" values were doing this, but when I saw that the react components were using it as well, I was sold. I have been in componentWillReceiveProps with redux too much, trying to improve rendering performance. With mobx, out of the box, you get 100% exact render updating.