I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that

I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that's when I whip out React's context (now documented https://facebook.github.io/react/docs/context.html https://facebook.github.io/react/docs/context.html). I follow the pattern of Redux/Baobab of having a monolithic state and partitioning it by module namespace (to avoid data dependency issues, e.g. Flux's waitFor hell http://christianalfoni.github.io/javascript/2015/02/06/plant-a-baobab-tree-in-your-flux-application.html http://christianalfoni.github.io/javascript/2015/02/06/plant...). Each module manages its slice of state and exposes an API for encapsulation. This also plays really well with React Router. In other words, the application state and the actions that can be performed on the state are passed down through the context. I prefer Redux's concept of smart/dumb components (https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.t5fhdnhsc https://medium.com/@dan_abramov/smart-and-dumb-components-7c...) to make sure the application state isn't being spaghettied all over the code. With Mobservable, there's a specific part of their documentation which I think does a decent job of explaining a similar set up: https://mweststrate.github.io/mobservable/best/store.html https://mweststrate.github.io/mobservable/best/store.html