[zawerf]

I recently started looking at mobx-state-tree[1] and I feel like it solves a lot of the boilerplate needed with redux in a very nice opinionated way. In particular it has built in support for tracking action history (as list of patches and snapshot), building views of computed values (selectors), organizing async action flows, and colocating all of this logic in a single model class.

It can be used on top of redux but it won't really look like redux code anymore. But since you're using immer in the starter, it wasn't going to look like redux anyway (e.g., ton of triple dots everywhere).

Do you have any opinion on mobx-state-tree? Maybe you should just bless mobx-state-tree in the starter too? (immer is built by the same mobx guy)

[1] https://github.com/mobxjs/mobx-state-tree

(I have not actually use the library yet. Secretly hoping you'll will tell me about all the cons so I don't have to do the research myself. Currently choosing a library based on which has the best saga-like support)

[yayr]

mobx-state-tree (mst) is an addition to mobx. While mobx is a rather generic approach to manage state via composable observables and actions, mst is a strongly opinionated enhancement of it that brings in e.g. strong typing and some simplifications. While mst was great for some simple things, it soon runs into issues at complex requirements, one of them being performance. In my scenarios after running into some of these issues, I then rebuilt everything in mobx and brought in the strong typing etc. via TypeScript and code governance. This worked great so far, not much boilerplate, great state/action componentisation, also a great serialization/deserialization out of the box with serializr.