Flux is the application architecture that Facebook uses for building
client-side web applications. It complements React's composable view
components by utilizing a unidirectional data flow. It's more of a
pattern rather than a formal framework, and you can start using Flux
immediately without a lot of new code.
Flux applications have three major parts: the dispatcher, the stores,
and the views (React components). These should not be confused with
Model-View-Controller. Controllers do exist in a Flux application, but
they are controller-views — views often found at the top of the
hierarchy that retrieve data from the stores and pass this data down to
their children. Additionally, action creators — dispatcher helper
methods — are used to support a semantic API that describes all changes
that are possible in the application. It can be useful to think of them
as a fourth part of the Flux update cycle.
Data in a Flux application flows in a single direction:
A unidirectional data flow is central to the Flux pattern, and the above diagram should be the primary mental model for the Flux programmer.
The dispatcher, stores and views are independent nodes with distinct
inputs and outputs. The actions are simple objects containing the new
data and an identifying type property.
The views may cause a new action to be propagated through the system in response to user interactions:
All data flows through the dispatcher as a central hub. Actions are provided to the dispatcher in an action creator
method, and most often originate from user interactions with the views.
The dispatcher then invokes the callbacks that the stores have
registered with it, dispatching actions to all stores. Within their
registered callbacks, stores respond to whichever actions are relevant
to the state they maintain. The stores then emit a change
event to alert the controller-views that a change to the data layer has
occurred. Controller-views listen for these events and retrieve data
from the stores in an event handler. The controller-views call their own
setState() method, causing a re-rendering of themselves and all of their descendants in the component tree.
Actions
The
dispatcher exposes a method that allows us to trigger a dispatch to the
stores, and to include a payload of data, which we call an action. The
action's creation may be wrapped into a semantic helper method which
sends the action to the dispatcher. For example, we may want to change
the text of a to-do item in a to-do list application. We would create an
action with a function signature like updateText(todoId, newText) in our TodoActions
module. This method may be invoked from within our views' event
handlers, so we can call it in response to a user interaction. This
action creator method also adds a type to the action, so that
when the action is interpreted in the store, it can respond
appropriately. In our example, this type might be named something like TODO_UPDATE_TEXT.
Actions
may also come from other places, such as the server. This happens, for
example, during data initialization. It may also happen when the server
returns an error code or when the server has updates to provide to the
application.
Angular is well known for its two-way data binding. When a user updates an input field on a view, the view directly updates the data model it represents. Likewise, when the model receives updates (via the controller) it propagates those changes to the presentation layer. This makes for bi-directional data flow, as the view and model are constantly kept in-sync.
Unlike MVC, the Flux pattern enforces a unidirectional data flow. A dispatcher receives user actions from the view and updates stores. These stores are similar to models in MVC, however they can contain multiple data objects. After receiving user actions from the dispatcher, each store updates the view(s) that are affected by the user action. It should be noted that application state is only handled in the stores. This maintains a strict separation between different parts of the app. This means that the view can't mutate the app's existing state directly. Rather, the view creates an actionable item that generates a new state. This new state replaces the current one only where necessary.
Implementations of Flux
Redux is a predictable state container for JavaScript apps.
It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. On top of that, it provides a great developer experience, such as live code editing combined with a time traveling debugger.
You can use Redux together with React, or with any other view library.
0 comments:
Post a Comment