I've been using mobx-state-tree for the latest couple of projects after Redux. I like them both, but I prefer mobx-state-tree for a handful of reasons.
1.) There is an immutable data store with action-driven changelog, just like Redux.
2.) The immutability of the data store is baked in and enforced. The necessity to provide changes to the data store within an action is baked in and enforced.
3.) Having actions baked in as methods rather than having to create "action creators which in turn dispatch actions" is a nice reduction in boilerplate.
4.) Being able to add action listeners AND state listeners are baked in, and can be done at any level of the state's depth. To watch state changes in redux, for global changes not related to a particular component, I had to write:
https://github.com/ralusek/redux-store-watch
5.) Mobx's observers on react render methods makes the renders far more efficient than what could be achieved with react-redux easily, without really ensuring that the props being passed in are as granular as necessary or shouldComponentUpdate is correctly identifying state changes. In mobx, the most granular access of the lowest level state can be detected within a render method, and only when that very specific value is replaced is the component rendered.
6.) Computed values on mobx-state-tree are baked in without the need for something like reselect
I like Redux, I enjoy working on projects that use it, but I think that I think I'd have to admit that I prefer mobx-state-tree.
We've been using mobx-state-tree too. What I like is that it's easier to gain an understanding of the moving parts of my application; how actions, derived data and data work together. On the other hand the support for Typescript is a bit clunky and leads to slow compilation. Mitigating the compile time leads to a bit of boiler plate.
Couple of questions - with mobx-state-tree are there ways of handling side-effects nicely? E.g. an equivalent to redux-observable epics (or redux-saga sagas)?
In regards to #5 redux there's a pattern to use selectors (which can be memoized with reselect), which means that whether components update is a simple shallow === comparison on their data props, and also a handy abstraction for getting data out of a potentially deeply tree and applying transforms to it.
Performance was my main concern with MST, most notably if your data modelling involves A LOT of entities, things can get slow: https://github.com/mobxjs/mobx-state-tree/issues/440. Binding methods on every instance of an object is a lot of overhead.
I really liked using MST when I spent a few days fiddling with it. However, I really don't want to get trapped with perf bottlenecks I can't easily fix. Whether I'd actually run into trouble - I have no idea, but vanilla MobX is excellent enough that I'm happy sticking with it. I'd love to use MST more though.
I investigated MST for a React Native project and found the the additional overhead it created for frequent state updates was too much - in a synthetic test updating state every frame, it resulted in a 30-40% increase in CPU usage on a real device vs. plain MobX which for our application probably isn’t acceptable. If you know you won’t be making really frequent state updates or CPU constraints are less important it seems like a great option!
Mobx is not immutable. The tree is protected from modifications outside of it, but functions you define on the tree can freely modify all the nodes that they own. It's managed mutable state, much like a database.
Vue comes with computed property out of the box. That is something I miss in react where I have to write small helper functions to compute stuffs from the state.
It's a shame there's no reference in the README. Makes it seem like they don't take testability seriously, which for me is a major plus point of Redux.
1.) There is an immutable data store with action-driven changelog, just like Redux.
2.) The immutability of the data store is baked in and enforced. The necessity to provide changes to the data store within an action is baked in and enforced.
3.) Having actions baked in as methods rather than having to create "action creators which in turn dispatch actions" is a nice reduction in boilerplate.
4.) Being able to add action listeners AND state listeners are baked in, and can be done at any level of the state's depth. To watch state changes in redux, for global changes not related to a particular component, I had to write: https://github.com/ralusek/redux-store-watch
5.) Mobx's observers on react render methods makes the renders far more efficient than what could be achieved with react-redux easily, without really ensuring that the props being passed in are as granular as necessary or shouldComponentUpdate is correctly identifying state changes. In mobx, the most granular access of the lowest level state can be detected within a render method, and only when that very specific value is replaced is the component rendered.
6.) Computed values on mobx-state-tree are baked in without the need for something like reselect
I like Redux, I enjoy working on projects that use it, but I think that I think I'd have to admit that I prefer mobx-state-tree.