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

View other answers to this thread
Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more

Michael J. Ryan's photo

It's about managing complexity as you add features. In the end, a unidirectional data flow, especially combined with a single store and single state tree (redux, socrates and similar) which distill from the flux pattern, mean that changes to state happen in a consistent manner, and that actions/events are also dispatched consistently.

In this way, there is more cognitive overhead getting started in a new project, because the pattern breaks typical binding on components and separates out your control flow away from controllers and towards reducers. In the end, as you add features, new data, new containers/views/components/controls, you don't add much new complexity, and the logic is easier to manage.

It's hard to get into this mindset when you start a project, and the "community standards" are evolving... but it's easy to see how this works better in larger applications. In a simple TODO app, not so much, but in very large line of business apps, absolutely.

Anecdotal example, At work, I'm currently supporting three applications. One is an angular 1.x line of business application that is customer facing, it is very component/service centered and making changes to the workflow are very hard, to say the least... Another is a react+redux proof of concept for the prior application. The proof of concept handles roughly half the workflow of the original app (designed for the portion of workflow), but the codebase covering that workflow is a fraction of the size, and a lot of the larger complexity is gone and significantly easier to follow. The third is a new application using Angular 2, but it's going to use a single store/state tree. It's in Angular 2 (political reasons) as handed down, and unidirectional workflow, single-state based because it's proven itself out to reduce total complexity with additional features.

A bit of advice, divide up your structure (actions, reducers, controls, components, views, containers) based on feature, not based on types at a higher level. When you need functionality that is a cross-cutting concern, expose hooks via each feature's top level index, and use that for bridging the gaps.