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).
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 the mapStateToProps
. 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.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