Dan Abramov and Andrew Clark created the Redux Open Source Javascript library in 2015. Redux is modeled after the Flux architecture created by Facebook and manages and centralizes the application state.

Foundation

The foundation of the Redux architecture is the assumption that data can only flow in one direction and that there can be only one model (the source of truth) in charge of storing and modifying the data so that it can be shown.

Redux components

In the Redux architecture we can find the following components (listed in alphabetical order).

Action

An Action is a straightforward object that the View sends to alter the application’s State. For example, receiving a response to a call to an external server is an example os a thing that can trigger an action. For example, imagine an action that changes an username. It can be done as an enum:

enum Action {
    case changeUsername(name: String)
}

Middleware

A Middleware is charge of using dependencies in the application, such as database access or external calls management. The application state and the action are passed through the middlewares when an action is launched.

Reducer

A Reducer is a synchronous, pure function that houses the logic and is in charge of changing the application’s state (they are the only components that can do it). The Reducer takes the State and Action from the Store, creates a new State, and then passes the new State back to the Store. Let’s see how to set a reducer that updates the username in the State:

func reducer(action: Action, state: State) -> State {
    switch action {
        case .changeUsername(let newUsername): 
            var newState = state
            newState.username = newUsername
            return newState
    }
}

State

There can only be one application state (for this reason, we may also say that the state is the origin of truth in the app). In the example we are seen, the State is a struct with a paremeter:

struct State {
    var username: String = ""
}

Store

The Store contains the State and is responsible for passing it to the Reducer together with the View and the Action. The new State generated by the Reducer is received by the View, which is subscribed to the State changes.

View

The View is in charge of displaying the application’s current state and is what the user sees. It receives updates whenever the State changes because, as we have seen, it is subscribed to changes in the State.

Redux flow

In redux the flow is as follows:

• It starts by an Action on the View.
• Then, the Reducer component receives this instruction, and its job is to change the application’s state in accordance with it.
• Finally, the state change causes the new information to be updated in the View, as the View is subscribed to this changes.

It is preferable to use different Reducers (Composition pattern) rather than different Stores when dividing the logic of an application.

Some Pros and Cons of the Redux architecture

## Pros

• Redux is lightweight, so external libraries are not required.
• The business logic is simpler to test because the Reducer is composed entirely of functions.
• We can decrease the amount of mocks in the test by isolating the business logic (Reducers) from the dependencies (Middlewares).
• The separation of responsibilities is effective.
• The fact that it only has one state makes debugging easier.
• State can be saved, so we can restore the previous state and use it, for example, on restar the app.

Cons

• By only working with one State, as the application grows, passing that State in each Action will increase the memory consumption of the application.
• It is an architecture that is widely used in web development, but little used in the development of iOS applications, so the available information is limited and can be inconvenient for newbies.
• It is a fairly fixed and specialized architecture, which means that it leaves little ability to customize or change to another architecture once it has been applied in the development of a project.
• Asynchronous events that occur in a Middleware can lead to conflicts between actions.

Conclusion

Redux is another possibility to consider when developing an iOS application. As is all architectures, it has its pros and cons, which must be evaluated according to the project we have in hand.