The complexity of end-user applications is constantly increasing. Features like dedicated content serving
and real-time communication—via
chat, voice, and videoconference—are
routine on many websites, requiring
vast amounts of data to be streamed,
processed, and rendered. How is this
data flow supported? I explore the
answer here, while shedding light on
a model for not just handling but also
storing and mutating the data.

DATA-OBSERVER PATTERN

All applications that involve a nontrivial
data-management policy manifest an
observable pattern consisting of a client
and a subject; an observer acts as an
intermediary between the two:

Observer. The observer is responsiblefor watching the subject andcommunicating updates to the client asneeded;

Client. The client—an analog of
the subscriber in the publication-subscription pattern—waits to be
notified by the observer about changes
in the subject; and

Subject. The subject of the
data has no direct influence on the
infrastructure; its changes are simply
observed, and updates are sent to the
client.

Figure 1 illustrates how the three
components are interlinked. Keep in
mind this is important for understanding
how a state container works. On one
hand, the changes are observed and
updates are sent to the subscribers, and
on the other actions are dispatched to
change the state of the data.

STATE-MUTATION PROCESS

Having outlined the role of the observer,
we now turn to the actions triggered by
the clients that cause a data mutation
within the subject (see Figure 2).
Mutation is the permanent change of an
object. All changes should be described
through actions (commands). Once a
change is triggered by clients, an action
is dispatched through a pipe. On the
other end of pipe, the store (also called a
“reducer” in some implementations due to
the name of the method “reduce”) handles
the dispatch and, based on the actions,
decides how to change the state.

Actions. When describing actions,
as with any communication protocol, it
is important to be able to define a clear
standard. Most importantly, we want to
maintain deterministic behavior: The
same set of actions, fired in the same
order based on the same initial state,
should always lead to the same final
state. All actions are described by a
type and a payload, object with the
actual data. Based on the type, the
application can interpret the payload
and alter the state.

In a simple example of a mutation
through an action, as in Figure 3, we
start off with an initial state described
by the integer
1, and upon applying the
action {"add"," 3"} we end up in the final
state described by the integer
4.

Store. The store, or “reducer,” is
the entity that defines how the state
changes for a given action. Its job
is to handle the action and decide
the way state will be changed, thus
implementing the communication
protocol on the data end.

EXISTING IMPLEMENTATIONS

The following libraries constitute
examples of existing implementations
of predictable state containers:

Flux. This architecture, developed by
Facebook, represents a good starting
point for developers to develop libraries
and concepts;

Predictable State ContainersBY TEODOR SZENTEHELLO WORLD

Figure 1. Schematic illustration of the flow of data in an observer pattern.

ObserverClient Client ClientSubjectwatchingnotifynotifynotify

Figure 2. Schematic illustration of the flow in a predictable state container.