Here our view controllers (just views in the web language of Flux)
and other objects send actions to the dispatcher.
The store has subscribed to receive the actions, which it uses to
update the state. Then the state is pushed to the view, which renders it,
completing the circle.

Now that a single store manages receiving actions and notifying
observers, it offloads the work of actually changing app state to
a reducer.

The reducer is where all UI-relevant state changes in your app
happen. I don’t mean state changes in external services like a
server or a database, I’ll talk about those later, but I mean any
state that impacts what a user sees or how they interact with
your app. It all happens here.

Reducer

(State, Action) -> State

Reducer

// Sequence

func reduce<Result>(

_ initialResult: Result,

_ nextPartialResult: (Result, Self.Iterator.Element) -> Result

) -> Result

The reducer is so named because it’s the method you’d pass to the
reduce function.

You can think of the incoming actions as a sequence,

Reducer

var actionStream: [Action]

func reduce<Result>(

_ initialResult: Result,

_ nextPartialResult: (Result, Action) -> Result

) -> Result

So the partially specialized reducer might look like this.

Now, considering that we're interested in updating state,

Reducer

typealias State = Result

func reduce(

_ initialResult: State,

_ nextPartialResult: (State, Action) -> State

) -> State

the fully specialized version might look like this.

Reducer

_ nextPartialResult: (State, Action) -> State

Here's the part we care about. Here's the reducer.

Reducer

(State, Action) -> State

Since the reducer is managing updates to your whole UI state,
it’s very important. Let’s discuss a few things about how we want
to build reducers.

First, notice that this is a synchronous method. We have a state
and an action, and we return a new state synchronously. This means
it must be very fast.

Second, this is intended to be a pure function with no side effects.
Given the same initial state and the same action, the reducer
should always return the same final state. This makes the reducer,
such a core part of our app, exceptionally easily testable.