This is a very enlightening view into React - reading this and thinking about complex application challenges, I think React can supplement even the large frameworks (such as Angular and Ember) well.
I don't think he read up too much on Flux since he implies Flux ditches unidirectional data flow. Flux is all about unidirectional data flow.
In the example involving the cart; he assumes the only way two sibling components can share state is by bloating parent components (by making them pass callbacks that they don't care about to their child components) or by breaking unidirectional data flow.
However, Flux (as described by Facebook) has a Store in which interested components can subscribe to change events. Your top level components will subscribe to the store and pass data to the child components. When a change occurs, only the top level component will get the new data and it will pass the data to its child components as usual. That doesn't break unidirectional data flow.
My point is that the React marketing is "top down unidirectional data flow", and that you quickly reach the end of what you can do with that before needing to add a another perpendicular uni-directional data flow (which is Flux or one of its variants), which breaks the vanilla React paradigm and many of the simplifying assumptions implied within such a simplified system. Two flows, both uni-directional, but in different directions, and the top-down flow no longer has anywhere near the same degree of control once you've added Flux to your system.
> ...you quickly reach the end of what you can do with that before needing to add a another perpendicular uni-directional data flow (which is Flux or one of its variants)...
Can you expand on that? For a simple application without Flux, the data flow starts at the top-level component and ends at the bottom. That's unidirectional and we both agree.
For more complex applications that require Flux, the data flow starts at the top-level component which gets the state from the store and passes it to the child components, which may raise change events which will run the callback registered by the top-level component that gets the state from Store and passes it to the child components, which may raise change events and the cycle continues.
I don't see two flows, I don't see different directions and I'm not sure how anything is perpendicular.
6 comments
[ 4.4 ms ] story [ 18.8 ms ] threadIn the example involving the cart; he assumes the only way two sibling components can share state is by bloating parent components (by making them pass callbacks that they don't care about to their child components) or by breaking unidirectional data flow.
However, Flux (as described by Facebook) has a Store in which interested components can subscribe to change events. Your top level components will subscribe to the store and pass data to the child components. When a change occurs, only the top level component will get the new data and it will pass the data to its child components as usual. That doesn't break unidirectional data flow.
Can you expand on that? For a simple application without Flux, the data flow starts at the top-level component and ends at the bottom. That's unidirectional and we both agree.
For more complex applications that require Flux, the data flow starts at the top-level component which gets the state from the store and passes it to the child components, which may raise change events which will run the callback registered by the top-level component that gets the state from Store and passes it to the child components, which may raise change events and the cycle continues.
I don't see two flows, I don't see different directions and I'm not sure how anything is perpendicular.