mobx-state-tree
Koen van Gilst / September 22, 2019
2 min read • ––– views
I've been meaning to do this for a long time, but work and other side projects kept getting in the way. But last weekend I finally took a look at the much praised state management library by Michel Weststrate @mweststrate called mobx-state-tree
.
To get a feel for the library I created a simple kids' game figuring Jack the Lumberjack and his axe. The goal is to chop down as many trees as possible (not very CO2 neutral, I know). I used mobx-state-tree
to keep track of the game state and that felt clean and fast (as in: not verbose). Especially when comparing it to my current state management tool (Redux Saga).
Random observations
- it reduces boilerplate a lot
- it aligns more clearly with the Model View Controller paradigm
- offers a basic type system for your state (cause of errors in Redux, when not using TypeScript)
- you can keep your model, view models and actions together in one place (compare this with idiomatic Redux, where actions, reducers, sagas, etc. all live in their own folders)
- in
mob-state-tree
it's immediately clear where you do what: You handle actions in.actions
. If you need some derived piece of state, use.views
. In Redux Sagas you generally only use actions to dispatch payloads. Any business logic you're supposed to put in the Sagas. At least that's what I do. I’ve also seen examples of people putting business logic into actions and even reducers. Or in themapStateToProps
. Or in special selectors that live in the same folder as the reducers. In my experience programmers aren’t really sure where to put the logic, so in large codebases, it tends to be all over the place. - using it with TypeScript was really easy as well (most of the types are automatically inferred).
All in all, I was pretty happy with mobx-state-tree
as a state management solution.
The source code of Lumber Jack can be found on Github: https://github.com/vnglst/lumber-jack