Also, the optimistic updates with rollbacks in this implementation is pretty neat.
Mobx v/s Redux does kick off the OOP v/s Functional debate, but as a developer my productivity and effectiveness is measured in terms of my ability to ship software not in terms of my programming style, and it's my personal belief that Mobx does make me more productive as compared to Redux.
For developers new to the whole Flux/Redux/Mobx/State Management world, I highly suggest to give Mobx a try.
I concur with giving Mobx a try. I'm using it at least one product so far and it's been working out great.
One thing I will say is that because your subscriptions are set up implicitly, it's easy to have things misbehave in unexpected ways. For instance, if you update multiple observable properties in a single function, it will fire off observers multiple times. That could put you into an unexpected state and cause some errors.
Luckily, almost every time I've run into this kind of issue, I've discovered there's an API to cover that case (runInAction in the previous example's case). And they APIs themselves are really neat and fun to work with. `when` and `observable.array`'s extensions are some of my favorites.
Also, just storing state in your higher level components can work for much more complicated apps than many think.
To elaborate: in 'response' to the webdev tendency I have to use the latest and greatest, and the HN articles about this phenomenon, I've done a few React projects with a conservative mindset.
React-router I don't miss too much for much of it. I could also do without a bunch of ES6/7 features, TypeScript, and so on. But with each of these projects I wish I'd used Redux, MobX, Baobab, and so on instead of the 'vanilla' approach of keeping state in my higher level components.
tl;dr: if you're gonna be conservative, leave state management as the last thing you 'conserve' on.
Usually I start an app like this and when things get really complicated I add Redux and refactor the state management out of my top component.
MobX looks interesting, however didn't get to try it out yet, only briefly looked over it. I find it a bit annoying that they introduce even more syntax overloading - annotations - as if ES6/7/JSX is not enough already. Will give it a try on a pet project soon.
That said, these days I would never use anything but Redux. MobX is gaining traction as a viable alternative, but I just love having all possible mutations spelled out explicitly.
> a JavaScript persistent and immutable (at least by default) data tree supporting cursors and enabling developers to easily navigate and monitor nested data through events.
It's a fairly simple library to read and understand and it's well written. I have a couple decent sized SPAs working on top of it, and I store the full data tree using localForage for offline use.
Here is a comparison.
The architecture is very similar - I think it was the inspiration behind Redux. You get to use a more succinct syntax and there is a compiler underneath it that supports the whole process. I have only recently started with it, bit I am finding the adage that 'if it compiles it will work' is proving remarkably accurate.
It offers more than one strategy for managing state; there is simple two way binding between a JS object and the DOM, there is the Elm-inspired vuex, and also it can integrate with Redux. http://vuejs.org/v2/guide/state-management.html
Before Redux came out, I built my own state management system around Backbone. I recommend using Redux.
This approach matches well with GraphQL (without Relay -- but with Relay I imagine it would fit even better).
[1]: technically apollo client uses redux internally but they keep it nicely wrapped for you
It's also a lot of boilerplate when you just want to add a simple toggle to some component.