Flux is a front-end development architecture for a Facebook team

Flux is a front-end development architecture for a Facebook team

Flux Introduction

This article consists of:

• React Official Document Translation
• Relevant practical experience.

The content is the introduction of flux, examples will be written later.
Once you know a little bit more about react, it's hard to avoid the term flux.
Flux is a front-end development architecture for a Facebook team. With other mechanisms such as one-way data flow, react can play a more powerful role. Flux is more like a model than any other framework, and we can invest less in learning and quickly get started with flux.

The flux application has three main components: Dispatcher ( dispatcher ), Warehouse ( stores ), view ( view ). View is composed of react components. Do not view the flux application as an MVC architecture. Indeed, controllers exist in flux applications, but they are called controller-views, which is actually the outermost react component that gets data from the store and transmits it to subcomponents.

Flux uses one-way data binding, and each time the user interacts with the view, the view passes the action to the store of various storage application data and business logic, updating all the react components that are affected by the dispatcher.

Structure and Data Flow

The transfer of data in flux is unidirectional.

The above diagram is the most basic model for flux applications. Each node is independent. Do not think of the action too complex, they are only the data propagation package.

If the client interaction is taken into account, the graph will turn into the following, and the view will trigger the action to propagate in the app.

All data is propagated through the central node of the dispatcher. Dispatcher receives the action, it calls the appropriate callback function registered with store. The store will tell Controller-views that new data has arrived, triggering the latter's event handler. The latter obtains new data and, with the help of react's setstate, triggers the component's re-rendering.

There is no two-way bound data, and all States are maintained in the store. There may be dependencies on each sotre, but this dependency is managed by dispatcher and the modules are well decoupled.

Dispatcher

Dispatcher, as the central node of flux Application data transfer, actually manages the various callback registrations in the store, allowing it to distribute the action later.
Dispatcher can also manage dependencies between stores, that is, when the configuration action arrives, the registered callback is called in a certain order.

Appdispatcher.register (function (action) {varTextswitch (action.actiontype) {case TodoConstants.TODO_CREATE: text = action. text. trim (); if (text!==  ") {Create (text); Todostore.emitchange (); } break; case todoconstants.todo_toggle_complete_all: if ( Todostore.areallcomplete ()) {UpdateAll ({complete: false});} else {updateAll ({complete: true});} Todostore.emitchange (); break; default: //No op});       

Stores and Controller-views

The store contains the application's state and business logic. Their duties are similar to that of M in MVC.
The callback in the store takes an action parameter. As in the previous code, different operations are handled according to different action types. Whenever a store is updated, it notifies the various types of view being listened to in the event of a broadcast.
The React component forms the view layer, at the outermost level of the view structure, which is the controller-view that listens to the store broadcast, and each individual controller-view can be used to process the state of a subset of the components in the page.
When receiving an event from the store, it first takes advantage of the Getter method provided by the store to obtain new data and then passes setState() or forceUpdate() triggers the rendering.

This article concludes.

Category: React

Flux is a front-end development architecture for a Facebook team