How does the Flux architecture work?

Question

Reactjs brought with it a new architecture, also used for Facebook and Yahoo!

I wonder how it works, what exactly is a Dispatcher, Store, Action...

If possible, on the basis of the MVC.

Answer 1

Flux is an architecture used to build client-side web applications, focusing on reusing code through component encapsulation, complementing the combinable components created with Reactjs, using a one-way data transport method.

What’s the idea behind this?

Basically the idea is to modularize the application into blocks containing behaviors, the elements are rendered according to the state changes, obeying callback features offered by the framework.

Another nice thing is that the framework provides a "Virtual DOM" where the state changes that reflect in the DOM presented to the user are applied.

Applications using Flux are divided into 3 main parts, the Dispatcher, as Stores, and the views(Reactjs components).

However, this Pattern should not be confused with MVC, because in Flux there are View-Controllers, that respond to user interactions.

Dispatchers

It is the central point that manages the entire data stream in a FLUX application. It is essentially a record of callbacks to the Stores. Each store registers and provides a callback. When the Dispatcher responds to an action, all Stores of the application receive the data load provided by the action through the callbacks registered.

Stores

Contains the status of the application and logic. Its role is somewhat similar to a model in a MVC traditional, but they manage the state of many objects and not single object instances. Nor are the same collections of Backbone. More than just managing a collection of style objects ORM, manage the application status for a particular application domain.

For example, the Facebook’s Lookback Video Editor used a TimeStore which accompanied the reproduction time position and the reproduction status. On the other hand, A ImageStore from the same app accompanied a collection of images.

As mentioned above, a Store registers with the Dispatcher, giving you a callback. This callback receives action data load as a parameter. The payload contains a type attribute, identifying the type of action. Inside the callback registered of Store, an instruction switch based on the type of action is used to interpret the load and provide the appropriate hooks for internal methods of store. This allows an action to result in an update to the state of the store, through the dispatcher. After the Stores be updated, they broadcast an event stating that their status has changed, so the Views can consult the new status and update themselves.

Views

Reactjs provides the combinable components we need for the layer view. Near the top of the hierarchy, a special kind of view listen to events that are transmitted by Stores on which it depends. One might call this view controller, since it provides the code to get the data from the Stores and pass that data down the chain of your descendants. We may have a view-controller to control any significant part of the page.

When you receive the event from the store, he first requests the new data he needs through methods getter() public of Stores. Then call your own setstate() or ForceUpdate(), causing your method to render() of all his descendants be executed.

We usually pass the whole state of store of the chain of views on a single object, allowing different descendants to use whatever they need. In addition to maintaining controller behavior at the top of the hierarchy, and thus keeping our descending views functionally pure as much as possible by going down the entire state of storages on a single object, which also has the effect of reducing the number of props we need to manage.

Flux x MVC

In comparison to the Pattern MVC, we can say that the Stores would be next to layer model, but it’s hard to compare the layer view, for she is the very one controller application in Lux. Different from controller of MVC that triggers and is triggered by the view, the view-controllers directly activate their Stores, as long as the Dispatcher deals with the dependencies between Stores.

Below the Flux application cycle, demonstrating that data flows in a single direction and remain in cycles associated with user interactivity.

Sources:

http://facebook.github.io/flux/docs/overview.html#content https://github.com/facebook/flux/tree/master/examples/flux-todomvc/

Answer 2

Flux - The Facebook architecture for Frontend development

What is?

Flux is a software architecture that Facebook uses to build the front end of its applications. It complements React using its one-sided data stream. Flux is more of a set of standards than a framework and you can start using Flux immediately in your projects without having to write or rewrite a lot of code.

To understand the operation of Flux Applications it is necessary to understand these 4 concepts:

Actions - These are methods to help send information to Ispatcher. Dispatcher - It is a data flow concentrator that is used to relay data to everyone who should receive that information, based on the Publish Subscribe standard. the Dispatcher used by the facebook you use in your home is here. Stores - It is the place where all the logic and the state of your application is stored that has registered callbacks for Dispatcher. Controller Views - These are components in React that bring the Stores' states and pass them on to the children in their 'props'. As you can already see, the data stream is unidirectional (Actions -> Dispatcher -> Stores -> Controller Views) and always in this way, if a component of the React performs some action, a new action will be called to send some information to the Ispatcher, who sends this information to all the subscribers and so on.

This should not be confused with the MVC. Controllers exist in a Flux application, but they are View Controllers that are often found at the top of the hierarchy that retrieves data from Stores and passes this data to your children.

Flux differs from MVC by having a unidirectional data stream. When a user interacts with a React component (View Controller), the view (component) triggers an action through Dispatcher, for the various Stores that maintain the application data and business rule and that update all the views that need to be affected.

https://medium.com/@henricavalcante/Flux-a-arquitetura-do-facebook-para-desenvolvimento-frontend-2bf7192c8f77

Answer 3

According to post on React blog:

Flux is the architecture of the Facebook application uses to build Javascript applications. It is based on a unidirectional data stream. We have built everything from small widgets to large applications with Flux, and everything we have played in it is handled. Because we think it’s a great way to structure our code, we’re excited to share it with the open source community. Jing Chen presented Flux at the F8 conference, and since then we have seen a great interest in him. We have also published an overview of the flow and a todomvc example, with an accompanying tutorial.

Flux is more of a standard than a complete structure, and you can start using it without a lot of new code besides React. Until recently, however, we have not launched a key piece of our flow software: the dispatcher. But along with the creation of the new Flux code repository and Flux site, we now have the same open source forwarder that we used in our production applications.

The dispatcher is a Singleton*, and functions as a data flow center in a flow application. It’s essentially a record of callbacks, and it can invoke those callbacks in order. Each store registers a callback with the dispatcher. When new data comes to the dispatcher, he then uses these call returns to propagate the data to all stores. The process of invoking call returns is started through the Dispatch() method, which takes a data load object as its only argument.

When new data enters the system, whether through a person interacting with the application or through a web API call, that data is packaged into an action - a literal object containing the new data fields and a specific type of action. We often create a library of auxiliary methods called Actioncreators that not only create the action object, but also pass the action to the dispatcher.

Different actions are identified by an attribute of the type. When all stores receive the action, they usually use this attribute to determine whether and how they should respond to it. In a Flux app, both stores and views control themselves; they are not put into practice by external objects. Actions run to stores through call returns that set and register, not through Setter methods.

Letting stores upgrade themselves eliminates many embarrassments commonly found in MVC applications, where cascading upgrades between models can lead to unstable state and make accurate testing very difficult. Objects within a flow application are highly dissociated, and adhere very strongly to Demeter’s Law, the principle that each object within a system should know as little as possible about the other objects in the system. This results in software that is easier to maintain, adaptable, testable, and easier for new members of the engineering team to understand.

(*) "Singleton is a software design standard (from Design Pattern). This pattern ensures the existence of only one instance of a class, maintaining a global point of access to its object. Some projects require some classes to have only one instance. For example, in an application that needs a data log infrastructure, you can implement a class in the Singleton standard. This way there is only one object responsible for the log throughout the application that is accessible only through the Singleton class."