Why does React emphasize on unidirectional data flow and Flux architecture?
The official docs say that it gives you the control over how data flows throughout your app. I didn't get this. How is this principle violated if I decide to support two-way data binding and other MVC concepts?
Answer
Ember developer here and Ember is a strictly conventional MVC so I think I can possibly answer your question. From what I can gather its away to decouple yourself from the expectation of two way bindings and some of the issues it causes when the view is so entangled in the store/data structure. Being able to trigger actions and dispatchers that then go on to update a view is the what Flux (to me) is in a nutshell. Given the shadow DOM and the benefits of managed component rendering in React 16 (Fiber) I don't see how they can occupy the same development architecture. Having this dispatch and event pathway lets the components compute and render separately and that is ACTUALLY better for a front-end application in terms of render and load speeds. IMO: Two way bindings cause data store changes in such a closed loop that there is little possibility for the kind of innovation that React and the various stores are bringing to the table.
Reply to this…
