Redux

Redux is a predictable state container. It helps you write applications that behave consistently, run in different environments and easy to test. On top of that, it provides a great developer experience. It is an alternative to other architectural patterns such as: MVC, MVVM and Viper.

Why Redux?

Redux as an architectural concept (not specifically as the Redux JS library) provides a well balanced implementation approach to a reactive paradigm with declarative UI. Its elements (see previous section) are well defined, its responsibilities are clear and is lightweight enough for us to implement our own redux stack version without the need to rely on heavier, and not tailored for our use, 3rd-party libraries.

Adopting an architecture as well-known as redux allows us to benefit from loads of 3rd party documentation, examples and tutorials from a vast community online. This will greatly help us to spread its knowledge and use. Also will be easier to overcome future challenges, since it is likely that some other people in the community have already found a good solution the same issues.

If the state is not managed properly then providing the necessary data to the components becomes more difficult as it expands and includes more components. This will cause application performance issues as well. By using proper state management architecture like redux we can avoid such situation.

What problem redux solves

It is much simpler to use redux state management and linking components rather than injecting properties and providing callbacks to change or access the application state.

Redux is a form of event sourcing where actions are sent to explain how to change the state rather than changing it directly. The reducer takes those action and applies the relevant modifications to the state.

State Management

In an imperative way, you would normally have to handle conditions and perform some operations on a ViewModel In a declarative way using Redux, we just check if we receive an ACTION of certain type; then we perform some business operations that will update the state model. It improves readability and consistency between other Views. We don't make any changes directly to a View because the View contains components (Text Fields, etc.) that are attached (bound) to a data model (State) in the Store, or in other words, the View is a function of the State.

---

Single Source of Truth (SSOT)

In other design patterns, like MVVM, you would normally have access to the data you need everywhere, like network, database, camera, etc. all around different classes and files.

You would initialise or use one of these services anywhere in the project multiple times. While using Redux, all the operations you perform are done towards a centralised source called Store.

Views are connected to this Store and always receive the most up to date value performed, as well as react immediately to any changes on its values. Simplified, the View tells the reducer to update the Store's State so that it can consume it by reacting to the state change.

This is known as Unidirectional Data Flow, and ensures only an Action can update the View.

Platform Specific Implementation

• iOS
• Android

Our redux proof of concepts

For each mobile platform (iOS and Android), we have developed a proof of concept where we have put into practice the redux architecture. This is also meant to serve as guidance for new projects that will be using this architecture. If you are implementing a redux reactive plugin, please visit the following repos for reference:

• Android
• iOS

---

References

Android - State and Jetpack Compose

TCA - The Composable Architecture

Combine

Redux

Redux introduction