3 ms·
There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (stat
by dclowd9901 11y ago
There's some trickiness around drizzling data down a hierarchy of views (creating redundant Params for modules) and around action handling outside of Flux (state should live in the controller, so how does a child module pass the action back up gracefully?). How do you addresss those?
- jameslk 11y agoI'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