Jing Chen, software engineer at Facebook was the one who first implemented FLUX. FLUX is a kind of data flow programming style, which emphasises the movement of data and models programs as a series of connections.
It’s recommended to use Flux as an application architecture for React, because of single directional data flow, which is easy to understand and to modify when an application becomes more complicated. It eliminates the problem where one change can trigger cascading updates due to two-way data binding.
Flux application consists of three major parts: the dispatcher, the stores, and the view (in our case these are React components). It is based on the concept of unidirectional data flow, making it much easier to track changes. All data changes come from user actions and goes to the dispatcher, which then sends it to store and when store does its job, it triggers view to update. Actions can be described as simple objects that contain new data. There is no other way, so there is no two-way data bindings. You can say that components take their mutated state from stores and can pass it to their child components through props.
Dispatcher sends some payload data to Stores, which are data layers in Flux. Dispatcher has some very useful methods, for example, “waitFor()”, a method that helps render in proper order. But all in all it’s like a simple mechanism that distributes actions to stores.
Store is responsible for managing dispatcher callbacks and state of application. Stores respond only to those actions that are connected with the state that they are maintaining. Finally they emit information that their state has been changed so components can re-render themselves and their child, retrieve new data, and trigger their “setState()” method to update the view.