flux-guidelines

Core Concepts

Flux pattern is based on several concepts that make it different from well known MVC pattern. These concepts explain the nature of relations between entities and layers in the system. Each of them can be effective in isolation from others, but together they shape the pattern in the way we know it.

Unidirectional data flow

Each piece of a system has one particular and unique piece to get data from and another one to pass data to. There is no intersection between these relations. However, the type of relations is different in each particular case. Containers pull data from stores, when stores react on actions from the dispatcher. It aims at satisfying the rules of loose coupling and high cohesion.

A set of connections can be represented as a circle:

Store          →      Container
  ↑                      ↓
Dispatcher     ←      Action Creator

Entities have a specific type of relations that determine the scope of knowledge about each other:

1. Containers pull data from Stores
2. Containers push data to Action Creators
3. Action Creators push actions to Dispatcher
4. Stores react on Dispatcher

Here are the key points:

• Dispatcher does not know about any piece of the system
• Stores only know about Dispatcher and use it as a single source of truth to mutate their state
• Action Creators know how to produce actions and dispatch them
• Containers (as a UI layer) know where to get data and how to react to the user’s input

Static subprograms instead of dynamic relations

In the way how entities are described, they look like stateless pieces of code with a single entry and an output. However, under the hood, those subprograms are called frequently based on the user’s interaction with the system. This achieved by generalizing the data flow and keeping the mechanism separately from the domain knowledge. This also brings the ability to cover these pieces with tests in isolation.

Actions as an activity log

Action, as a materialized fact about what happened in the system, can be persisted. List of actions may be used for several techniques that barely possible to be implemented outside of the pattern. For example, when a system failure is observed it can be reported with a list of actions so it can be treated as a list of steps to reproduce the failure in a different environment.

Deterministic UI state

Concepts described above introduce the way to compute a particular state of the UI based on a list of actions happened in the system. This creates a huge difference from MVC where you would need to perform some scenario in the way to get a desired state, where in Flux it happens by a straightforward operation on data.