You can find the source code of this tutorial here. If you’re so eager to try it that you want to skip the tutorial, just launch RootView.swift preview.

Introduction

Today we are going to build a simple app, consisting of 2 screens, using the composable architecture (TCA for short). TCA is a variant of an unidirectional architecture built upon reactive programming principles, created by PointFree. They provide extensive documentation about it and its creation process. You can check it out here. Interesting stuff and highly recommended if you like to understand every concept as intended by its creators.

The scope of this tutorial is to help onboard the TCA concepts as soon as possible. Which makes it a handy tutorial for people that need to work with these concepts right away.

This is what we are aiming for:

For this tutorial, we are going to use an open Dogs API which doesn’t require a token and perfectly suits the needs of this article. Let’s take a look at the app structure.

• Main screen: List of dog breeds with a possibility to filter by name.
• Detailed screen: A screen with a particular dog’s breed as a title, random dog image + a list of dog’s sub-breeds if available.

Both screens are going to be separate modules that don’t know about each other, so you can see modularization techniques of TCA as well. However, let's start with a bit of theoretical knowledge so we know what we're doing here.

What is The Composable Architecture

TCA is one of the variations of unidirectional architectures family, such as Redux, RxFeedback, Flux etc. Let's just copy some explanation from the official GitHub.

This library provides a few core tools you can use to build applications of varying purposes and complexity. It provides compelling stories that you can follow to solve many day-to-day problems you encounter when building applications, such as:

• State management
  How to manage the state of your application using simple value types, and share the state across many screens. This way, you can see mutations in one screen immediately in another.
• Composition
  How to break down large features into smaller components that can be extracted to their own, isolated modules. And that you can easily glued back together to form the feature.
• Side effects
  How to let certain parts of the application talk to the outside world in the most testable and understandable way possible.
• Testing
  How to test a feature built in the architecture, but also write integration tests for features that have been composed of many parts. Also: how to write end-to-end tests to understand how side effects influence your application. This allows you to make strong guarantees that your business logic is running in the way you expect it to.
• Ergonomics
  How to accomplish all of the above in a simple API with as few concepts and moving parts as possible.

To build a feature using the Composable Architecture, let’s define some types and values that model a domain:

• State
  A type that describes the data your feature needs to perform its logic and render its UI.
• Action
  A type that represents all actions that can happen in your features, such as user actions, notifications, event sources et cetera.
• Environment
  A type that holds any dependencies the feature needs, like API clients, analytics clients and so on.
• Reducer
  A function that describes how to evolve the current state of the app to the next state given an action. The reducer is also responsible for returning any effects that should be run, such as API requests, which can be done by returning an Effect value.
• Store
  The runtime that actually drives your feature. You send all user actions to the store so that the store can run the reducer and effects. You can also check state changes in the store so that you can update UI.

Now that the introduction is done, let’s get to the action 🚀

The Setup

Usually, every iOS tutorial starts with the project creation. But now, since it’s 2021 and all, you only need SPM to build this small app. Let’s do a little bit of RW style.

In Xcode, select File ▸ New ▸ Swift Package…. Then set the Product Name to DogBreedsComponent.

Click Create et voilà. Easy peasy right?

Adding necessary dependencies to the Project

Let’s update the Package.swift file by adding necessary dependencies that we need for this tutorial. The final result will look like this:

We’ve added 2 dependencies to the package:

1. TCA framework itself
2. Kingfisher library, that we're going to use for async image loading

Extras

For the implementation of this tutorial there are 2 simple extensions

KFImage+Header.swift

An extension that helps to build a proper layout with KFImage. That’s an Image type from the Kingfisher library, with a possibility to load async images:

String+Capitalized.swift

An extension we’re going to use for styling strings.

Please copy these 2 extensions into your project, to make sure your journey goes as smooth as butter. 🧈

Dogs module

First, we’re going to build the Dogs module. Basically the main and start module of this tutorial. With TCA it’s usually possible to start with 2 directions: business or layout. You could even split this work between 2 people via splitting business-logic-based State from view/layout-based ViewState.

Build the Dogs screen

In this tutorial, we’ll start with the layout for the main Dogs screen. Here’s what we’re going to build:

Loading screen, while loading dog breeds:

Loaded screen, with loaded dog breeds and a filtering field:

Let’s create a DogsView itself. The result is supposed to look like this:

Nothing fancy, just a SwiftUI view from a template. However, we're going to use DogsView as a namespace for a further journey.

ViewState

Just a small reminder that unidirectional architectures are state-based with a data-driven model. In a data-driven approach, the life cycle will be triggered whenever a piece of data changes. As opposed to an event-driven model where a life cycle will be triggered whenever an event occurs. So, let’s build this “model” ViewState for Dogs screen.

Here’s what happened:

1. A struct ViewState which is going to represent DogsView layout.
2. A filterText property speaks for itself.
3. A loadingState state property which is a simple enum LoadingState. It's pretty important to have our ViewState consistent, so it's not possible to end up in a situation where the screen is loading and showing dogs at the same time (if that's not our intention, of course).

ViewAction

ViewAction only represents events from the user or view life cycle. Let’s build every needed action or event for DogsView as an enumeration:

For DogsView.ViewAction we basically listed every action the DogsView is interested in. You’ll see how this is used soon.

Layout

Now let’s build a SwiftUI body for the DogsView as presented in the GIF earlier:

Here’s what happened:

1. DogsView owns its own Store based on ViewState and ViewAction.
2. SwiftUI TCA based implementation uses WithViewStore that returns a View and has a closure with ViewStore type inside. ViewStore is basically just a wrapper that allows you to have direct access to State and ability to send Actions.
3. Conditional check whether the ViewState.LoadingState is .loading. If it is, we show a progress view, or else a search bar and a breeds list. What's hidden under searchBar and breedsList you'll see in a moment.
4. In this particular scenario, it’s interesting to know when the view has appeared via sending ViewAction.onAppear to the Store. We'll cover the handling of these events in a bit.

Now after the main layout was built, let’s take a look at the guts of the searchBar function.

Here’s only one thing that’s interesting. For the SwiftUI's text field you need to use Binding (A type that can read and write a value at the same time). However, the nature of unidirectional architectures allows mutating (write) values only via Reducer. That's why TCA provides a helper function binding on the ViewStore, that reads data from State and as a function sends data to the Store via Reducer with the given action ViewAction.filterTextChanged.

In other words, this:

Is equivalent to:

Let’s have a look at breedsList function real quick:

Here’s what happened:

1. By using ForEach we're going through the ViewState.breeds array and drawing cells for every breed.
2. The cell itself is presented via Button and when pressing on we send a ViewAction.cellWasSelected action to the Store.

Layout Testing

What’s so great about SwiftUI? The previews are (when they work at least 😅). TCA's data driven approach offers super simple ways to test our layout. Here's an example for DogsView:

As you can see, by simply stubbing layout data, we can easily test 2 main scenarios (loading and loaded states) for this view. We’re going to cover how to use a reducer and an environment in this scenario later on.

Build Dogs business logic

After we’ve finished the layout, we’re going to add some business logic. I’m a fan of separating layout and business logic domains. So, let’s build business logic for the Dogs module.

State

Let’s describe the data of Dogs module feature that needs to perform its logic:

As you can see, DogsState is pretty similar to the DogsView.ViewState but not quite the same. This separation approach gives us a possibility to completely split the layout from business logic. By using this approach, it’s also much easier to reuse the same State for several screens at the same time or for different layouts for iPhone and iPad.

Action

Alright, it’s time to build an action type that represents all of the actions that can happen in the Dogs module:

Because the Dogs module itself is in charge of loading dogs, DogsAction has actions related to loading.

Environment

I already pointed out that we need to load dogs somehow. As you may remember, Environment is a type that holds all dependencies.

Here you can see DogsEnvironment, which holds loadDogs dependency. The return type of this dependency is an Effect. I can't phrase it any better than the way it's stated in the official documentation:

The Effect type encapsulates a unit of work that can be run in the outside world, and can feed data back to the Store. It is the perfect place to do side effects, such as network requests, saving/loading from disk, creating timers, interacting with dependencies, and more. Effects are returned from reducers so that the Store can perform the effects after the reducer is done running. It is important to note that Store is not thread safe, and so all effects must receive values on the same thread, and if the store is being used to drive UI then it must receive values on the main thread. An effect simply wraps a Publisher (Combine framework) value and provides some convenience initializers for constructing some common types of effects.

Reducer

Let’s put everything together in the dogs reducer:

Here’s what happened:

First of all, let’s take a look at every return value in this switch. Side effects in TCA provided by Effect as mentioned earlier. TCA framework provides a helper for Effect as well - .none which basically means that none of the work is going to be performed. This .none helper is used for every switch case, but one, which we'll get to right now.

1. Reducer type in TCA is actually a wrapper structure over the function known as Reducer in unidirectional architectures. This type provides some helper functions that we'll cover soon.
2. DogsAction.breedWasSelected is not handled at this moment, because we're going to extract navigation from the Dogs module itself.
3. DogsAction.dogsLoaded is an action used for DogsState to update with new dogs when they're loaded.
4. DogsAction.filterQueryChanged is an action that's called when the user changes the filter query.
5. DogsAction.loadDogs is an action called for dogs request. There's only one place for this reducer, which returns a side effect via effect. As you can see, we map returned data from environment and map it back into DogsAction. Which is basically a great example for a unidirectional approach. After the side effect performed DogsAction.dogsLoaded, action will be called.

Finalize Dogs module

In the previous steps, we’ve managed to create layout and business logic setups. Now it’s time to put everything together and make it work.

ViewState conversion from State

First, we need to bring our business logic world into Dogs screen layout. We’re going to use converters for it.

Here’s what happened:

1. A simple function which converts DogsState into DogsView.ViewState.
2. Here you see the necessity of having separate states for business and layout domains. We don’t care about formatting in our business logic, but it’s important for the visual part.
3. Filtering logic is also just part of state conversion. We don’t perform any special logic for filtering.

This approach helps with testing a lot too, since it makes our views as dumb as possible. Every view just renders simple data and sends actions back.

Here are some tests that should prove it:.

We’re going to use this converter inside an extension of DogsState and we’ll see how to use it later.

Action conversion from ViewState

Despite state conversions for actions, it’s necessary to convert in the other direction.

Showtime

Before we’ll show you the final result, we’re just going to add something small to the DogsEnvironment:

I really admire this way of treating dependencies, because with just a simple extension we’re able to test the whole logic without a real network call. If you’d like to learn more, there is a series from pointfree. To mimic some real network call behavior, we’ve added a small delay to see a transition from loading to loaded states.

Let’s add another DogsView preview and see what we’ve got:

Here’s what happened:

1. The first time we’ve only been interested in the layout, but here we used a business logic Store.
2. Here is a scope function to “scope” business domain into layout view one.

Let’s take a look at the result:

And it works even without any real API on board! Pretty cool right?

Dogs module testing

We’ve already had the whole working Dogs module. But what about testing? There’s no need to copy the official readme, so here’s a link on it. In short, the whole State/ Action based approach really helps with testing.

TestStore

If you’re already finished reading how testing and debugging works in TCA, you probably know what TestStore is. Let's implement it for Dogs module:

Nothing fancy, just a helper function that takes the same values as a normal Store but provides some testing functionality for us. TestStore provides send and receive functions that mimic real app/user behavior. But wait a second... What's the environment: .failing here?

Remember, how cool we’ve managed to create a fake implementation for DogsEnvironment? This is the same situation. But in this case we'd like to fail if anything that used loadDogs dependency was not expected. Remember what I've said in the beginning, that Effect is just a Publisher with helpers? This Effect.failing is one of them.

Let’s build our first test for dogs loading logic:

Here’s what happened:

1. Just a store: TestStore property, which we'll use for testing.
2. Mock of loadDogs dependency.
3. Sending an action DogsAction.loadDogs for a request of dogs loading.
4. Expecting to receive dogs response as DogsAction.dogsLoaded.
5. Here’s an assertion that DogsState mutated as expected.

If you’d like to see how TCA helps with highlighting test fails, please comment on our 2–5 points of the listed code.

Here’s another filtering behavior that would be nice to test.

Nothing complicated, just state mutation when an action is sent.

Basically, that’s it for the Dogs module. Congratulations! We still have stuff to do though.

Breeds module

The Breeds module is going to be similar with regards to architectural principles. That’s why it’s a great opportunity to train your new skills.

Here are requirements for this screen:

• Use Dogs.breed as a title for screen.
• Download a random picture for breed, according to this documentation and place it as a header.
• Create a list with cells and use Dogs.subBreeds as a title for each cell.

The final result would look like this:

After you finish or if just want to skip this exercise, check this proposed code:

Breeds module

Breeds module tests

App module

So far we’ve accomplished 2 modules: Dogs and Breeds. However, they are completely independent from each other. Also: there’s no way to navigate from Dogs to Breeds. Let’s try to solve it with modularization techniques in TCA. If you'd like to know more details, watch this pointfree collection about modularity.

Navigation is still a topic under discussion and there’s no clear approach for it yet. I’m going to show you my vision on it. Well, one of my visions actually. For the App module there is no need to create a separate ViewState and State because the App module is going to serve only as a mediator with navigation over Dogs and Breeds modules.

AppState

First of all, it’s good to remember that TCA is a part of a state-based unidirectional architectures family. In these architectures, there is usually just ONE state for the whole application. However, TCA framework provides some helpers for state composition. In other words, we can create several independent modules with independent states, which connect inside a single bigger state.

Let’s start with the heart of the module AppState:

Here’s what happened:

1. In this example, a dogs property is a shared property within the whole application. For other scenarios, it could be a User property, which you'll need access to throughout the app.
2. DogsInternalState we’re going to cover the next step. You could treat it as a Dog module state inside the AppState. It’s not optional, because the Dogs module basically exists within the whole app life cycle.
3. BreedState? is an optional state for the Breeds module. This state is optional because we use it for our detailed screen aka Breeds module.

But what’s this DogsInternalState thing? Let’s take a look:

Here’s what happened:

1. You may remember DogsState contains 2 properties: filterQuery and dogs. However, dogs is shared within the whole application. So, DogsInternalState is a helper entity, which consists of every property inside DogsState that are not shared with an upper module AppState. DogsInternalState has 2 initializers: one as an initial for AppState and a second one as a helper for initialization from DogsState.
2. This extension is just a convenience initializer from DogsInternalState, which contains any not shared property and the shared property itself.
3. A computed property dogsState which actually is a DogsState part of AppState.

AppAction

AppAction as AppState is a composition of BreedAction and DogsAction. However, there’s one extra action AppAction.breedsDisappeared which speaks for itself.

AppReducer

Let’s now try to build a reducer for App module:

Here’s what happened:

1. Breed module actions inside AppReducer, in which we have no interest whatsoever.
2. AppAction.breedsDisappeared an action where we need to clear BreedState after a screen disappeared.
3. DogsAction.breedWasSelected was abandoned inside DogsReducer. Now it's time to handle this action. We simply create a new BreedState that serves as a state for the Breed module. We'll show you how this state change will reflect navigation in the next steps.
4. Because we are interested in just one action from the Dogs module, all other actions can be safely ignored.

But wait! If the AppReducer ignores almost every action from Dogs and Breed modules, how ‘s this thing supposed to work at all? 🤔 The answer is simple. We’ve mentioned that Reducer is basically a wrapper over a reducer function + some handy helpers, right?

Before the big reveal, let’s implement prod or live versions for our environments.

Nothing really interesting here, just simple backing URLSession calls into needed dependencies. But have you already noticed we have 3 different implementations (failing, fake, and live) of environments without using protocols and such?

Now let’s go back to the reducers:

Here’s what happened:

1. Combining method helps to “combine” different reducers into one big reducer. So this combined reducer is going to work with every performed action from App, Dogs, and Breed modules as we’d like it to work.
2. As the first reducer here we use an AppReducer itself.
3. DogsReducer that we combined with a big AppReducer .That’s possible thanks to the AppState and AppAction structure.
4. DogsReducer is pulled back into AppReducer with the pullback function help. And as a result of this function we have AppReducer.
5. Via the usage of Swift KeyPath, we can say that DogsReducer is only going to work with the dogsState part of the AppState.
6. Via the usage of pointfree CasePath (if you’d like to know more, check out this repository. In short, it’s a way to use enums in the same fashion as KeyPaths). We can say that DogsReducer is only going to work with the AppAction.dogs part of AppAction.
7. Here, we’ve just created a DogsEnvironment. If our app is more complicated and has a lot of dependencies, we’d use a closure parameter AppEnviroment. But in this case it’s just a Void, so we don’t need it.
8. BreedReducer that’s also combined into the big AppReducer
9. BreedState is optional inside AppState, so we use another Reducer helper optional.

RootView

Basically, we’ve built the whole necessary logic, but haven’t made a real navigation yet. The final RootView of the app:

Here’s what happened:

1. DogsView was created as an immutable variable because it exists in the whole app life cycle and basically the main view of the app.
2. In the RootView we’re just interested in the breedState part of the AppState only for navigation purposes, which means that closure will be called only on breedState changes.
3. The body of the view contains DogsView and invisible NavigationLink which is backed by ViewStore Binding with a destination of BreedView.
4. A property for BreedView creation. If you take a look inside, you’ll see the IfLetStore entity, which helps to create views, backed by store, only when it’s possible.

That’s basically it. For the last step, let’s put everything together inside the RootView preview.

You should see a working app with a real live API.

App tests

Last but not least. Here’s the one test for App module:

AppStoreTests.swift

That’s all folks! You’ve just built you’re first TCA based application. Congratulations! 🥳

Where to go next

• The framework itself
• PointFree TCA video collection
• Series of articles about reactive programming and unidirectional architectures Learn more about the paradigm behind it and how to build your own unidirectional architecture framework.
• A video of another unidirectional architecture RxFeedback A solid introduction to the concepts.
• redux.js.org Thorough documentation about Redux framework for js. Don't need to go into the details, but this website contains a good explanation of the concept.

Last time we were talking about different types of modularization for Unidirectional data flow. And this time we are going to talk about the most important topic - testing. I'd say the whole of this journey was about this topic.

This time I’d highly recommend reading all the previous articles, because reading about testing in isolation doesn’t make any sense, without understanding the concepts of reactive programming and Unidirectional data flow.

1. What is Reactive Programming? iOS Edition
2. How to cook reactive programming. Part 1: Unidirectional architectures introduction.
3. How to cook reactive programming. Part 2: Side effects.
4. How to cook reactive programming. Part 3: Modularization.

Thousands of kudos to Dave Phillips. He really helped with this article!

Intro

I think this article will be the shortest one in the whole cooking saga, but as I said above and I want to repeat, it will be the most important one. Let's take for the experiments our old friend:

It’s quite a simple state machine, where every state is represented as an enum case. I don’t think it’s a secret for anyone that unidirectional architecture is highly based on functional programming approaches. That’s why we’ll start with the most functional thing about all unidirectional architecture — reducer.

Reducer

If you remember, reducer is a pure function. It has two inputs: previous state of the system and event for mutation of this state. As output, there’s a resulting state.

It should be quite obvious how to write tests for this kind of function. For these inputs, we have this output, zero dependencies, zero surprises. I want to show you one example, just to be sure that everyone stays in sync.

And that’s it. I bet it’s one of the most simple tests that you’ve ever seen. However, there’s not only a reducer in the system. Moreover, we have the whole system with side effects and everything else. How do we test all this stuff? Actually I’m going to say that integration tests couldn’t be easier as in unidirectional approaches.

Testing the system

Because we have a unidirectional data flow system which is based on events, and can be mutated only with events, testing the whole user flow becomes super easy. Unfortunately, the Combine framework doesn’t have a testing SDK yet, so that’s why I’ll use a little bit of RxSwift code, but don’t worry, here I’m going to use the most primitive concepts of RxSwift. Firstly let me show the test of the quite complicated user scenario. The user wants to add an event into the calendar but doesn’t have a calendar permission for it.

Firstly, I’ve used a TestStore which is a special test implementation of the store. The biggest difference is that this store can receive events as input for the sake of real user behavior simulation. We have two events from the user right here: showScene, where the user tries to open a calendar for adding a new event and userFinishedWithCalendarEditor, whose name speaks for itself.

Also, inside the TestStore I've mocked the permissionService to return the authorized status for every authorization attempt it helps to test a successful flow.

And last but not least we received an array of every state mutation in the result, which helps us to see what’s really going on there. Which scenes were opened and closed, how permissions were changed. I can even say that it looks like a UI testing, but without UI.

But what is this TestStore and what is the difference with the normal store?

Please don’t be scared of RxSwift code here, everything is quite simple. Let me explain. As far as you know every reactive framework is based on the event sequences. And every event has its own time when to appear in this sequence. RxTest in this play is a special framework, which can help us to avoid all this timing complexity. Moreover, in this particular case, it helps us to provide an array of input events for our system, which helps to simulate real user behavior. That’s it, there’s no other difference compared to a normal Store.

Actually, there’s one other cool feature, which we can do with a concrete TestStore implementation for the concrete system. It’s about mocking dependencies. I don’t think it’s a secret that one event or state mutation can produce a side effect. Sometimes it’s not so handy when your state could be mutated by some events, caused by other side effects. Let me provide an example. You’ve started to work with adding new events into the calendar, but by the app logic, we should first show you an alert with a login option, even if the login itself is not required for adding an event into the calendar. It doesn’t sound very user friendly, but I made up this example only as an example. However you really want to avoid this complexity for your test. You have two solutions here. The first solution is just to mock an auth service and say to it that your user has already been authorized. However, if that’s not an option for any reason, you can just mock your alert module with a never return. Remember, that in reactive frameworks we speak in the language of data sequences. So, technically every sequence could produce zero elements for the whole time, so it’s a never. This is an example, how could it look like:

Also, you can see a TestScheduler. This is a special scheduler, which helps us to work with a made-up (virtual) time. If you don’t know what scheduler is, in simple terms every one of your events in the system goes according to the imaginary clock, with this clock ticking and on every tick, an event could appear. So, this clock is the scheduler itself.

TCA

No articles without Composable Architecture so far... These two fellas really provide a lot of information to think about. While working with the approach that I've shown you before, pointfree.co shows an even more advanced version of testing the whole system. I'll show you a little bit of it, but you can make yourself familiar with this episode which is free to watch.

The test itself looks like this:

They use the same concept of the TestStore, that I’ve shown before, but it’s really more advanced. The testing of the system is now like magic.

One remark I’d make is their reducer looks a little bit different, and I’ve already made an overview of it in my article about side effects.

It has an environment, which holds all dependencies. So, how does their approach work? Firstly they can provide mocks for every dependency inside the test itself, mostly in the same way as I’ve shown you before. But further cool things happen. They have two different directives — send and receive. What are they about? The Send directive is the same as I've demonstrated in the previous approach, it is just what the user or other part of the app could send into your system. Inside a closure of it, you provide all changes of the state which should happen, to validate them. The Receive directive is the event which you will expect from the system, according to your side effects work. And the same closure to validate the state changes. So here, you really can test the whole flow.

However, pointfree.co is not pointfree.co if they don’t take one step further. Just look how their assert function shows you if your state wasn't mutated as expected:

And yes, it shows you the exact place, where the error happened. It’s crazily cool I would say.

Outro 😔

Usually, I say here something about that there’s no silver bullet, but this article was mostly not about approaches, but to show you how it is easy to test unidirectional approach. You really firstly can put all feature behavior in your tests and only after it starts to write a working code. If you don’t write the test before, you will after adopting unidirectional approaches. So this was the last article about reactive programming and unidirectional approaches! I hope for now you have enough experience to cook it in the right way.

If you liked this article don’t forget to smash that clap button. Moreover, you can do it 50 times, for you, it’s super easy, but it will be really helpful for me.

If you don’t want to lose any new articles subscribe to my twitter account

Last time we were talking about different types of Side Effects, and moreover I showed you some libraries which support Unidirectional data flow approaches. I can certainly say if you’ve already read all the previous articles you now have a clear idea of how reactive programming works, and how to build a unidirectional architecture by yourself.

I would highly recommend firstly reading at least the two previous articles. However, if you’re not familiar with frameworks such as RxSwift or Combine, or reactive programming in general, I’d suggest reading my first article as well.

Thousands of kudos to Dave Phillips. He really helped with this article!

Back to the future

I’ve finished all my articles already. And now we can go back to the future 🏎…

1. What is Reactive Programming? iOS Edition
2. How to cook reactive programming. Part 1: Unidirectional architectures introduction.
3. How to cook reactive programming. Part 2: Side effects.
4. How to cook reactive programming. Part 3: Modularization.
5. How to cook reactive programming. Part 4: Testing.

Intro

As I mentioned in my previous article, we live in a world where applications are not one button flashlight apps anymore. We have teams of more than ten people. And if you noticed, the main idea of Unidirectional architecture is to keep all data in one place. I bet, if you start with this approach, you’ll end up with a huge State and Reducer if not at the end of the week, then certainly by the end of the month. You may wonder how it's possible to separate the Unidirectional approach on different modules when the main idea is to keep everything in one place. That’s exactly what I'm going to show you today.

Today I will show you two approaches for Unidirectional architecturemodularization. I picked these two not because there are not more out there - you can easily find them if you search the internet. I picked them because they are opposite to one another. As a starting point, I picked a module that I want to use for experiments from the previous chapter.

But this time we need an app, where all the magic will happen. I’d like to keep it as simple as possible.

Imagine you have a small module like I’ve shown you recently, which can download news titles. Let’s just name it News. And you have the app itself, let's just call it App. Quite a simple module I’d say, but this time we need a User who’s shared within the whole app. Moreover, let's add a situation when the main app should know about the loading step from the news module, for example, it has another page, which depends on the news titles. So, let's start with the first approach on how to connect it to the main app. A list of requirements would look like this:

• The App needs to know about all changes in the News
• The News needs to know about all changes in the part of the App (User)

I think these requirements are simple and are enough for showing modularization concepts. So, let’s start with the first approach.

Composable Reducers

If you read my previous article, I bet you’ve already understood what architecture I’m going to talk about. Composable Architecture provides a really good way for modularization. What do they do?

The main idea of the modularization with the composable approach is to store every Eventand every State in the App module. Let's change the app a little bit to conform to the new requirement.

So far, I’ve just put everything inside the App itself. We’ll talk about problems with this approach a little bit later. For now, we need to proceed and solve the next problem. How would this system work? Maybe you've noticed that I omitted reducer for the new app variation. I did this on purpose because the entire work which should be done exists in the reducer itself.

Let’s try to solve this problem as it stands with building a new reducer.

It’s a little bit clumsy, but it works. However, I’ve just generated another problem. NewsStateis optional and should be created somewhere. Let's try to create it the first time when .newsEvents have appeared. The final reducer would look like this:

Now the system works. However, it doesn’t look like a modularization at all. All actions happen inside one function in the main application. Let’s try to fix it a little bit. We’ve already had a reduce function for the News module. I want to try to adopt it as is to the previously implemented reducer.

Now we have the composition of the most primitive function. It looks better, but it’s still not what we would expect from modularization. Could we somehow improve this composition? Of course we can — in the end, I’m not inventing here anything.

I’d suggest starting with the functions declaration first. What do we already have? We have two reducers, which work like one reducer. What does that mean? It means we want a function which could compose two separate reducers into one. So, for the first step, we need a reducer declaration.

Just a type alias for the function, which takes State and Event as the input and provides a result state as an output. Ok, so there’s nothing new here. For the next step let's make a declaration for the combine function, which combines multiple reducers into one.

Things are progressing easily so far. Now with these declarations, we’ll write a realization for the combine function. We just need to chain every reducer with the provided state and event.

This function could be realized with a simple “for” loop, however, the usage of the reducefunction inside our combine looks more symbolic, doesn't it? Let's try out what we've done so far.

What have I just done? I’ve created two reducers, combined them into one result reducer, and performed two mutations. As a result you can see that two completely separated reducers mutate one state, which is a proof of concept. However, I created another problem, and I’ve started to have the feeling that I’m only creating problems, not solving them. The combinefunction can work only over one type of state - AppState- and one type of event - AppEvent. We have the News module, which has different state and event types. How could this situation be resolved? Maybe you've already guessed, according to my first iterations, that NewsState, now a part of AppState and NewsEvent, is a part of AppEvent and we could apply some conversions to fulfill combine function requirements. But what should we do exactly? We need to convert NewsReducer into AppReducer.

NewsReducer has this declaration:

And AppReducer this:

I want to split this task into two smaller ones. Let’s start with transforming

into

As usual I want to start with a function definition:

Because Reducer is a function itself, we need to build a function inside another function 🤯. The first step will look like this:

To build a function which uses AppEvent and AppState we have NewsState and AppEvent. What can we do here? Because we need to put NewsState inside NewsReducer we need to somehow transform AppState into NewsState:

We’re Halfway there, but it’s not enough, as we’ve got an error

Cannot convert return expression of type ‘NewsState’ to return type ‘AppState’

It means that we need somehow to transform the news reducer result in AppState. We already know that NewsState is a part of the AppState, so it shouldn’t be so hard.

It will work, I can assure you. However, it doesn’t look generic enough for usage for different applications with different state interfaces. So let’s fix it.

Much better, but we could refactor it a little bit more with a KeyPath usage, and decrease the number of input parameters of the function, so let's try it out.

That’s what I’m talking about. Let’s move forward, we still have unfinished business according to events. The desired transform function will look like this:

Let’s start with an update to the existing one:

This code will show another error:

Cannot convert value of type ‘AppEvent’ to expected argument type ‘NewsEvent’

As far as you can see a Swift compiler really helps in these kinds of things, as throughout I’m just doing whatever it says to me. And now we need to convert AppEvent into NewsEvent. We've already made one as a part of another. Now we should make one small addition to make things easier.

We have a newsEvent property, which allows us to easily convert AppEvent into NewsEvent if it's possible. I'm going to add this update and fix the error.

In this case, if the app event was a news event we will perform a news reducer. However, the same small change should be added to make the transform function more generic. What have we done so far? We converted AppEvent into NewsEvent, so should we just add a conversion function as another parameter of the transform function?

Perfect! Now we have a transform function, which will really help with the reducers composition. Shall, we add the final step to make transform and combine into generic functions?

Voila! So it’s a small change, but we can use these functions for every reducer right now. Let’s test them with our previous test case.

The output is the same as on the previous occasion, however we now have a fully generic approach to achieve this. And that’s it, we’ve achieved a fully generic way of Unidirectional architecture modularization. It's actually quite a straightforward way to modularize your system. Before we move forward to another modularization approach, let's talk a little bit about the pros and cons.

Pros 👍:
The true way of Unidirectional data flow. You don't lose any of the advantages of the unidirectional approach and as far as you can see the main mantra still applies - everything is in the one place, everything works in the one direction, everything is consistent. It goes from the previous point, there's no way - unless of course you deliberately make one - when you have for instance different users in different modules.

Cons 👎:
Not true module separation. To achieve this modularization approach you need to reveal the State and Event of the underlying module to the module where you attach things. It shouldn't be a big problem if all your modules work together only in one project or several affiliated projects. However, it could cause some problems in two cases. The first case is if you just have started to use unidirectional approaches in your codebase. I bet you want to isolate and reuse modules in this case, not connect them in one place. In the second case when you work over a framework, you shouldn’t expect your customers to adopt a way of modularization, which I've just shown to you.

As I’ve mentioned before, what I’ve shown you I took from the pointfree channel. I’ve tried to make things a little bit different. They separated the app by modules, but I attached the existing module to the app. It’s not a big difference, but if you want to go deeper consider watching their videos as well. Also, they’ve explained a lot of functional programming concepts, which we used to achieve this modularization approach.

Fully separated approach

Do you remember what were the problems of the previous approach? That it’s hard to use in isolation and you have to reveal a state and event for an upper module. With this approach, you can solve these problems.

For this time we need to remember about Store.

Why do we need Store here so badly? Because Store is an entry point of the whole module creation. We actually need it for Composable Reducers, but it’s not so bad and I wanted to save a little bit of your time.

So, how do we achieve modularization? The answer is actually more straightforward or even easier than with a previous approach. We just need to provide a way of updating information from the outside world and provide a way to notify changes from the child module.

With any reactive framework, it’s a super-easy task. So, let’s implement it in one step.

What are all the interesting things that happened in the Store? I've just added two publishers Input and Output. With input, I can observe what happened in the outside world of the module and update data, according to the input event. With output, I can cut a piece of the state, which could be interesting in the outside world. Also, there’s one small addition because the sink method produces Cancellable type, so we need to somehow utilize this sinksubscription. I've attached it to the lifecycle of the view controller however, it could be done in different ways since unidirectional architecture could be used not only in the partnership with a view.

The second approach part ended up much shorter than the previous one. I hope it’s because this approach is far easier to understand and to implement, not because I’m too lazy to write it step by step. Now let’s talk about the pros and cons of this approach.

Pros 👍:
True modularization. An application doesn’t depend on the underlying module realization. If you want to try unidirectional approaches, it’s a way to adopt this as an only part of the project. Also, it’s suitable for SDKs creation.

Cons 👎:
It’s too easy to create the not true unidirectional state, because modules could have their own independent states and the whole app state could be inconsistent. Because it’s a state-based system, sometimes you have to almost manually reset a state. Imagine the situation, that you need to open another scene from your child module. You have something like sceneForOpen property in the child module. The main module should send something, like sceneWasShown, back to the child module for clearing sceneForOpen property. Otherwise, if you go back and want to open the same page again nothing would happen, because the child's state hasn't been changed.

What about Side Effects?

Side effects realization with modularization highly depend on the way you implement these side effects.

With the second fully separated approach there’s no difference in handling side effects at all. You have a fully separated module with its own side effects, when you create this module side effects will work, as I’ve shown in the previous article.

On the other hand, we have an approach with composable reducers. And thus I don’t want to repeat the pointfree.co Effects approach to modularization. You can easily find an explanation in their videos or on github.

However, I want to show you at least something. Composable architecture has its effects system, but imagine the situation when you have composable reducers as a modularization approach and query-based side effects. Here’s some code, showing how you could create a child store (child module) from the main store (main module). The main idea here is that every module has its own store, but every child module has a piece of this store from the main module.

In this case, we have a scope function which transforms the main store to the child one. Here SideEffect<LocalState, LocalEvent> is a pairing of query and action. The main idea of this approach is that while we create a child module, we inject side effects from it to the scope function. It gives us a way to construct modules with independent side effects. Every other action which is occurring in this function is mostly about main - child communication. It's necessary because we want to reflect changes from the main module inside the child one and visa versa.

There’s nothing hard to understand if you’ve already got how to handle modularization in general, trust me.

Outro

As usual, there’s no silver bullet for modularization. You can decide for yourself what to use. So far, you’ve become familiar with how to work and even how to build your own reactive framework and unidirectional architecture. Actually you know most of these things already. However, in my opinion, there’s still one important topic left — testing. Unidirectionalarchitectures give us a super elegant way of testing your code. How to do the testing I will show you in the next article. So, let's keep in touch!

If you liked this article don’t forget to crash a clap button. Moreover, you can do it 50 times, for you, it’s super easy, but it will be really helpful for me.

If you don’t want to lose any new articles subscribe to my twitter account

Before we start, I’d firstly highly recommend reading at least How to cook reactive programming. Part 1: Unidirectional architectures introduction.. However, if you’re not familiar with frameworks such as RxSwift or Combine, or reactive programming in general, I’d suggest reading this article as well.

Thousands of kudos to Dave Phillips. He really helped with this article!

Back to the future

I’ve finished all my articles already. And now we can go back to the future 🏎…

1. What is Reactive Programming? iOS Edition
2. How to cook reactive programming. Part 1: Unidirectional architectures introduction.
3. How to cook reactive programming. Part 2: Side effects.
4. How to cook reactive programming. Part 3: Modularization.
5. How to cook reactive programming. Part 4: Testing.

Intro

Before we will move to the talk about Side Effects I want to introduce you to the main subject of this article.

This is a representation of the simplest State which you actually can find in nearly every application. Let me transform this image into the real code.

Much better! If you’re familiar with a state machine theory from the computer science class, this picture will be very recognisable to you. This is a simple state machine with 3 states. The Initial state can go to the Loading state. The Loading state to the Loaded state. And the Loaded state can go back to the Loading state. Remember I was talking about Statedata consistency. In this particular case it's really hard to make the state inconsistent. Each state of the system is represented as an enum case.

Don’t worry, I’m not going to bother you with any computer science concepts here. It was mostly a representation of the ideal State which could be achieved. In the real world it's really hard to create only an enum state. In most cases it would be a structure. However, for the purposes of this article we will use this State for the experiments. And now let's move to the main topic.

What are Side Effects?

According to Wikipedia

In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, that is to say has an observable effect besides returning a value (the main effect) to the invoker of the operation. State data updated “outside” of the operation may be maintained “inside” a stateful object or a wider stateful system within which the operation is performed. Example side effects include modifying a non-local variable, modifying a static local variable, modifying a mutable argument passed by reference, performing I/O or calling other side-effect functions. In the presence of side effects, a program’s behaviour may depend on history; that is, the order of evaluation matters. Understanding and debugging a function with side effects requires knowledge about the context and its possible histories.

However, here we’re not talking about the strict definition of the side effects. Let’s remember where we ended up the last time.

Generally, nearly all unidirectional architectures look like this. We have a State on which the rest application relies as only one source of truth. A reducer which alongside Event is the only way to mutate or update State. However, there should be something else. We don't live in a synchronous world, where every update for State can be done only with a synchronous reduce function. Every application needs to go to the network or database, for the new cat images. Every developer moves even hard computations on the background thread. So, how will all of this work with the existing code? The answer is side effects. In our case Side Effects are something asynchronous, which could mutate State and this "something" works on the side of the reducer. Imagine your beloved network service which somehow needs to be connected to the rest of the system. But first let's talk about why this architecture is called 'unidirectional'.

One remark: Event in different implementations of unidirectional architectures could be called a Mutation or Action or Message, or maybe something different, for our purposes however naming is not so important.

Why is the architecture called unidirectional?

Unidirectional architecture is also known as one-way data flow. This means that data has one, and only one way to be transferred to other parts of the application. In essence, this means child components are not able to update the data that is coming from the parent component. The main benefit of this approach is that data flows throughout your app in a single direction, giving you better control over it.

I think it should be quite easy to understand with the State reduce approach from the beginning. We can change or mutate State only with a strict described Event. As a result we've got a one-way (unidirectional) data flow. However, what should we do with Side Effects?

Imagine that for the State we have a service which as a result returns a list of the news titles.

We know that reducer takes Event as an input not a closure... How can we connect this service to the reducer? The answer is quite simple. Let's have a Side Effect, which will return Event, not just requested data.

The resulting system will look like this:

As you can see for now loadNewsTitles returns an Event, which could mutate the state. Our system works only in a unidirectional way. And there's an answer to why the architecture is called Unidirectional. After I’d answered one question, I've subsequently produced another one. How can we connect Side Effects and the rest of the system? This question actually is the most complicated so far. I'll try to answer it in the next section.

Which types of side effects exist?

In nearly every unidirectional architecture you'll see a collaboration of State and some function for reducing this State according to the input Event. With Side Effects it's much more complicated. Almost every framework does this in a different way. Let me try to make you familiar with the most popular of them.

Middleware

Let’s start with the Middleware approach. Middleware provides a third-party extension point between dispatching an Event, and the moment it reaches the reducer. In simple terms Middleware, sits in the middle between you performing or dispatching an Event and mutating your State inside the reducer.

Let me provide you with a code example, which I found in one well-known framework for Redux implementation for Swift.

As you can see a Middleware could be treated as an asynchronous pre Reducer. It catches all Events, carries out some manipulations over it - in our case, loading news titles -, and performs a new Event for the system if it's necessary. So, if the Event is loadData, listed Middleware will load news titles and in the closure send another Event to the Store. The next dataLoaded Event will just be ignored by this Middleware. One of the pros of this method is the possibility to chain Middlewares quite easily.

Also, if you want to read more about this approach, I’d highly recommend taking a look at ReSwift framework. This framework is an implementation of a unidirectional architecture, which is called Redux for Swift language. For those, who still refuse reactive frameworks, ReSwift could be a good start, because ReSwift doesn't use any.

Effects

The next approach I want to talk about is the Effects approach. The main idea is almost the same as the Middleware, but all actions are going on inside Reducer itself.

In this approach Reducer has a little bit of a different shape, that I showed you before. It has a shape, which you can see below.

Nearly everything should be familiar. State is a type that holds the current state of the application. Event is a type that holds all possible events that cause the state of the application to change. However, there are two new characters: Environment and Effect. Environment is a type that holds all dependencies needed in order to produce Effect(s), such as API clients, analytics clients, random number generators, and so on.

So, how does it work for our example?

How does this approach work? For every call of Reducer you provide all necessary dependencies via Environment to the Reducer itself, and afterward your Store will perform every workItem from the Effect itself. And then every Effect will return another Event to the Reducer. Unidirectional data flow works with all power here.

You may ask, but what about the pure Reducer over there? You told us that Reducer is a pure function, and now you put Side Effects directly inside this function. Moreover, we mutate State inside this function, not just creating a new value. So, I can definitely explain that this variation of the Reducer is the most complicated one which we've seen so far. It has the Environment inside and it mutates State. However, let's take a closer look. If we provide one implementation for the loadNewTitles service, our Reducer will perform the same and our State in the end will be the same. Yeah, in the real world, our server can answer with the different replies or different news titles, but it still has the same output - Effect as a return value, with the same network client in it. I hope you've got the idea. What about State mutation? Since all real mutations are always going on inside the Store, the main situation around changing State hasn't changed itself. Moreover, mutating State against creating new values for every reduce saves some performance for us. We don't need to allocate new memory each time.

I don’t want to provide a working example of this approach as well. My job is to make you familiar with it and explain the basics. However, I highly recommend taking a look at The Composable Architecture TCA from pointfree.co. In my personal opinion this framework is the most promising for now. It has its own cons such as the minimum iOS 13 version.

Query Feedback

Let’s move forward or downstairs. In contrast with Middleware or Effect approaches from the previous sections, there's a Query approach. The Query Feedback approach reactsto new changes from the different side of the Reducer compared to Middleware.

Did you notice? We’ve moved the whole way through Side Effects approaches? Middleware was before Reducer, Effects approach was inside Reducer and now Query Feedback is after reducer. Quite a journey, huh?

However, how does it work? We need to take a small piece of the State and start to Observe every change of this state. For the previous example it will look like:

In other words, there’s some kind of Observer, which follows every change of this query and performs some actions over it. The optional Void type for my taste is the best representation when you need to understand whether you need to do any work or not.

I think you’ve likely become bored with non-working examples in this article. So, let’s try at least to implement this one. I’ll use the Combine framework for this implementation. Whoah, this is the third article about reactive programming, and only now I'll start to use a reactive framework. Also, afterward, I'll explain why I prefer to use Combine over vanilla Swift. Technically Combine is already vanilla as well, but you've got the point.

Here is a small table of concepts for those who are new in Combine.

• Publisher declares that a type can transmit a sequence of values over time.
• @Published is a type that publishes a property marked with an attribute
• Sink attaches a subscriber with closure-based behavior to a publisher
• Cancellable a protocol indicating that an activity or action supports cancellation.
• Store stores this cancellable instance in the specified collection

From now a little bit of tutorial started. Everything that I’ll write below you can copy to your project and play with it afterward.

Let’s introduce our old characters: State, Reducer, Query and Event:

Nothing new so far — only a Query which I've shown to you recently. Now let's remove the callback from loadNewsTitles service and rewrite it in Combine fashion.

Mostly it’s just a pre-prepared mock with a small delay, which should simulate a real network environment. And now there’s a new character in this play. Let’s call it SideEffects. Obviously it's not me who invented this name, but let's imagine it for the bigger narrative of the story.

As far as you can see, SideEffects for the Query Feedback approach is almost the same thing, as Environment for the Effect approach. I prefer to keep it as simple as possible, and most of the time it just converts the output from the services into Event which could be consumed by the Reducer.

And for now, there’s only one question left- how do we connect SideEffects with the rest of the system? The answer isn’t so complicated, and Combine helps with it very much. Let's build our boss Store entity in which we'll connect every piece of our system.

The most interesting part of the code listing above is the start function. As far as you can see, I made our SideEffects react to the change of the piece of the State loadQuery. And for every time when our system will be in the loading State, our SideEffects will go to the network service, download new newsTitles and notify our system that new titles have been downloaded. Do you see it? Everything in the cycle, all data flow works in the one direction.

Let’s test what I’ve done so far.

And it works, as expected! The system started from initial state then it went to the loading state after the new Event was sent, and ended up in loaded state. If you want to play with it some more, I've prepared a gist.

I know that twoCancelables could look a little bit clumsy here, but I didn't want to make this example too complicated. There's another framework called RxFeedback where all these problems were solved. I think that you've already got it, that this framework uses RxSwift from the title, right? However, there's a constructor of Observable - it's a Publisher from the Combine - which creates the whole unidirectional system for you.

Typealias Feedback is a SideEffect itself. It takes changes in the State as an input and provides a sequence of Events as output.

In my personal opinion, this approach is the most hardcore one. As an advantage, you can take that your State always reflects what's going on in the system. The previous two rely on Event while doing any Side Effects, but this one only relies on the State itself. If you want to read a little bit more about the pros and cons of the Effect and Query approaches, you could read my discussion with TCA creators.

Why do we need a reactive framework for this?

There are a lot of people who don’t want to accept any reactive frameworks and don’t understand why they are even needed. If you’re still reading this, and you are one of them, crash the like or clap button. This section is mostly for those who’ve been intrigued by the Unidirectional approach, but for some reason don't want to use reactive frameworks. Firstly I want to say, that you've already seen in my articles, that there’s nothing to be scared by inreactive frameworks and reactive programming in general. Most of you already use some techniques from it. I can say that it's much more handy to handle your data like a sequence or array than work with enormous closures. Use some functions, like filter, mapor reduce etc. It really makes your code more clean and understandable. It's really hard to make a lot of mistakes from the start if you don't know how to cook it 😉. That's why I write these articles for you.

Let me show you another advantage in a reactive framework usage. Do you remember that I relied on ReSwift framework while showing a Middleware approach? This is a great framework, which was written by brilliant people. However, if you try to understand how it works under the hood, or even try to work with it you will end up with structures like this.

There are three closures inside each other! Moreover, I’ve used a helper to make it more simple. Of course, you could separate all of this somehow and avoid all the callback hell. However, if you take a look at my previous Query example you will see how everything was simple and straightforward. I wanted to say elegant as well, but for elegance it has to be refactored a little bit 😑. If you want to have a closer look at ReSwift in action, I did a small test project some time ago.

Outro

There’s no silver bullet on how to handle Side Effects. You can decide for yourself what to use. However, I think that most of you and myself will choose some pre-prepared solution like RxFeedback or TCA or ReSwift or something else.

Finally, I have a chance to show you this gif. I took it from the ReSwift repo. This gif in full form represents the whole power of Unidirectional approaches. Technically you can store the whole history of State mutations and replay them at any moment you want.

So far, you’ve become familiar with how to work and even how to build your own reactive framework and unidirectional architecture. However, we live in a world where applications are not one button flashlight apps anymore. We have teams of more than ten people. And if you noticed, the main idea of Unidirectional architecture is to keep all data inside one struct. I bet, if you start with this approach you will end up with a huge State and Reducer if not at the end of the week, then by at the end of the month. You may wonder how it's possible to separate the Unidirectional approach on different modules when the main idea is to keep everything in one place. What to do in this situation and what are the ways of app modularization I will show you in the next article. Let's keep in touch!

If you don’t want to lose any new articles subscribe to my twitter account))

Back to the future

I’ve finished all my articles already. And now we can go back to the future 🏎…

1. What is Reactive Programming? iOS Edition
2. How to cook reactive programming. Part 1: Unidirectional architectures introduction.
3. How to cook reactive programming. Part 2: Side effects.
4. How to cook reactive programming. Part 3: Modularization.
5. How to cook reactive programming. Part 4: Testing.

Back to the article

This article can be read not just by iOS developers. I used only the basic concepts of Swift. You will understand it if you have knowledge of any modern programming language.

Today we are going to talk more about the practical aspects of reactive programming. I’ve already mentioned it’s too easy to make a lot of errors with this approach after you’ve begun using any reactive framework, so I want to show you how to avoid any problems.

Thousands of kudos to Dave Phillips. He really helped with this article!

The problems

To start, I want to describe some common problems with reactive programming and with the most common approaches nowadays.

Let’s begin with reactive problems. The most common fear about reactive programming is that when you start to use it, you can reach a point where there are hundreds of uncontrolled data sequences in your code base and you as a developer no longer have any power over it.

Unpredicted mutations

The first and the biggest problem of what a reactive way could do for you is unpredicted mutations. Let me make an example:

For the simplest of reasons, I’ve replaced the reactive sequence with an array. The example itself is an oversimplified way of how you can make a mistake, doing any reactive things. Nobody can predict where and when you changed data, we have so many ways to do it and there are so many of them hidden under reactive framework implementations.

However, how can we handle this, how can we protect ourselves? First of all, we should move from reference types to the value ones.

Just with this simple change, I protect my array from an unpredicted mutation. As far as you know structs are value types, and they copy themselves all the time (there's a copy on write mechanism, but you've got the idea).

However, let’s wait for a moment, and let’s try to move one step forward and try to make one radical movement. Let’s make variable val a constant.

Yes! That’s the protection I’m talking about. Now we don’t have any chance to mutate our data on the way through the data Sequence.

What are we going to do with all this? A mobile application is not a painting, it is not static, we need to mutate data to react on user behavior or any other external changes such as network data or timers. An app is a living thing. So we have two problems to solve. We need to keep our value entities in the floating sequences, and we need somehow to mutate data to show changes to the user. That sounds like a challenge but wait for it, let's talk a little bit about modern architectures. This is an article about architecture after all.

MV family

The problem above is not only about the reactive approach. You can face it everywhere, no matter the paradigm you use. Let’s take a small step back and talk a little bit about modern app architectures.

I can bet you’ve seen this guy before. Actually, in my personal opinion, most modern architectures look like this. They could be called the MVsomething family. MVP, VIPER, MVVM, the same but different. I don’t want to go deep inside to try to understand what all the differences are between them, you already know this. Let’s talk about common things. They are all small pieces, separated by screens, single views, or just a piece of business logic. Whoever is familiar with the topic will understand in advance what I’m getting at. With all these architectures it’s easy to bump into an inconsistent state of the app. Let me provide an example — imagine you have a home page in your app, and this home page depends on the logged-in user. You have a quite complicated app already with a possibility to sign in or sign out the user from different parts of the app. Already understand what I’m talking about? Imagine you decided to sign out from one part of the app and your home page should react on this change. Let me just show a gif as an example.

You can use some sort of user service, which will notify all subscribers to this service about any changes to a user. This approach has two problems. First problem: I think that services should be stateless; they shouldn’t hold any information, just perform actions. Second problem: imagine that we have more than one situation where we need to share information between several modules. In this case, we’d have a bunch of dirty services and we’d simply return to the starting point with a lot of floating mutations.

What to do in this situation? I’ll give you an answer shortly.

One ring to rule them all

As I said above, an application is a living, changing system. For now, we have two problems, which should be solved. The first problem is that we need to keep data in the sequences immutable. The second one is that we need to stop producing sources of truth inside the codebase. How can we achieve this? What if I say, we can have a single source of truth for the entire application? It sounds ridiculous, but let’s try to build this kind of system.

As I said before only one state object is needed. Let’s create it.

Quite easy, yes? The system should be as simple as possible. There is only one source of truth, and every other participant in the codebase observes all changes within this source. Let's try to implement this as well.

What have I done? There’s a state object which holds data from the whole application. Store is an entity, which holds everything. Two Observer objects, which subscribed on every state change. And mostly that's it. By the way, do you remember the user example before? The listed solution perfectly handles this situation. However, there's one big problem. The state was changed directly via store.state.value = 10. This approach could lead to the same problems, which I'm trying to remove right now. I'm going to fix it with a solid сoncept of Event.

One remark. I know that observers are held with a strong reference in Store, and it should be avoided in the real project. You can find out how to achieve this in the previous article. Here I want to save some time. Back to the Event.

For now, no-one can mutate the state in an unpredictable way. The way of mutation is clear, structured and encapsulated under the Event concept. If you have noticed, for now, you cannot reach State just like a property of the store. I've done this on purpose, because reactive programming is about reaction on system changes, not taking data whenever you want, as I described in my previous article.

Wait one moment… Take a look at this signature of standard reduce function in Swift:

It looks almost the same as our accept function. There's an intialResult as the previous State, and some function to mutate State according to the Event. Let's refactor existing code a little bit.

That’s much better. However, take a look at this reduce function... It looks like it's completely independent of the Store and mostly any other objects. Why is this so? A reduce function is a pure function - it has its input parameters and one output. It also means that no matter what is going on in Store itself, reduce will work in the same way. So, maybe we should extract it from the store and make it a high order function? It sounds like a great idea, doesn't it? Again, let's wait one moment. Seems like reduce is closer to State than to Store, so let's put it under the State namespace.

Here’s the final solution for our DIY architecture.

As a result, we’ve got a simple unidirectional architecture. However, there are so many questions remaining. We don’t live in the synchronous world, where it’s possible to put every mutation through the reduce function synchronously. Indeed internet requests or timers couldn't be added like this to the approach that I've introduced before. To resolve this problem, we'll use the SideEffects approach, but I'll write about that in my next article. And I almost forgot about one important thing. Why is the architecture called unidirectional? To provide a clear explanation, I'll need to make you familiar with the SideEffects as well. So, stay tuned!

PS: This is already the second article about reactive programming, and I haven’t used any framework such as RxSwift or Combine... It actually means that most of you have already been using reactive approaches, without even noticing it. If you don't want to lose any new articles subscribe to my twitter account))

So, what is R̶x̶S̶w̶i̶f̶t̶ ̶C̶o̶m̶b̶i̶n̶e̶ Reactive programming?

According to Wikipedia:

Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm, it is possible to express static (e.g., arrays) or dynamic (e.g., event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow.

Excuse me, WHAT?

Let’s start from the beginning.

Reactive programming is an idea from the late 90s that inspired Erik Meijer, a computer scientist at Microsoft, to design and develop the Microsoft Rx library, but what is it exactly?

I don’t want to provide one definition of what reactive programming is. I would use the same complicated description as Wikipedia. I think it’s better to compare imperative and reactive approaches.

With an imperative approach, a developer can expect that the code instructions will be executed incrementally, one by one, one at a time, in order as you have written them.

The reactive approach is not just a way to handle asynchronous code; it’s a way to stop thinking about threads, and start to think about sequences. It allows you to treat streams of asynchronous events with the same sort of simple, composable operations that you use for collections of data items like arrays. You think about how your system reacts to the new information. In simple words, our system is always ready to handle new information, and technically the order of the calls is not a concern.

I assume that most of the readers of this article came from iOS development. So let me make an analogy. Reactive programming is Notification center on steroids, but don’t worry, a counterweight of the reactive frameworks is that they are more sequential and understandable. Moreover in iOS development, it’s hard to do things in one way, because Apple gave us several different approaches like delegates, selectors, GCD and etc. The reactive paradigm could help solve these problems in one fashion.

It sounds quite simple. Let’s take a look ar a couple of functions in one class implementation of one of the most popular frameworks RxSwift:

This even partial example does not look easy at all… As we can see the implementation of RxSwift is not so simple. But let me explain myself. RxSwift is an advanced, highly optimized framework with wide functionality. To understand the principles of the reactive world, this framework doesn't fit. So, what are we going to do? We are going to write our own reactive solution from scratch. To do this, firstly we need to understand which parts this library consists of.

The tale of two friends

Let me answer again the question: What is reactive programming? Reactive programming is a friendship of two design patterns: Iterator and Observer. Let's have a quick reminder of how these patterns work.

Iterator is a behavioral design pattern that lets you traverse elements of a collection without exposing its underlying representation (list, stack, tree, etc.). You can read more at this link.

Observer is a behavioral design pattern that lets you define a subscription mechanism to notify multiple objects about any events that happen to the object they're observing. You can read more at this link.

How do these two friends work together? In simple terms, you use the Observer pattern to be subscribed for new events, and use the Iterator pattern to treat streams like sequences.

Iterator

Let’s start from the beginning. From the Iterator pattern.

Here’s a simple sequence of integers:

And I want to iterate through it. Easy enough:

However, I think that everybody would say this way of iteration via sequence is a little bit weird. Let’s do this the proper way:

For now, it looks more natural, or at least I hope so. I used the forEach method on purpose. forEach has this signature

func forEach(_ body: (Element) -> Void)

It's a function which takes a function(handler) as an argument and performs this handler over the sequence. Let's try to build forEach by ourselves.

With forEach semantics it's possible to write this elegant code.

As I said before, that reactive programming is above all thread problems. Let’s add to our custom forEach some thread abstraction.

Observer

I went so far and did some strange custom forEach for Array. What is this for? We'll know about this a little bit later, but now let's move to Observer.

There are many terms used to describe this model of asynchronous programming and design. This article will use the following terms: an Observer and Observable. An Observer subscribes to an Observable, and the Observable emits items or sends notifications to its observers by calling the observers' methods.

In other words: Observable is a stream with data itself, and Observer is a consumer of this stream.

Let’s start with the Observer. As I said, it's a consumer of a data stream, which can do something around this data. Let me translate, it's a class with a function inside, which calls when new data arrives. Let's implement this class:

And now let’s move to Observable. Observable it's data itself. Let's make it simple for the first iteration.

The most interesting part is that Observable should allow to subscribe to a consumer of this data. And via changing this data in Observable, Observer needs to know about these changes.

Actually we just build our Observer pattern. So, let's try this out.

And it works! But hold on for a second — let’s add some modifications before we go further.

Maybe you’ve already mentioned that our Observable stores all input Observers via subscription, which is not so great. Let's make this dependency weak. However, Swift doesn't support weak arrays for now and maybe forever, that's why we need to handle this situation otherwise. Let's implement the class wrapper with a weak reference in it.

As a result, you can see a generic object, which could hold other objects weakly. Now let’s make some improvements to Observable.

For now Observers not held by Observable. Let's try this out and create two observers.

As you can see, the second Observer was destroyed after 2, which proves the workability of the code. However, I think creating an Observer object by hand all the time could be annoying, so let's improve Observable to consume a closure, not an object.

For my taste usage is more clear now, however it’s possible to use both subscribe functions.

For now, our tiny reactive framework looks finished, but not exactly. Let’s do some asynchronous stress tests for the Observable.

In this case, we should receive numbers from 1 to 9 in random order, because changes run in the different asynchronous queues. For my case, it was like this

As you can see, it’s not the expected result. A race condition happened and it should be fixed. The solution is easy — let’s add some thread synchronization. There are several ways to achieve this, but I’ll use a method with a dispatch barrier. Here’s the solution.

The same test as before gave me this result:

This time it’s even in the right order, but be aware that it’s not guaranteed. Now our reactive framework has thread synchronization.

Let’s move further and there’s another difference between a vanilla Observer pattern and most of the reactive frameworks. Usually, as an Element from Observable, you manipulate not just an Element, but some kind of Event enumeration, which looks like this.

It’s a handy solution, because you can handle situations when your sequence completed or received an error. I don’t want to spend time adopting this practice right now, I think it doesn’t matter for concept understanding.

Let’s compose Observer and Iterator

One of the killer features for reactive programming is the possibility to treat your Observable sequence as a Sequence I think everybody knows these handy functions like map, flatMap, reduce, and so on. As an example, let's try to add to our Observable the map function. But firstly let's remember how it works with a simple array.

This case is a primitive adding 1 to every element. Can we do the same with an Observable? Sure we can. Let's add a map function to our Observable.

Yeah, you can mention that I’ve cheated a little bit.

True map function would have structure with a generic like this:

func map<T>(_ transform: @escaping (Element) -> T) -> Observable<T>

However, for the sake of simplicity in this article I just added this:

func map(_ transform: @escaping (Element) -> Element) -> Observable<Element>

I hope you could forgive me and understand the point.

Actually, we’re done for now with our own reactive framework, congratulations to everybody who followed until the end. It’s super simplified but it works. Gist with the last iteration of this article you can find here.

I hope at least for now, reactive programming doesn’t look scary anymore. However, I hear all the time from people, that reactive way could lead us t an enormous number of sequences flying around the project and it’s very easy to shoot yourself in the foot with this approach. I won’t fight against this, and you can easily Google a bad style of doing reactive. I don’t want to leave you with a cliffhanger, but I hope to show you a way, how to treat a reactive approach in the next chapters.

Where to go after

• http://reactivex.io
• https://github.com/ReactiveX/RxSwift
• https://refactoring.guru/

Back to the future

I’ve finished all my articles already. And now we can go back to the future 🏎…

1. What is Reactive Programming? iOS Edition
2. How to cook reactive programming. Part 1: Unidirectional architectures introduction.
3. How to cook reactive programming. Part 2: Side effects.
4. How to cook reactive programming. Part 3: Modularization.
5. How to cook reactive programming. Part 4: Testing.

What is Reactive Programming? was originally published in atimca on Medium, where people are continuing the conversation by highlighting and responding to this story.