An introduction to the Flux architectural pattern

Cristian Salcescu
Jan 31 · 5 min read

was named one of the !

Flux is an architectural pattern proposed by Facebook for building SPAs. It suggests to split the application into the following parts:

  • Stores
  • Dispatcher
  • Views
  • Action / Action Creators

Store

Store manages the state. It can store both domain state and user interface state.

Store and state are different concepts. State is the data value. Store is a behavior object that manages state through methods. In the case of managing books: the book list is the state and BookStore manages that list.

A store manages multiple objects. It is the single source of truth in regards to those specific objects. In an application there can be many stores. For example: BookStore, AuthorStore, UserStore.

There are no setter methods on the store. You can only request state change by passing an action to the dispatcher.

A store listens for all actions and decides on which of them to act. This usually means a switch statement. Once the store has made the state changes, it will emit a change event. The store is an event emitter.

Stores don’t take other stores as dependencies.

Dispatcher

Dispatcher is a single object that broadcasts actions/events to all registered stores. Stores need to register for events when the application starts.

When an action comes in, it will pass that action to all registered stores.

View

View is the user interface component. It is responsible for rendering the user interface and for handling the user interaction. Views are in a tree structure.

Views listen for store changes and re-render.

Views can be further split in Presentation and Container Views.

Presentation views don’t connect to dispatcher or stores. They communicate only through their own properties.

Container views are connected to stores and dispatcher. They listen for events from stores and provide the data for presentation components. They get the new data using the stores’ public getter methods and then pass that data down the views tree.

Container views dispatch actions in response to user iteration.

Actions

An action is a plain object that contains all the information necessary to do that action.

Actions have a type property identifying the action type.

As action objects move around the application, I suggest making them immutable.

Actions may come from different places. They may come from views as a result of user interaction. They may come from other places like the initialization code, where data may be taken from a Web API and actions are fired to update the views. Action may come from a timer that requires screen updates.

Action Creators

The practice is to encapsulate the code, creating actions in functions. These functions that create and dispatch actions are called action creators.

Web API Calls

When doing Web API calls to update the user interface, the Web API call will be followed by an action to update the store. When the store is updated it will emit a change event and as result, the view that listens for that event will re-render.

Web API calls are made in action creators. We can extract out the code that does the API call in Web API Utils functions.

Unidirectional data flow

Updating views flow in a single direction:

Views do not modify the data they received. They listen for changes of this data, create actions with new values, but do not update the data.

Stores, views and any other action can’t change the state in (other) stores directly. They must send an action through the dispatcher

The data flow is shorter in store reads than in writes. The data flow in store writes differs between asynchronous and synchronous actions.

Store Reads

Store Writes in synchronous actions

Store Writes in asynchronous actions

Pros

Flux architecture is better in an application where views don’t map directly to domain stores. To put in a different way, when views can create actions that will update many stores and stores can trigger changes that will update many views.

Actions can be persisted and then replayed.

Cons

Flux can add unnecessary complexity to an application where each view maps to one store. In this kind of application, a separation between view and store is enough.

Take a look for example at .

Conclusion

Stores manage state. They change state only by listening for actions. Stores notify views to update.

Views render the user interface and handle user interaction. Container views listen to store changes.

The dispatcher broadcasts actions to all registered stores.

Actions are plain objects.

was named one of the !

For more on applying functional techniques to React take a look at .

Learn how to apply .

You can find me on .

The Startup

Medium's largest active publication, followed by +469K people. Follow to join our community.

Cristian Salcescu

Written by

Author of Discover Functional JavaScript and Functional React. Enthusiastic about sharing ideas.

The Startup

Medium's largest active publication, followed by +469K people. Follow to join our community.