Forem: Maxim Smirnov

The Composable Architecture tutorial

Maxim Smirnov — Fri, 23 Jul 2021 09:35:13 +0000

Disclaimer: This tutorial uses Xcode 12.4, Swift 5.3, and iOS 14.

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:

// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "DogBreedsComponent",
    platforms: [.iOS(.v14)],
    products: [
        .library(
            name: "DogBreedsComponent",
            targets: ["DogBreedsComponent"]
        ),
    ],
    dependencies: [
        // 1.
        .package(
            name: "swift-composable-architecture",
            url: "https://github.com/pointfreeco/swift-composable-architecture.git",
            .exact("0.17.0")
        ),
        // 2.
        .package(
            name: "Kingfisher",
            url: "https://github.com/onevcat/Kingfisher",
            .exact("6.2.1")
        )
    ],
    targets: [
        .target(
            name: "DogBreedsComponent",
            dependencies: [
                .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
                .product(name: "Kingfisher", package: "Kingfisher")
            ]
        ),
        .testTarget(
            name: "DogBreedsComponentTests",
            dependencies: [
                "DogBreedsComponent",
                .product(name: "ComposableArchitecture", package: "swift-composable-architecture")
            ]
        ),
    ]
)

We've added 2 dependencies to the package:

TCA framework itself
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:

import Kingfisher
import SwiftUI

extension KFImage {
    func header() - > some View {
        GeometryReader { geometry in
            resizable()
                .placeholder {
                    ProgressView()
                        .frame(height: 240)
                }
                .aspectRatio(contentMode: .fill)
                .frame(width: geometry.size.width, height: 240)
                .clipped()
        }
        .frame(height: 240)
    }
}

`String+Capitalized.swift`

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

extension String {
    var capitalizedFirstLetter: String {
        prefix(1).capitalized + dropFirst()
    }
}

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:

import SwiftUI

struct DogsView: View {
    var body: some View {
        Text("Hello, World!")
    }
}

struct SwiftUIView_Previews: PreviewProvider {
    static var previews: some View {
        DogsView()
    }
}

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.

extension DogsView {
    // 1.
    struct ViewState: Equatable {
        // 2.
        let filterText: String
        // 3.
        let loadingState: LoadingState
    }
}

// MARK: - Loading
// 3.
extension DogsView.ViewState {
    enum LoadingState: Equatable {
        case loaded(breeds: [String])
        case loading

        var breeds: [String] {
            guard case .loaded(let breeds) = self else { return [] }
            return breeds
        }

        var isLoading: Bool { self == .loading }
    }
}

Here’s what happened:

A struct ViewState which is going to represent DogsView layout.
A filterText property speaks for itself.
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:

extension DogsView {
    enum ViewAction: Equatable {
        case cellWasSelected(breed: String)
        case onAppear
        case filterTextChanged(String)
    }
}

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:

import ComposableArchitecture
import SwiftUI

struct DogsView: View {

    // 1.
    let store: Store<ViewState, ViewAction>

    var body: some View {
        // 2.
        WithViewStore(store) { viewStore in
            VStack {

                // 3.
                if viewStore.loadingState.isLoading {
                    ProgressView()
                } else {
                    searchBar(for: viewStore)
                    breedsList(for: viewStore)
                }

            }
            .navigationBarTitle("Dogs")
            .padding()
            // 4.
            .onAppear { viewStore.send(.onAppear) }
        }
    }
}

Here's what happened:

DogsView owns its own Store based on ViewState and ViewAction.
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.
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.
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.

@ViewBuilder
private func searchBar(for viewStore: ViewStore<ViewState, ViewAction>) - > some View {
    HStack {
        Image(systemName: "magnifyingglass")
        TextField(
            "Filter breeds",
            // 1.
            text: viewStore.binding(
                get: \.filterText,
                send: ViewAction.filterTextChanged
            )
        )
        .textFieldStyle(RoundedBorderTextFieldStyle())
        .autocapitalization(.none)
        .disableAutocorrection(true)
    }
}

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:

viewStore.binding(
    get: \.filterText,
    send: ViewAction.filterTextChanged
)

Is equivalent to:

Binding(
    get: { viewStore.filterText },
    set: { viewStore.send(.filterTextChanged($0)) }
)

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

@ViewBuilder
private func breedsList(for viewStore: ViewStore<ViewState, ViewAction>) - > some View {
    ScrollView {
        // 1.
        ForEach(viewStore.loadingState.breeds, id: \.self) { breed in
            VStack {
                // 2.
                Button(action: { viewStore.send(.cellWasSelected(breed: breed)) }) {
                    HStack {
                        Text(breed)
                        Spacer()
                        Image(systemName: "chevron.right")
                    }
                }
                Divider()
            }
            .foregroundColor(.primary)
        }
    }
    .padding()
}

Here's what happened:

By using ForEach we're going through the ViewState.breeds array and drawing cells for every breed.
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:

struct DogsView_Previews: PreviewProvider {
    static var previews: some View {
        NavigationView {
            DogsView(
                store: Store(
                    initialState: DogsView.ViewState(
                        filterText: "",
                        loadingState: .loaded(
                            breeds: [
                                "affenpinscher",
                                "african",
                                "airedale",
                                "akita",
                                "appenzeller",
                                "australian",
                                "basenji",
                                "beagle",
                                "bluetick"
                            ]
                        )
                    ),
                    reducer: .empty,
                    environment: ()
                )
            )
        }

        NavigationView {
            DogsView(
                store: Store(
                    initialState: DogsView.ViewState(
                        filterText: "",
                        loadingState: .loading
                    ),
                    reducer: .empty,
                    environment: ()
                )
            )
        }
    }
}

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:

struct DogsState: Equatable {
    var filterQuery: String
    var dogs: [Dog]

    static let initial = DogsState(filterQuery: "", dogs: [])
}

public struct Dog: Equatable {
    let breed: String
    let subBreeds: [String]
}

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:

public enum DogsAction: Equatable {
    case breedWasSelected(name: String)
    case dogsLoaded([Dog])
    case filterQueryChanged(String)
    case loadDogs
}

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.

struct DogsEnvironment {
    var loadDogs: () - > Effect<[Dog], Never>
}

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:

extension DogsState {
    // 1.
    static let reducer = Reducer<DogsState, DogsAction, DogsEnvironment> { state, action, environment in
        switch action {
        // 2.
        case .breedWasSelected:
            return .none
        // 3.
        case .dogsLoaded(let dogs):
            state.dogs = dogs
            return .none
        // 4.
        case .filterQueryChanged(let query):
            state.filterQuery = query
            return .none
        // 5.
        case .loadDogs:
            return environment
                .loadDogs()
                .map(DogsAction.dogsLoaded)
        }
    }
}

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.

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.
DogsAction.breedWasSelected is not handled at this moment, because we're going to extract navigation from the Dogs module itself.
DogsAction.dogsLoaded is an action used for DogsState to update with new dogs when they‘re loaded.
DogsAction.filterQueryChanged is an action that’s called when the user changes the filter query.
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.

extension DogsView.ViewState {
    // 1.
    static func convert(from state: DogsState) - > Self {
        .init(
            filterText: state.filterQuery,
            loadingState: loadingState(from: state)
        )
    }

    private static func loadingState(from state: DogsState) - > LoadingState {
        if state.dogs.isEmpty { return .loading }

        // 2.
        var breeds = state.dogs.map(\.breed.capitalizedFirstLetter)
        if !state.filterQuery.isEmpty {
            // 3.
            breeds = breeds.filter {
                $0.lowercased().contains(state.filterQuery.lowercased())
            }
        }

        return .loaded(breeds: breeds)
    }
}

Here's what happened:

A simple function which converts DogsState into DogsView.ViewState.
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.
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:.

class DogsViewStateConverterTest: XCTestCase {
    func testViewStateFilterTextGoesFromStateFilterQuery() {
        // Given
        let filterQuery = "filter"
        // When
        let viewState = DogsView.ViewState.convert(from: DogsState(filterQuery: filterQuery, dogs: []))
        // Then
        XCTAssertEqual(viewState.filterText, filterQuery)
    }

    func testViewStateLoadingStateIsLoadingIfStateDogsAndFilterQueryIsEmpty() {
        // When
        let viewState = DogsView.ViewState.convert(from: DogsState(filterQuery: "", dogs: []))
        // Then
        XCTAssertEqual(viewState.loadingState, .loading)
    }

    func testViewStateLoadingStateIsLoadedGoesFirstLetterCapitalizedStateDogsBreedWithEmptyFilterQuery() {
        // Given
        let dogs = [Dog(breed: "breed0", subBreeds: []), Dog(breed: "breed1", subBreeds: [])]
        // When
        let viewState = DogsView.ViewState.convert(from: DogsState(filterQuery: "", dogs: dogs))
        // Then
        XCTAssertEqual(viewState.loadingState, .loaded(breeds: ["Breed0", "Breed1"]))
    }

    func testViewStateLoadingStateIsLoadedGoesFirstLetterCapitalizedStateDogsBreedFilteredContainsByFilterQuery() {
        // Given
        let breed0 = "Abc0"
        let breed1 = "Abc1"
        let breed2 = "Def0"
        let breed3 = "Def1"
        let dogs = [breed0, breed1, breed2, breed3].map { Dog(breed: $0, subBreeds: []) }
        // When
        let viewState = DogsView.ViewState.convert(from: DogsState(filterQuery: "abc", dogs: dogs))
        // Then
        XCTAssertEqual(viewState.loadingState, .loaded(breeds: [breed0, breed1]))

    }
}

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

extension DogsState {
    var view: DogsView.ViewState {
        DogsView.ViewState.convert(from: self)
    }
}

Action conversion from ViewState

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

extension DogsAction {
    static func view(_ localAction: DogsView.ViewAction) - > Self {
        switch localAction {
        case .cellWasSelected(let breed):
            return .breedWasSelected(name: breed)
        case .onAppear:
            return .loadDogs
        case .filterTextChanged(let newValue):
            return .filterQueryChanged(newValue)
        }
    }
}

Showtime

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

extension DogsEnvironment {
    static let fake = DogsEnvironment(
        loadDogs: {
            Effect(
                value: [
                    Dog(breed: "affenpinscher", subBreeds: []),
                    Dog(breed: "bulldog", subBreeds: ["boston", "english", "french"])
                ]
            )
            .delay(for: .seconds(2), scheduler: DispatchQueue.main)
            .eraseToEffect()
        }
    )
}

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:

NavigationView {
    DogsView(
        // 1.
        store: Store(
            initialState: DogsState.initial,
            reducer: DogsState.reducer,
            environment: DogsEnvironment.fake
        )
        // 2.
        .scope(
            state: \.view,
            action: DogsAction.view
        )
    )
}

Here's what happened:

The first time we've only been interested in the layout, but here we used a business logic Store.
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:

class DogsStoreTests: XCTestCase {
    func testStore(initialState: DogsState = .initial)
    - > TestStore<DogsState, DogsState, DogsAction, DogsAction, DogsEnvironment> {
        TestStore(
            initialState: initialState,
            reducer: DogsState.reducer,
            environment: .failing
        )
    }
}

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?

extension DogsEnvironment {
    static let failing = DogsEnvironment(
        loadDogs: { .failing("DogsEnvironment.loadDogs") }
    )
}

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:

extension DogsStoreTests {
    func testDogsLoad() {

        // 1.
        let store = testStore()
        let expectedDogs = [Dog(breed: "dog", subBreeds: [])]
        // 2.
        store.environment.loadDogs = {
            Effect(value: expectedDogs)
        }

        // 3.
        store.send(.loadDogs)
        // 4.
        store.receive(.dogsLoaded(expectedDogs)) {
        // 5.
            $0.dogs = expectedDogs
        }
    }
}

Here's what happened:

Just a store: TestStore property, which we’ll use for testing.
Mock of loadDogs dependency.
Sending an action DogsAction.loadDogs for a request of dogs loading.
Expecting to receive dogs response as DogsAction.dogsLoaded.
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.

extension DogsStoreTests {
    func testFilterQueryChanged() {

        let store = testStore()
        let query = "buhund"

        store.send(.filterQueryChanged(query)) {
            $0.filterQuery = query
        }
    }
}

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:

public struct AppState: Equatable {
    // 1.
    var dogs: [Dog]
    // 2.
    var dogsInternal = DogsInternalState()
    // 3.
    var breedState: BreedState?

    public static let initial = AppState(dogs: [], breedState: nil)
}

Here's what happened:

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.
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.
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:

// 1.
struct DogsInternalState: Equatable {
    var filterQuery: String

    init() {
        self.filterQuery = ""
    }

    init(state: DogsState) {
        self.filterQuery = state.filterQuery
    }
}

// 2.
extension DogsState {
    init(
        internalState: DogsInternalState,
        dogs: [Dog]
    ) {

        self.init(
            filterQuery: internalState.filterQuery,
            dogs: dogs
        )
    }
}

// 3.
extension AppState {
    var dogsState: DogsState {
        get {
            DogsState(internalState: dogsInternal, dogs: dogs)
        }
        set {
            dogsInternal = .init(state: newValue)
            dogs = newValue.dogs
        }
    }
}

Here's what happened:

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.
This extension is just a convenience initializer from DogsInternalState, which contains any not shared property and the shared property itself.
A computed property dogsState which actually is a DogsState part of AppState.

AppAction

public enum AppAction: Equatable {
    case breed(BreedAction)
    case breedsDisappeared
    case dogs(DogsAction)
}

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:

extension AppState {
    static let reducerCore = Reducer<AppState, AppAction, Void> { state, action, _ in
        switch action {
        // 1.
        case .breed:
            return .none
        // 2.
        case .breedsDisappeared:
            state.breedState = nil
            return .none
        // 3.
        case .dogs(.breedWasSelected(let breed)):
            guard let dog = state.dogs.first(where: { $0.breed.lowercased() == breed.lowercased() }) else { fatalError() }
            state.breedState = BreedState(dog: dog, imageURL: nil)
            return .none
        // 4.
        case .dogs:
            return .none
        }
    }
}

Here's what happened:

Breed module actions inside AppReducer, in which we have no interest whatsoever.
AppAction.breedsDisappeared an action where we need to clear BreedState after a screen disappeared.
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.
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.

extension DogsEnvironment {

    private struct DogsResponse: Codable {
        let message: [String: [String]]
    }

    static let live = DogsEnvironment(
        loadDogs: {
            URLSession
                .shared
                .dataTaskPublisher(for: URL(string: "https://dog.ceo/api/breeds/list/all")!)
                .map(\.data)
                .decode(type: DogsResponse.self, decoder: JSONDecoder())
                .map { response in
                    response
                        .message
                        .map(Dog.init)
                        .sorted { $0.breed < $1.breed }
                }
                .replaceError(with: [])
                .receive(on: DispatchQueue.main)
                .eraseToEffect()
        }
    )
}

extension BreedEnvironment {

    private struct BreedImageResponse: Codable {
        let message: String?
    }

    static let live = BreedEnvironment(
        loadDogImage: { breed in
            URLSession
                .shared
                .dataTaskPublisher(for: URL(string: "https://dog.ceo/api/breed/\(breed)/images/random")!)
                .map(\.data)
                .decode(type: BreedImageResponse.self, decoder: JSONDecoder())
                .compactMap(\.message)
                .map(URL.init(string:))
                .replaceError(with: nil)
                .receive(on: DispatchQueue.main)
                .eraseToEffect()
        }
    )
}

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:

public extension AppState {
    static let reducer = Reducer<AppState, AppAction, Void>
        // 1.
        .combine(
            // 2.
            AppState.reducerCore,
            // 3.
            DogsState
                .reducer
                // 4.
                .pullback(
                    // 5.
                    state: \.dogsState,
                    // 6.
                    action: /AppAction.dogs,
                    // 7.
                    environment: { _ in DogsEnvironment.live }
                ),
            // 8.
            BreedState
                .reducer
                // 9.
                .optional()
                .pullback(
                    state: \.breedState,
                    action: /AppAction.breed,
                    environment: { _ in BreedEnvironment.live }
                )
        )
}

Here's what happened:

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.
As the first reducer here we use an AppReducer itself.
DogsReducer that we combined with a big AppReducer .That’s possible thanks to the AppState and AppAction structure.
DogsReducer is pulled back into AppReducer with the pullback function help. And as a result of this function we have AppReducer.
Via the usage of Swift KeyPath, we can say that DogsReducer is only going to work with the dogsState part of the AppState.
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.
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.
BreedReducer that’s also combined into the big AppReducer
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:

public struct RootView: View {

    let store: Store<AppState, AppAction>
    let dogsView: DogsView

    public init(store: Store<AppState, AppAction>) {
        self.store = store
        // 1.
        dogsView = DogsView(
            store: store.scope(
                state: \.dogsState.view,
                action: { local - > AppAction in
                    AppAction.dogs(
                        DogsAction.view(local)
                    )
                }
            )
        )
    }

    public var body: some View {
        // 2.
        WithViewStore(store.scope(state: \.breedState)) { viewStore in
            HStack {
                // 3.
                dogsView
                NavigationLink(
                    destination: breedView,
                    isActive: viewStore.binding(
                        get: { $0 != nil },
                        send: .breedsDisappeared
                    ),
                    label: EmptyView.init
                )
            }
        }
    }

    // 4.
    var breedView: some View {
        IfLetStore(
            store.scope(
                state: \.breedState?.view,
                action: { local - > AppAction in
                    AppAction.breed(
                        BreedAction.view(local)
                    )
                }
            ),
            then: BreedView.init(store:)
        )
    }
}

Here's what happened:

DogsView was created as an immutable variable because it exists in the whole app life cycle and basically the main view of the app.
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.
The body of the view contains DogsView and invisible NavigationLink which is backed by ViewStore Binding with a destination of BreedView.
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.

struct RootView_Previews: PreviewProvider {
    static var previews: some View {
        NavigationView {
            RootView(
                store: Store(
                    initialState: .initial,
                    reducer: AppState.combinedReducer,
                    environment: ()
                )
            )
        }
    }
}

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

@testable import DogBreedsComponent
import ComposableArchitecture
import XCTest

class AppStoreTests: XCTestCase {
    func testStore(initialState: AppState) - &gt; TestStore {
        TestStore(
            initialState: initialState,
            reducer: AppState.reducer,
            environment: ()
        )
    }
}

// MARK: - Navigation
extension AppStoreTests {
    func testNavigation() {

        let breedName = "Hound"
        let dog = Dog(breed: breedName, subBreeds: ["subreed1", "subbreed2"])

        let initialState = AppState(
            dogs: [Dog(breed: "anotherDog0", subBreeds: []), dog, Dog(breed: "anotherDog1", subBreeds: [])]
        )
        let store = testStore(initialState: initialState)

        store.send(.dogs(.breedWasSelected(name: breedName))) {
            $0.breedState = BreedState(dog: dog, imageURL: nil)
        }

        store.send(.breedsDisappeared) {
            $0.breedState = nil
        }
    }
}

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.

How to cook reactive programming. Part 4: Testing.

Maxim Smirnov — Fri, 23 Jul 2021 09:01:02 +0000

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.

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:

enum State {
    case initial
    case loading
    case loaded(data: [String])
}

enum Event {
    case dataLoaded(data: [String])
    case loadData
}

extension State {
    static func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .dataLoaded(let data):
            state = .loaded(data: data)
        case .loadData:
            state = .loading
        }
        return state
    }
}

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

func reduce(state: State, event: Event) -> State

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.

extension State {
    static func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .dataLoaded(let data):
            state = .loaded(data: data)
        case .loadData:
            state = .loading
        }
        return 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.

func testAfterDataLoadedEventStateWillBeChangedIntoLoadedWithReceivedData() {
    // Given
    let initialState: State = .initial
    let data = ["first", "second"]
    // When
    let resultState = State.reduce(state: initialState, event: .dataLoaded(data: data))
    // Then
    XCTAssertEqual(resultState, .loaded(data: data))
}

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.

    // User wants to open calendar event edit.
    // User doesn't have permission for editing a calendar.
    // Request should be sent to the user.
    // If the user authorized the permission.
    // Calendar event edit will be opened.
    // User added new event. -> Calendar State should be saved. And then the scene should be dismissed with Calendar State == nil.
    // After dismissing dismissedScene should be calendar.
    func testCalendarUserStoryWithPermission() {
        // Given
        let authorizedEvents = [PermissionType.events: PermissionStatus.authorized]
        let emptyPermissions: [PermissionType: PermissionStatus] = [:]
        let calendarEvent = CalendarEvent.testEvent

        // When
        let result = TestStore(
            scheduler: scheduler,
            disposeBag: disposeBag,
            permissionService: { .just(.authorized) }
        )
            .start(with: [.showScene(.calendar(event: calendarEvent)),
                          .userFinishedWithCalendarEditor(with: .saved)])

        // Then
        XCTAssertEqual(result[0].sceneForOpen, nil)
        XCTAssertEqual(result[0].permissions, emptyPermissions)

        XCTAssertEqual(result[1].sceneForOpen, .calendar(event: calendarEvent))
        XCTAssertEqual(result[1].permissions, emptyPermissions)

        XCTAssertEqual(result[2].sceneForOpen, .calendar(event: calendarEvent))
        XCTAssertEqual(result[2].permissions, authorizedEvents)

        XCTAssertEqual(result[3].sceneForOpen, nil)
        XCTAssertEqual(result[3].permissions, authorizedEvents)

        XCTAssertEqual(result[4].calendarState, .saved)

        XCTAssertEqual(result[5].calendarState, nil)
        XCTAssertEqual(result[5].dismissedScene, .calendar(result: .saved))
    }

If you read comments for this test you will be amazed by just how easily I've tested the whole used story. However, let's take a closer look, what happened here.

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?

import RxCocoa
import RxSwift
import RxTest

open class TestStore<State: Core.State, Event>: Store<State, Event> where State.Event == Event {

    private let observer: TestableObserver<State>
    private let scheduler: TestScheduler
    private let disposeBag: DisposeBag

    public init(scheduler: TestScheduler,
                disposeBag: DisposeBag,
                initial: State,
                feedBacks: [SideEffect<State, Event>]) {

        self.scheduler = scheduler
        self.disposeBag = disposeBag
        self.observer = scheduler.createObserver(State.self)
        super.init(initial: initial, feedBacks: feedBacks, reducer: State.reduce, scheduler: scheduler)

        stateBus
            .distinctUntilChanged()
            .drive(observer)
            .disposed(by: disposeBag)
    }

    public func start(with events: [Recorded<RxSwift.Event<Event>>] = []) -> [Recorded<RxSwift.Event<State>>] {
        scheduler
            .createColdObservable(events)
            .bind(to: eventBus)
            .disposed(by: disposeBag)
        scheduler.start()
        return observer.events
    }

    public func start(with events: [Event] = []) -> [State] {
        start(
            with: events
                .enumerated()
                .map { .next(($0.offset), $0.element) }
        )
            .compactMap(\.value.element)
    }
}

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:

struct StateStore {

    private let scheduler: TestScheduler

    init(
        scheduler: TestScheduler,
        permissionService: (PermissionType) -> Observable<PermissionStatus> = { _ in .never() },
        alertModule: (AlertModule.State) -> Observable<GeneralEvent> = { _ in .never() }
    )
}

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 episod which is free to watch.

The test itself looks like this:

store.assert(
    .environment {
        $0.currentDate = { 100 }
        $0.trainingProcessor = TrainingProcessor(
            applyGrade: { _, _, _ in flashCard },
            nextTraining: { _ in flashCard }
        )
    },
    .send(.fillTheBlanks(.goNext(grade))),
    .receive(.trainingCompleted(.bright)) {
        $0.currentScene = .showTheWord(WordSceneState(word: flashCard.word, kind: .correctAnswer))
        $0.trainingsRemain = 0
    }
)

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.

private let reducer: (inout State, Action, Environment) -> Effect<Action, Never>

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:

🛑 failed - Unexpected state mutation: …

      AppState(
        todos: [
          Todo(
    −       isComplete: false,
    +       isComplete: true,
            description: "Milk",
            id: 00000000-0000-0000-0000-000000000000
          ),
        ]
      )

(Expected: −, Actual: +)

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

Twitter(.atimca)
.subscribe(onNext: { newArcticle in
    you.read(newArticle)
})

How to cook reactive programming. Part 3: Modularization.

Maxim Smirnov — Fri, 23 Jul 2021 08:58:06 +0000

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.

As I mentioned in my previous article, we live in a world where applications are not one button flashlight apps any more. 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 architecture modularization. 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.

struct User {
    let id: AnyHashable
}

struct NewsState {
    var user: User
    var step: Step
}

extension NewsState {
    enum Step {
        case initial
        case loading
        case loaded(data: [String])
    }
}

enum NewsEvent {
    case dataLoaded(data: [String])
    case loadData
}

extension NewsState {
    static func reduce(state: NewsState, event: NewsEvent) -> NewsState {
        var state = state
        switch event {
        case .dataLoaded(let data):
            state.step = .loaded(data: data)
        case .loadData:
            state.step = .loading
        }
        return state
    }
}

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

struct AppState {
    var user: User
}

enum AppEvent {
    case newUserWasLoaded(User)
}

extension AppEvent {
    static func reduce(state: AppState, event: AppEvent) -> AppState {
        var state = state
        switch event {
        case .newUserWasLoaded(let user):
            state.user = user
        }
        return state
    }
}

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 Event and every State in the App module. Let's change the app a little bit to conform to the new requirement.

struct AppState {
    var user: User
    var newsState: NewsState?
}

enum AppEvent {
    case newUserWasLoaded(User)
    case newsEvents(NewsEvent)
}

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.

extension AppEvent {
    static func reduce(state: AppState, event: AppEvent) -> AppState {
        var state = state
        switch event {
        case .newUserWasLoaded(let user):
            state.user = user
        case .newsEvents(let event):
            switch event {
            case .dataLoaded(let data):
                state.newsState?.step = .loaded(data: data)
            case .loadData:
                state.newsState?.step = .loading
            }
        }
        return state
    }
}

It's a little bit clumsy, but it works. However, I've just generated another problem. NewsState is 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:

extension AppEvent {
    static func reduce(state: AppState, event: AppEvent) -> AppState {
        var state = state
        switch event {
        case .newUserWasLoaded(let user):
            state.user = user
        case .newsEvents(let event):
            if state.newsState == nil {
                state.newsState = NewsState(user: state.user, step: .initial)
            }
            switch event {
            case .dataLoaded(let data):
                state.newsState?.step = .loaded(data: data)
            case .loadData:
                state.newsState?.step = .loading
            }
        }
        return state
    }
}

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.

extension AppEvent {
    static func reduce(state: AppState, event: AppEvent) -> AppState {
        var state = state
        switch event {
        case .newUserWasLoaded(let user):
            state.user = user
        case .newsEvents(let event):
            if state.newsState == nil {
                state.newsState = NewsState(user: state.user, step: .initial)
            }
            state.newsState = NewsState.reduce(state: state.newsState!, event: event)
        }
        return state
    }
}

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.

typealias Reducer = (AppState, AppEvent) -> AppState

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.

func combine(_ reducers: Reducer...) -> Reducer

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.

func combine(_ reducers: Reducer...) -> Reducer {
    return { state, event in
        reducers.reduce(state) { state, reducer in
            reducer(state, event)
        }
    }
}

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

let firstReducer: Reducer = { state, event in
    var state = state
    switch event {
    case .newUserWasLoaded(let user):
        state.user = user
    default:
        return state
    }
    return state
}

let secondReducer: Reducer = { state, event in
    var state = state
    switch event {
    case .newsEvents:
        state.newsState?.step = .loading
    default:
        return state
    }
    return state
}

let resultReducer = combine(firstReducer, secondReducer)
let initialState = AppState(user: User(id: ""), newsState: NewsState(user: User(id: ""), step: .initial))

let firstMutation = resultReducer(initialState, .newUserWasLoaded(User(id: 1)))
let secondMutation = resultReducer(firstMutation, .newsEvents(.loadData))

print(secondMutation.user.id)
print(secondMutation.newsState!.step)

// Console output:
// 1
// loading

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 combine function 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:

func reduce(state: NewsState, event: NewsEvent) -> NewsState

And AppReducer this:

func reduce(state: AppState, event: AppEvent) -> AppState

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

func reduce(state: NewsState, event: AppEvent) -> NewsState

into

func reduce(state: AppState, event: AppEvent) -> AppState

As usual I want to start with a function definition:

func transform(newsReducer: (NewsState, AppEvent) -> NewsState) -> Reducer

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

func transform(newsReducer: (NewsState, AppEvent) -> NewsState) -> Reducer {
    return { appState, appEvent in
        ???
    }
}

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:

func transform(
    newsReducer: (NewsState, AppEvent) -> NewsState,
    appStateIntoNews: (AppState) -> NewsState
) -> Reducer {
    return { appState, appEvent in
        let newsState = appStateIntoNews(appState)
        return newsReducer(newsState, appEvent)
    }
}

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 ews reducer result into AppState. We already know that NewsState is a part of the AppState, so it shouldn’t be so hard.

func transform(
    newsReducer: @escaping (NewsState, AppEvent) -> NewsState,
    appStateIntoNews: @escaping (AppState) -> NewsState
) -> Reducer {
    return { appState, appEvent in
        var appState = appState
        let newsState = appStateIntoNews(appState)
        let newNewsState = newsReducer(newsState, appEvent)
        appState.newsState = newNewsState
        return appState
    }
}

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.

func transform(
    newsReducer: @escaping (NewsState, AppEvent) -> NewsState,
    appStateIntoNews: @escaping (AppState) -> NewsState,
    mutateAppStateWithNewsState: @escaping (AppState, NewsState) -> AppState
) -> Reducer {
    return { appState, appEvent in
        let newsState = appStateIntoNews(appState)
        let newNewsState = newsReducer(newsState, appEvent)
        return mutateAppStateWithNewsState(appState, newNewsState)
    }
}

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.

func transform(
    newsReducer: @escaping (NewsState, AppEvent) -> NewsState,
    stateKeyPath: WritableKeyPath<AppState, NewsState>
) -> Reducer {
    return { appState, appEvent in
        var appState = appState
        appState[keyPath: stateKeyPath] = newsReducer(appState[keyPath: stateKeyPath], appEvent)
        return appState
    }
}

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:

func transform(newsReducer: (NewsState, NewsEvent) -> NewsState) -> Reducer

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

func transform(
    newsReducer: @escaping (NewsState, NewsEvent) -> NewsState,
    stateKeyPath: WritableKeyPath<AppState, NewsState>
) -> Reducer {
    return { appState, appEvent in
        var appState = appState
        appState[keyPath: stateKeyPath] = newsReducer(appState[keyPath: stateKeyPath], appEvent)
        return appState
    }
}

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.

enum AppEvent {
    case newUserWasLoaded(User)
    case newsEvents(NewsEvent)

    var newsEvent: NewsEvent? {
        guard case .newsEvents(let event) = self else { return nil }
        return event
    }
}

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.

func transform(
    newsReducer: @escaping (NewsState, NewsEvent) -> NewsState,
    stateKeyPath: WritableKeyPath<AppState, NewsState>
) -> Reducer {
    return { appState, appEvent in
        guard let newsEvent = appEvent.newsEvent else { return appState }
        var appState = appState
        appState[keyPath: stateKeyPath] = newsReducer(appState[keyPath: stateKeyPath], newsEvent)
        return appState
    }
}

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?

func transform(
    newsReducer: @escaping (NewsState, NewsEvent) -> NewsState,
    stateKeyPath: WritableKeyPath<AppState, NewsState>,
    toNewsEvent: @escaping (AppEvent) -> NewsEvent?
) -> Reducer {
    return { appState, appEvent in
        guard let newsEvent = toNewsEvent(appEvent) else { return appState }
        var appState = appState
        appState[keyPath: stateKeyPath] = newsReducer(appState[keyPath: stateKeyPath], newsEvent)
        return appState
    }
}

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?

func combine<State, Event>(_ reducers: (State, Event) -> State...) -> (State, Event) -> State {
    return { state, event in
        reducers.reduce(state) { state, reducer in
            reducer(state, event)
        }
    }
}

func transform<GlobalState, GlobalEvent, LocalState, LocalEvent>(
    localReducer: @escaping (LocalState, LocalEvent) -> LocalState,
    stateKeyPath: WritableKeyPath<GlobalState, LocalState?>,
    toLocalEvent: @escaping (GlobalEvent) -> LocalEvent?
) -> (GlobalState, GlobalEvent) -> GlobalState {
    return { globalState, globalEvent in
        guard
            let localEvent = toLocalEvent(globalEvent),
            let localState = globalState[keyPath: stateKeyPath]
            else { return globalState }
        var globalState = globalState
        globalState[keyPath: stateKeyPath] = localReducer(localState, localEvent)
        return globalState
    }
}

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.

let appReducer: Reducer = { state, event in
    var state = state
    switch event {
    case .newUserWasLoaded(let user):
        state.user = user
    default:
        return state
    }
    return state
}


let combinedReducer = combine(
    transform(
        localReducer: NewsState.reduce(state:event:),
        stateKeyPath: \AppState.newsState,
        toLocalEvent: \AppEvent.newsEvent
    ),
    appReducer
)

let firstMutation = combinedReducer(initialState, .newUserWasLoaded(User(id: 1)))
let secondMutation = combinedReducer(firstMutation, .newsEvents(.loadData))

print(secondMutation.user.id)
print(secondMutation.newsState!.step)

// Console output:
// 1
// loading

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.

class NewsStore {
    @Published private(set) var state: NewsState
    private let reducer: (NewsState, NewsEvent) -> NewsState

    init(
        initialState: NewsState,
        reducer: @escaping (NewsState, NewsEvent) -> NewsState
    ) {
        self.state = initialState
        self.reducer = reducer
    }

    func accept(event: NewsEvent) {
        state = reducer(state, event)
    }
}

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.

class ViewController: UIViewController {
    var cancellables: Set<AnyCancellable> = []
}

enum InputEvent {
    case newUserWasLoaded(User)

    var user: User {
        switch self {
        case .newUserWasLoaded(let user):
            return user
        }
    }
}

enum OutputEvent {
    case newsStateStepWasUpdated(NewsState.Step)
}

class NewsStore {
    @Published private(set) var state: NewsState
    private let input: AnyPublisher<InputEvent, Never>
    private let reducer: (NewsState, NewsEvent) -> NewsState

    init(
        initialState: NewsState,
        input: AnyPublisher<InputEvent, Never>,
        reducer: @escaping (NewsState, NewsEvent) -> NewsState
    ) {
        self.state = initialState
        self.reducer = reducer
        self.input = input
    }

    func accept(event: NewsEvent) {
        state = reducer(state, event)
    }

    func start() -> (UIViewController, AnyPublisher<OutputEvent, Never>) {

        let viewController = ViewController()

        input
            .map(\.user)
            .sink { self.state.user = $0 }
            .store(in: &viewController.cancellables)

        let output = $state
            .map(\.step)
            .map(OutputEvent.newsStateStepWasUpdated)
            .setFailureType(to: Never.self)
            .eraseToAnyPublisher()

        return (viewController, output)
    }
}

What are all the nteresting 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 sink subscription. 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.

    public func scope<LocalState, LocalEvent: ComponentableEvent>(
        state toLocalState: @escaping (State) -> LocalState,
        event toGlobalEvent: @escaping (LocalEvent) -> Event,
        feedBacks: [SideEffect<LocalState, LocalEvent>]
    ) -> Store<LocalState, LocalEvent> where LocalEvent.State == LocalState {

        let localStore = Store<LocalState, LocalEvent>(
            initial: toLocalState(state),
            feedBacks: feedBacks,
            reducer: { localState, localEvent in

                var state = self.state
                self.reducer(&state, toGlobalEvent(localEvent))
                localState = toLocalState(state)

                if localEvent != LocalEvent.updateFromOutside(localState) {
                    self.accept(toGlobalEvent(localEvent))
                }

        }
        )

        $state
            .map(toLocalState)
            .removeDuplicates()
            .sink { [weak localStore] newValue in
                localStore?.accept(.updateFromOutside(newValue))
            }
            .store(in: &localStore.disposeBag)

        return localStore
    }

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. Unidirectional architectures 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

Twitter(.atimca)
.subscribe(onNext: { newArcticle in
    you.read(newArticle)
})

How to cook reactive programming. Part 2: Side effects.

Maxim Smirnov — Thu, 18 Jun 2020 15:56:06 +0000

Despite the number, this is the third article about reactive programming. Today we are going to talk about how to handle side effects while using unidirectional approaches.

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.

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.

enum State {
    case initial
    case loading
    case loaded(data: [String])
}

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 State data 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.

struct State {
    var value: Int?

    static func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .changeValue(let newValue):
            state.value = newValue
        }
        return state
    }
}

class Store {
    var state: State

    func accept(event: Event) {
        state = reduce(state: state, event: event)
    }
}

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 theState 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.

func loadNewsTitles(completionHandler: ([String]) -> ()) {
    completionHandler(["title1", "title2"])
}

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:

enum State {
    case initial
    case loading
    case loaded(data: [String])
}

enum Event {
    case dataLoaded(data: [String])
    case loadData
}

func loadNewsTitles(completionHandler: (Event) -> ()) {
    loadNewsTitles { data in
        completionHandler(.dataLoaded(data: data))
    }
}

extension State {
    static func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .dataLoaded(let data):
            state = .loaded(data: data)
        case .loadData:
            state = .loading
        }
        return state
    }
}

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.

let middleware: Middleware = { store, getState in
    return { next in
        return { event in
            // perform middleware logic
            switch event {
            case .loadData:
                loadNewsTitles { event in
                    store.accept(event)
                }
            case .dataLoaded:
                break
            }

            // call next middleware
            return next(event)
        }
    }
}

As you can see a Middleware could be treated as an asynchronous preReducer. 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.

func reducer(state: inout State, event: Event, environment: Environment) -> Effect

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?

struct Environment {
    let loadNewsTitles: (Event) -> ()
}

struct Effect {
    init(work: ((State) -> ())? = nil)
    func performWorkItem() -> Event
}

extension Effect {
    /// An effect that does nothing and completes immediately.
    static let none = Effect()
}

extension Effect {
    static func loadNewTitlesEffect(loadNewsTitles: (Event) -> ()) -> Effect
}

func reducer(state: inout State, event: Event, environment: Environment) -> Effect {
    switch event {
    case .dataLoaded(data: let data):
        state = .loaded(data: data)
        return .none
    case .loadData:
        return Effect.loadNewTitlesEffect(loadNewsTitles: environment.loadNewsTitles)
    }
}

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. They also have a website with a lot of useful videos available on it. It's not free, but I have a promocode for you. I'm sorry I couldn't miss this chance...

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 reacts to 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:

extension State {
    var loadQuery: Void? {
        guard case .loading = self else { return nil }
        return ()
    }
}

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.

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:

enum State: Equatable {
    case initial
    case loading
    case loaded(data: [String])
}

enum Event {
    case dataLoaded(data: [String])
    case loadData
}

extension State {
    var loadQuery: Bool {
        guard case .loading = self else { return false }
        return true
    }
}

extension State {
    static func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .dataLoaded(let data):
            state = .loaded(data: data)
        case .loadData:
            state = .loading
        }
        return state
    }
}

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.

func loadNewsTitles() -> AnyPublisher<[String], Never> {
    ["title1", "title2"]
        .publisher
        .delay(for: .microseconds(500), scheduler: DispatchQueue.main)
        .collect()
        .eraseToAnyPublisher()
}

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.

struct SideEffects {
    let loadNewTitles: () -> AnyPublisher<[String], Never>

    func downloadNewTitles() -> AnyPublisher<Event, Never> {
        loadNewTitles()
            .map(Event.dataLoaded)
            .eraseToAnyPublisher()
    }
}

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.

typealias Reducer = (State, Event) -> State

class Store {
    @Published private(set) var state: State
    private let reducer: Reducer
    private let sideEffects: SideEffects

    init(
        initialState: State,
        reducer: @escaping Reducer,
        sideEffects: SideEffects
    ) {
        self.state = initialState
        self.reducer = reducer
        self.sideEffects = sideEffects
    }

    func accept(event: Event) {
        state = reducer(state, event)
    }

    func start() -> AnyCancellable {
        $state
            .map(\.loadQuery)
            .removeDuplicates()
            .filter { $0 == true }
            .map { _ in () }
            .flatMap(sideEffects.downloadNewTitles)
            .sink(receiveValue: accept(event:))
    }
}

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.

let store = Store(
    initialState: .initial,
    reducer: State.reduce(state:event:),
    sideEffects: SideEffects(
        loadNewTitles: loadNewsTitles
    )
)
var cancellables: [AnyCancellable] = []

store
    .start()
    .store(in: &cancellables)

store
    .$state
    .removeDuplicates()
    .sink { state in print(state) }
    .store(in: &cancellables)

store.accept(event: .loadData)

// Console output

// initial
// loading
// loaded(data: ["title1", "title2"])

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 two Cancelables 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<State, Event> = (Observable<State>) -> Observable<Event>

extension Observable {
    public static func system<State, Event>(
        initialState: State,
        reduce: @escaping (State, Event) -> State,
        feedback: Feedback<State, Event>...
    ) -> Observable<State>
}

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, map or 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.

    /// Creates a middleware function using SimpleMiddleware to create a ReSwift Middleware function.
    func createMiddleware<State: StateType>(_ middleware: @escaping SimpleMiddleware<State>) -> Middleware<State> {

        return { dispatch, getState in
            return { next in
                return { action in

                    let context = MiddlewareContext(dispatch: dispatch, getState: getState, next: next)
                    if let newAction = middleware(action, context) {
                        next(newAction)
                    }
                }
            }
        }
    }

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))

Twitter(.atimca)
.subscribe(onNext: { newArcticle in
    you.read(newArticle)
})

How to cook reactive programming. Part 1: Unidirectional architectures introduction

Maxim Smirnov — Mon, 25 May 2020 10:35:56 +0000

Recently I wrote an article What is Reactive Programming? iOS Edition where in a simple way I described how to build your own Reactive Framework, and helped you to understand that no-one should be scared by the reactive approach. The previous article could now be named How to cook reactive programming. Part 0., since this is a continuation. I would recommend reading the previous article if you are not familiar with the reactive programming concepts.

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.

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:

class Foo {
    var val: Int?

    init(val: Int?) {
        self.val = val
    }
}

var array: [Foo] = [Foo(val: 1), Foo(val: 2), Foo(val: 3)]

array = array.map { element in
    array[0].val = element.val
    return element
}

// array == 3, 2, 3

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.

struct Foo {
    var val: Int?
}

var array: [Foo] = [Foo(val: 1), Foo(val: 2), Foo(val: 3)]

array = array.map { element in
    array[0].val = element.val
    return element
}

// array == 1, 2, 3

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.

struct Foo {
    let val: Int?
}

var array: [Foo] = [Foo(val: 1), Foo(val: 2), Foo(val: 3)]

array = array.map { element in
    array[0].val = element.val // Cannot assign to property: 'val' is a 'let' constant
    return element
}

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.

struct State {
    var value: Int?
}

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.

protocol Observer {
    func stateWasChanged(with newState: State)
}

struct State {
    var value: Int?
}

class Store {
    var state: State = State() {
        didSet {
            observers.forEach { observer in
                observer.stateWasChanged(with: state)
            }
        }
    }

    var observers: [Observer] = []
}

struct Foo: Observer {
    func stateWasChanged(with newState: State) {
        print("It's newState from Foo: ", newState.value)
    }
}

struct Boo: Observer {
    func stateWasChanged(with newState: State) {
        print("It's newState from Boo: ", newState.value)
    }
}

let foo = Foo()
let boo = Boo()

let store = Store()
store.observers = [foo, boo]
store.state.value = 10

// It's newState from Foo:  10
// It's newState from Boo:  10

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.

enum Event {
    case changeValue(newValue: Int?)
}

class Store {
    private var state: State

    func accept(event: Event) {
        switch event {
        case .changeValue(let newValue):
            state.value = newValue
        }
    }
}

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:

func reduce<Result>(_ initialResult: Result, _ nextPartialResult: (Result, Element) -> Result) -> Result

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.

class Store {
    func accept(event: Event) {
        state = reduce(state: state, event: event)
    }

    func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .changeValue(let newValue):
            state.value = newValue
        }
        return state
    }
}

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.

protocol Observer {
    func stateWasChanged(with newState: State)
}

struct State {
    var value: Int?

    static func reduce(state: State, event: Event) -> State {
        var state = state
        switch event {
        case .changeValue(let newValue):
            state.value = newValue
        }
        return state
    }
}

enum Event {
    case changeValue(newValue: Int?)
}

class Store {
    var state: State = State() {
        didSet {
            observers.forEach { observer in
                observer.stateWasChanged(with: state)
            }
        }
    }

    var observers: [Observer] = []

    func accept(event: Event) {
        state = State.reduce(state: state, event: event)
    }
}

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))

Twitter(.atimca)
.subscribe(onNext: { newArcticle in
    you.read(newArticle)
})

What is Reactive Programming? iOS Edition

Maxim Smirnov — Tue, 14 Apr 2020 18:40:48 +0000

There are many articles about Reactive Programming and different implementations on the internet. However, most of them are about practical usage, and only a few concern what Reactive Programming is, and how it actually works. In my opinion, it is more important to understand how frameworks work deep inside - spoiler: nothing actually complicated there - rather than starting to use a number of traits and operators meanwhile shooting yourself in the foot.

So, what is ~~RxSwift~~ ~~Combine~~ 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:

public final class BehaviorSubject<Element> {

    public func value() throws -> Element {
        self._lock.lock(); defer { self._lock.unlock() }
            if self._isDisposed {
                throw RxError.disposed(object: self)
            }

            if let error = self._stoppedEvent?.error {
                throw error
            }
            else {
                return self._element
            }
    }

    func _synchronized_on(_ event: Event<Element>) -> Observers {
        self._lock.lock(); defer { self._lock.unlock() }
        if self._stoppedEvent != nil || self._isDisposed {
            return Observers()
        }

        switch event {
        case .next(let element):
            self._element = element
        case .error, .completed:
            self._stoppedEvent = event
        }

        return self._observers
    }
}

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:

let sequence = [1, 2, 3, 4, 5]

And I want to iterate through it. Easy enough:

var iterator = sequence.makeIterator()

while let item = iterator.next() {
    print(item)
}

// 1 2 3 4 5

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:

sequence.forEach { item in
    print(item)
}

// 1 2 3 4 5

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.

extension Array {
    func forEach(_ body: @escaping (Element) -> Void) {
        for element in self {
            body(element)
        }
    }
}

sequence.forEach {
    print($0)
}

// 1 2 3 4 5

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

func handle(_ item: Int) {
    print(item)
}

sequence.forEach(handle)

// 1 2 3 4 5

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

extension Array {
    func forEach(
        on queue: DispatchQueue,
        body: @escaping (Element) -> Void) {
        for element in self {
            queue.async { body(element) }
        }
    }
}

let queue = DispatchQueue(
    label: "com.reactive",
    qos: .background,
    attributes: .concurrent
)

sequence.forEach(on: queue, body: handle)

// Output is unpredictable, but we'd see all 5 values.

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.:

class Observer<Element> {

    private let on: (Element) -> Void

    init(_ on: @escaping (Element) -> Void) {
        self.on = on
    }

    func on(_ event: Element) {
        on(event)
    }
}

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

class Observable<Element> {

    var value: Element

    init(value: Element) {
        self.value = value
    }
}

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.

class Observable<Element> {
    private var observers: [Observer<Element>] = []

    var value: Element {
        didSet {
            observers.forEach { $0.on(self.value) }
        }
    }

    init(value: Element) {
        self.value = value
    }

    func subscribe(on observer: Observer<Element>) {
        observers.append(observer)
    }
}

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

let observer = Observer<Int> {
    print($0)
}

let observable = Observable<Int>(value: 0)
observable.subscribe(on: observer)

for i in 1...5 {
    observable.value = i
}

// 1, 2, 3, 4, 5

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.

class WeakRef<T> where T: AnyObject {

    private(set) weak var value: T?

    init(value: T?) {
        self.value = value
    }
}

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

class Observable<Element> {
    private typealias WeakObserver = WeakRef<Observer<Element>>
    private var observers: [WeakObserver] = []

    var value: Element {
        didSet {
            observers.forEach { $0.value?.on(self.value) }
        }
    }

    init(value: Element) {
        self.value = value
    }

    func subscribe(on observer: Observer<Element>) {
        observers.append(.init(value: observer))
    }
}

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

let observer1 = Observer<Int> {
    print("first:  ", $0)
}

var observer2: Observer! = Observer<Int> {
    print("second: ", $0)
}

let observable = Observable<Int>(value: 0)
observable.subscribe(on: observer1)
observable.subscribe(on: observer2)

for i in 1...5 {
    observable.value = i

    if i == 2 {
        observer2 = nil
    }
}

/*
first:   1
second:  1
first:   2
second:  2
first:   3
first:   4
first:   5
*/

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.

class Observable<Element> {
    private typealias WeakObserver = WeakRef<Observer<Element>>
    private var observers: [WeakObserver] = []

    var value: Element {
        didSet {
            observers.forEach { $0.value?.on(self.value) }
        }
    }

    init(value: Element) {
        self.value = value
    }

    func subscribe(onNext: @escaping (Element) -> Void) -> Observer<Element> {
        let observer = Observer(onNext)
        observers.append(.init(value: observer))
        return observer
    }
}

let observable = Observable<Int>(value: 0)
let observer = observable.subscribe {
    print($0)
}

for i in 1...5 {
    observable.value = i
}

// 1, 2, 3, 4, 5

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.

let observable = Observable<Int>(value: 0)
let observer = observable.subscribe {
    print($0)
}

for i in 1...5 {
    DispatchQueue(label: "1", qos: .background, attributes: .concurrent).asyncAfter(deadline: .now() + 0.3) {
        observable.value = i
    }
}

for i in 6...9 {
    DispatchQueue(label: "2", qos: .background, attributes: .concurrent).asyncAfter(deadline: .now() + 0.3) {
        observable.value = i
    }
}

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.

class Observable<Element> {
    private typealias WeakObserver = WeakRef<Observer<Element>>
    private var observers: [WeakObserver] = []
    private let isolationQueue = DispatchQueue(label: "", attributes: .concurrent)

    private var _value: Element
    var value: Element {
        get {
            isolationQueue.sync { _value }
        }
        set {
            isolationQueue.async(flags: .barrier) {
                self._value = newValue
                self.observers.forEach { $0.value?.on(newValue) }
            }
        }
    }

    init(value: Element) {
        self._value = value
    }

    func subscribe(onNext: @escaping (Element) -> Void) -> Observer<Element> {
        let observer = Observer(onNext)
        observers.append(.init(value: observer))
        return observer
    }
}

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.

enum Event<Element> {
    case next(Element)
    case completed
    case error(Error)
}

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.

let sequence = [1, 2, 3, 4, 5]
let newSequence = sequence
    .map { element in
        return element + 1
}

// newSequence: 2, 3, 4, 5, 6

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.

class Observable<Element> {
    typealias WeakObserver = WeakRef<Observer<Element>>
    private var observers: [WeakObserver] = []
    private let isolationQueue = DispatchQueue(label: "", attributes: .concurrent)

    private var _value: Element
    var value: Element {
        get {
            isolationQueue.sync { _value }
        }
        set {
            isolationQueue.async(flags: .barrier) {
                self._value = newValue
                self.observers.forEach { $0.value?.on(newValue) }
            }
        }
    }
    private var transform: ((Element) -> Element)?

    init(value: Element) {
        self._value = value
    }

    func subscribe(onNext: @escaping (Element) -> Void) -> Observer<Element> {
        let transform = self.transform ?? { $0 }
        let observer = Observer<Element> { element in
            onNext(transform(element))
        }
        observers.append(.init(value: observer))
        return observer
    }

    func map(_ transform: @escaping (Element) -> Element) -> Observable<Element> {
        self.transform = transform
        return self
    }
}

let observable = Observable<Int>(value: 0)
let observer = observable
    .map { $0 + 1 }
    .subscribe { print($0) }

for i in 1...5 {
    observable.value = i
}

// 2, 3, 4, 5, 6

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.

Forem: Maxim Smirnov

The Composable Architecture tutorial

Introduction

What is The Composable Architecture

The Setup

Adding necessary dependencies to the Project

Extras

KFImage+Header.swift

String+Capitalized.swift

Dogs module

Build the Dogs screen

ViewState

ViewAction

Layout

Layout Testing

Build Dogs business logic

State

Action

Environment

Reducer

Finalize Dogs module

ViewState conversion from State

Action conversion from ViewState

Showtime

Dogs module testing

TestStore

Breeds module

App module

AppState

AppAction

AppReducer

RootView

App tests

Where to go next

How to cook reactive programming. Part 4: Testing.

Reducer

Testing the system

TCA

Outro

How to cook reactive programming. Part 3: Modularization.

Composable Reducers

Fully separated approach

What about Side Effects?

Outro

How to cook reactive programming. Part 2: Side effects.

Intro

What are Side Effects?

Why is the architecture called unidirectional?

Which types of side effects exist?

Middleware

Effects

Query Feedback

Why do we need a reactive framework for this?

Outro

How to cook reactive programming. Part 1: Unidirectional architectures introduction

The problems

Unpredicted mutations

MV family

One ring to rule them all

What is Reactive Programming? iOS Edition

The tale of two friends

Where to go after

`KFImage+Header.swift`

`String+Capitalized.swift`