I've dug quite a bit into Redux and I don't think that's really true. In particular I don't think you "choose" to bring in that complexity. Redux is inherently complex the moment you add async actions to it, which (in my view) any real Redux app will need. Something as simple as "fetching some data when you click a button" is a surprisingly elaborate process. Similarly, trying to map a large state tree (which any real Redux app will have) to a component tree is not easy. Libraries like reselect and redux-saga (or event redux-thunk) sprung up and became essentially universal because they address the inherent complexity of Redux.
I just don't think it makes sense to tease out a small chunk of the code a Redux app needs to function and say "look, this chunk is small!"; it's true but meaningless.
MobX is dead simple, it's a short write and here's how it works:
- observables: add a getter/setter pair in place of the property - when it gets modified emit an event. - observer: when an observable getter gets called inside the `render` in React - listen to future updates and re-render. - computed: do the same thing as observer - but emit the value instead of rendering.
All MobX does is change detection, it has a very low API surface, it can be implement in a lot less code (but optimizes heavily) and it is one of the simplest packages I worked with without middlewares and connectors and selectors and so on.
In Redux you have a dispatcher, actions, a reducer and so on. In MobX you just have plain JavaScript objects for state and plain functions. MobX also composes much better with things like Rx.
Also their naming of the features could have been better. For example "reducer" makes sense ONLY after you understand what's going on. It should be the other way around--the naming should be intuitive enough to actually help me understand the concept easier.
A lot of physics theories are distilled down to a single equation, but that doesn't mean it's simple concept to understand. I personally think a library with 10000 lines of code that operate using setters and getters is much more simple to understand than a library with 100 lines of code that has all these esoteric concepts.
The author goes through it line by line here:
https://youtu.be/TfxfRkNCnmk?t=15m59s
It looked "magical" and tripped up my "too good to be true and I'll have problems later" sensor. Then I looked at that video and realised the idea is rather simple and brilliant.