Why does React emphasize on unidirectional data flow and Flux architecture?


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…

(4 answers) Take me to the question