Once you get your head around how MobX works and how it interacts with React components, the question becomes—how should I structure my stores? Should I tie my state as close to my React components as possible? Perhaps I should try to recreate the hierarchical structure of something like Redux? Or, maybe I should have a separate store for each domain object?

With a library as flexible as MobX, all these designs are possible. And each app has different needs—it's impossible to say that any particular design is "correct" for all cases. So in this episode we'll take an incremental approach—showing how designs change as more requirements come in, how they break down, and how to tease them apart.

By the end, we'll have a design that works well for pithy.af and the understanding of the choices that lead us there. Taking inspiration from the model layer from MVC frameworks such as Ruby on Rails, we'll see how MobX lets us present a clean, focussed API with a minimum of boilerplate. One that arguably hasn't really been possible in JavaScript before.