One of our engineers at StackShare suggested it and it's fantastic.
Mobx is very simple to understand and will make writing a "React" page a real joy again. Redux was way too complicated for what it gave, and just shot term after term after term at me that left me with a headache. I still don't understand Redux proper.
>Why do you have to type so much?
I know! I nope'd away from Redux because of that same reason.
But Mobx clicked for me. And if it clicked for me, it'll click for you.
Basically you have a store and you use that store anywhere in your components to share store state. When you update that store state everywhere else updates as well. Simple.
Another great reason to use React as opposed to alternatives is react-native. A _lot_ of knowledge transfer between the web and mobile with react native. It's pretty insane.
 - https://stackshare.io/stackshare/stackshare
You can just think of it as "automatix redux + reselect".
People think they use redux for immutability but in my experience most people just use it for updating the view when the store changes and end up with a lot of denormalization and stale state.
With redux you derive as much state as possible which is great.
It says "simple" but looks complicated. Any pointers? Is it because I don't know how decorators work it looks complicated?
If you have a property you need observed - add a `@observable`.
If you have a react component you want to update automatically, add `@observer`.
Derive as much as you can using `@computed`. You can but shouldn't use `autorun` which monitors side effects.
If you're already used to Vue it's very similar except it works with React.
That's pretty much it - just clone a boilerplate - the API surface is _tiny_ and everything "just works". I have a hard time describing how stupid I felt for using Redux after playing with MobX for 10-20 minutes.
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.
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:
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.
1. New JS decorator syntax
2. ES5 getters and setters
If you know those (and none are especially complicated), then I think the cognitive overhead of MobX is basically zero.
I liked Redux when I experimented with it, but it is not a panacea, the advantages you gain are not entirely for free, and it might not be worth the boilerplate and complexity if you don't have a very complex application.
So cool, you nailed that down vanilla - you're awesome.
Or you can just Mobx and not worry about it.
It's not like you're forced to use Mobx. Even when I worked with Windows Forms in .NET 2.0 you still had to have some way to keep values in sync, and instead of "Mobx" you had some home-grown monstrosity.