Forem: Omar 👾

Side Effects with Combine

Omar 👾 — Tue, 20 Apr 2021 14:07:52 +0000

One of the benefits of adopting Combine's publisher approach to asynchronous programing is that every operation is a stream or pipeline that we can subscribe and react to via powerful operators.

This works really well for situations where would like to execute code outside the scope of a publisher as certain events occur. Such executions are often described as side effects

What are side effects?

For the context of this article and within the realm of Combine, we can define side effects as invocations that do not transform the output of a publisher which are triggered when certain events occur during a publisher's lifecycle.

Common use cases for side effects in reactive programming include but are not limited to:

Debugging
Error handling
Event tracking
Persisting data

So how would we go about implementing side effects in Combine?

Handling events

Combine provides a useful handleEvents() operator that allows us to provide closures that can be performed when certain publisher events occur. This makes it possible, for example, to log relevant information in the event of a non-fatal error:

todoRepository.addTodo(title: title)
    .handleEvents(receiveCompletion: { [logger] completion in
        switch completion {
        case .failure(let error):
            logger.error(error)
            debugPrint("an error occurred: \(error)")
        case .finished:
            debugPrint("addTodo publisher completed")
        }
    })

In addition to the receiveCompletion parameter, the operator provides other events that we can hook into that can serve a variety of use cases:

receiveSubscription:

Executes when the publisher receives the subscription from the upstream publisher. A possible use case for this would be to launch a background process/experience whenever a consumer subscribes:

videoCallProvider.acceptCall()
    .handleEvents(receiveSubscription: { [cameraManager] _ in
        cameraManager.startCapture()
    })

receiveOutput:

Executes when the publisher receives a value from the upstream publisher. In the pattern we put together in my previous article Managing View State Combine, we could use this to keep track of Inputs as users interact with our views:

inputSubject
    .handleEvents(receiveOutput: { [eventTracker] input in
        switch input {
        case .addTodo:
            eventTracker.track(.todoAdded)
        case .todoRemoved:
            eventTracker.track(.todoRemoved)
        }
    })

receiveCancel:

Executes when the downstream receiver cancels publishing. A good use case for this would be disposing of no longer needed processes that live outside of a publisher's lifecycle:

videoCallProvider.acceptCall()
    .handleEvents(receiveCancel: { [cameraManager] in
        cameraManager.endCapture()
    })

receiveRequest:

Executes when the publisher receives a request for more elements. Had a hard time thinking of a good use case for this one, but could come in handy during situations where we would like know the amount of outputs being requested by a subscriber.

Note: closures passed to these parameters are escaped, and as a result, subject to the dangers of strong reference cycles or wrong thread executions. Make sure to avoid strong references by using capture lists and insuring the closure is performed on the appropriate thread via the receive(on:) operator.

A tip when handling events 💡:

You might have noticed when typing handleEvents, Xcode will autofill all possible parameters of the method. This can be annoying to deal with, especially if we find ourselves handling specific events frequently. Lets try and fix that with some convenient extensions:

extension Publisher {
    func handleOutput(_ receiveOutput: @escaping ((Self.Output) -> Void)) -> Publishers.HandleEvents<Self> {
        handleEvents(receiveOutput: receiveOutput)
    }

    func handleError(_ receiveError: @escaping ((Self.Failure) -> Void)) -> Publishers.HandleEvents<Self> {
        handleEvents(receiveCompletion: { completion in
            switch completion {
            case .failure(let error):
                receiveError(error)
            case .finished:
                ()
            }
        })
    }
}

With the extensions above, not only will interacting with the operator become more enjoyable, but the end result ends ups looking more readable:

todoRepository.addTodo(title: title)
    .handleOutput({ [eventTracker] _ in
        eventTracker.track(.todoAdded)
    })
    .handleError({ [logger] error in
        logger.error(error)
        debugPrint("an error occurred: \(error)")
    })

Conclusion

In situations where we would need to execute some code along side other asynchronous code, the Combine framework can serve as a good candidate given its elegant approach to performing side effects.

If you liked this article, follow me on Twitter for more updates and content about Swift development, architectural patterns and clean code.

Managing View State With Combine

Omar 👾 — Thu, 15 Apr 2021 17:25:06 +0000

Data Flow

SwiftUI's built in state management system does a great a job in providing an out of the box data flow solution that alleviates a lot of the pain points associated with manually updating UI based on state changes.

As your codebase grows and you find yourself leaning towards incorporating common architectural patterns, you'll likely come across the need to separate some state specific logic into a view model. Swift's Combine framework provides some great property wrappers to ease this transition via @PublishSubject and @ObservedObject.

There are some great articles that go into depth about these topics. I highly suggest you check them out if you aren't yet familiar with these concepts:

Continuing where the articles left off, I've put together a TodoListView that observes and reacts to a ViewState published by its ViewModel:

struct TodoListView: View {
    @ObservedObject
    private var viewModel = ViewModel()
    var body: some View {
        content(viewModel.viewState)
            .onAppear {
                viewModel.loadTodos()
            }
    }

    @ViewBuilder
    private func content(_ state: ViewState) -> some View {
        switch state {
        case .loading:
            ProgressView()
        case .error:
            Text("Oops something went wrong")
                .padding()
        case .content(let todos):
            List {
                ForEach(todos) { todo in
                    Text(todo.title)
                }
            }
        }
    }
}

extension TodoListView {
    enum ViewState {
        case loading
        case content(todos: [Todo])
        case error
    }

    class ViewModel: ObservableObject {
        @Published
        var viewState: ViewState = .loading
        private let todoRepository = TodoRepistory()
        private var cancellables = Set<AnyCancellable>()

        func loadTodos() {
            self.viewState = .loading
            todoRepository.getTodos()
                .sink { [weak self] completion in
                    switch completion {
                    case .failure:
                        self?.viewState = .error
                    case .finished:
                        ()
                    }
                } receiveValue: { [weak self] todos in
                    self?.viewState = .content(todos: todos)
                }
                .store(in: &cancellables)
        }

        // ....
    }
}

This setup already has some great benefits:

Our View is free of any state management logic. This allows us to unit test and even share that logic between other views
By conforming to the ObservableObject protocol and leveraging the @Published property wrapper, we've managed to make that separation easily consumable by our View. It works very similar to reacting off a @State property
We've got a nice repeatable pattern that we can apply to future views that require complex logic

While we can definitely call it a day and move on, you might find yourself wondering what other patterns can we apply here that further adhere to the reactive mantra

I want to highlight that what I'm about to showcase is pretty much a Combine + SwiftUI remix of Jake Wharton's outstanding talk Managing State with RxJava. It's about an hour but I can't emphasize enough how amazing his presentation is and how much it inspired me to apply reactive programming to more than just networking and repository logic. It's in Java but thanks to the language's verbosity it's possible to follow along.

Room for improvement

Looking at the current state of our view model there are a few things that seem unnatural:

func loadTodos() {
    self.viewState = .loading
    todoRepository.getTodos()
        .sink { [weak self] completion in
            switch completion {
            case .failure:
                self?.viewState = .error
            case .finished:
                ()
            }
        } receiveValue: { [weak self] todos in
            self?.viewState = .content(todos: todos)
        }
        .store(in: &cancellables)
}

Setting state outside of the stream seems misplaced and requires one to remember to revert the loading state during success and failure

// ..
func addTodo(title: String) {
    todoRepository.addTodo(title: title)
        .sink { [weak self] completion in
            switch completion {
            case .failure:
                self?.viewState = .error
            case .finished:
                ()
            }
        } receiveValue: { [weak self] todo in
            if case .content(var todos) = self?.viewState {
                todos.append(todo)
                self?.viewState = .content(todos: todos)
            }
        }
        .store(in: &cancellables)
}

func removeTodo(id: String) {
    todoRepository.removeTodo(id: id)
        .sink { [weak self] completion in
            switch completion {
            case .failure:
                self?.viewState = .error
            case .finished:
                ()
            }
        } receiveValue: { [weak self] _ in
            if case .content(var todos) = self?.viewState {
                todos.removeAll(where: { $0.id == id})
                self?.viewState = .content(todos: todos)
            }
        }
        .store(in: &cancellables)
}
// ..

As our view model grows in functionality, you'll notice our code will quickly get heavy with boilerplate subscription code. While we could clean this up and utilize theassign(to:) operator, they'd still be another peculiar characteristic of our state management; the lack of a centralized view state.

Redux/Flux's unidirectional data flow pattern solves a lot of the complexities of having state mutated throughout various areas in the codebase, yet here we are updating our view state throughout various areas of our view model.

How can we adjust our state management approach to alleviate these concerns?

Inputs, Actions and ViewState

Looking at our TodoListView from a behavioral point of view, we can quickly identify some common cause and effect patterns. When a user loads the view, they'd request a list of Todos. When a user adds a Todo, the list will update with the newly added list etc. We could summarize that a user triggered input is causing our app or view model to respond and react to it, resulting in an updated view state.

This sort of pattern is reactive in nature. Inputs can be happening in more than one place at a time and processing those inputs might require async operations. Reactive frameworks like Combine were made for these sort of circumstances and come with some handy operators that can help us gel this pattern into a consumable reactive state.

Let's see what an implementation that incorporates those operators might look like:

extension TodoListView {
    enum ViewState {
        case loading
        case content(todos: [Todo])
        case error
    }

    enum Input {
        case stateRequested
        case todoAdded(title: String)
        case todoRemoved(id: String)
    }

    enum Action {
        case setState(ViewState)
        case addTodo(todo: Todo)
        case removeTodo(id: String)
    }

    class ViewModel: ObservableObject {
        @Published
        var viewState: ViewState = .loading
        private let todoRepository = TodoRepistory()
        private let inputSubject = PassthroughSubject<Input, Never>()
        private var cancellables = Set<AnyCancellable>()

        init() {
            inputSubject
                .flatMap { [todoRepository] input -> AnyPublisher<Action, Never> in
                    switch input {
                    case .stateRequested:
                        return todoRepository.getTodos()
                            .map { todos -> Action in
                                .setState(.content(todos: todos))
                            }
                            .replaceError(with: .setState(.error))
                            .eraseToAnyPublisher()
                    case .todoAdded(let title):
                        return todoRepository.addTodo(title: title)
                            .map { todo -> Action in
                                .addTodo(todo: todo)
                            }
                            .replaceError(with: .setState(.error))
                            .eraseToAnyPublisher()
                    case .todoRemoved(let id):
                        return todoRepository.removeTodo(id: id)
                            .map { _ -> Action in
                                .removeTodo(id: id)
                            }
                            .replaceError(with: .setState(.error))
                            .eraseToAnyPublisher()
                    }
                }
                .scan(viewState) { (currentState, action) -> ViewState in
                    switch action {
                    case .setState(let state):
                        return state
                    case .addTodo(let todo):
                        if case .content(var todos) = currentState {
                            todos.append(todo)
                            return .content(todos: todos)
                        }
                        return currentState
                    case .removeTodo(let id):
                        if case .content(var todos) = currentState {
                            todos.removeAll(where: { $0.id == id })
                            return .content(todos: todos)
                        }
                        return currentState
                    }
                }
                .receive(on: DispatchQueue.main)
                .assign(to: &$viewState)
        }

        func send(_ input: Input) {
            inputSubject.send(input)
        }
    }
}

There are quite a few things going on here, so let's walk through them step by step.

We first create an entity to describe possible inputs that can occur to our view:

    enum Input {
        case stateRequested
        case todoAdded(title: String)
        case todoRemoved(id: String)
    }

These inputs can end up affecting our view state. Let's call these effects actions:

    enum Action {
        case setState(ViewState)
        case addTodo(todo: Todo)
        case removeTodo(id: String)
    }

In order to process these inputs in a reactive stream, we create a PassthroughSubject, which is a subject that broadcasts elements downstream. This works well for our use case as we would like to channel inputs downstream to be processed into possible actions:

private let inputSubject = PassthroughSubject<Input, Never>()

When we init our view model, we subscribe to these emissions and process them via the flatMap operator. Each input is processed differently. This is why representing our inputs as an enum helps us make sure we account for every possible variation and will remind us in the future to account for newly added inputs:

inputSubject
    .flatMap { [todoRepository] input -> AnyPublisher<Action, Never> in
        switch input {
        case .stateRequested:
            return todoRepository.getTodos()
                .map { todos -> Action in
                    .setState(.content(todos: todos))
                }
                .replaceError(with: .setState(.error))
                .eraseToAnyPublisher()
        case .todoAdded(let title):
            return todoRepository.addTodo(title: title)
                .map { todo -> Action in
                    .addTodo(todo: todo)
                }
                .replaceError(with: .setState(.error))
                .eraseToAnyPublisher()
        case .todoRemoved(let id):
            return todoRepository.removeTodo(id: id)
                .map { _ -> Action in
                    .removeTodo(id: id)
                }
                .replaceError(with: .setState(.error))
                .eraseToAnyPublisher()
        }
    }

Take note that we are transforming our stream here into a publisher of <Action, Never>. This means that regardless of the input, the outcome of this step should result in one or many Actions. The Never lets the compiler know that we don't intend this subscription to ever error out. In theory it shouldn't. Any error that might occur in processing should be handled and accounted for(i.e displaying an error state in the view).

This is where the replaceError(with:)operator comes in to save the day. We can easily transform unexpected errors into a relevant action that will get applied to our view state. It's pretty neat and It always forces us to account for unhappy paths when putting together the view model logic.

The final piece to the puzzle is the scan operator. Each action can have an effect on our view state. Via the scan operator, we can process each action as there are emitted by publishers upstream and produce a new view state that we then assign to our @Published view state.

.scan(viewState) { (currentState, action) -> ViewState in
    switch action {
    case .setState(let state):
        return state
    case .addTodo(let todo):
        if case .content(var todos) = currentState {
            todos.append(todo)
            return .content(todos: todos)
        }
        return currentState
    case .removeTodo(let id):
        if case .content(var todos) = currentState {
            todos.removeAll(where: { $0.id == id })
            return .content(todos: todos)
        }
        return currentState
    }
}
.assign(to: &$viewState)

If you are familiar with reducers, the above should look familiar. Instead of reducing multiple actions into one state, we are processing each action and producing a new state.

As for our TodoListView, the only change would be in how our view channels inputs to our view model via the send(_ input: Input) method:

// ...
content(viewModel.viewState)
    .onAppear {
        viewModel.send(.stateRequested)
    }
// ...

And there we have it. A view state management setup thats a bit more reactive, maybe too reactive.

Some benefits to this approach:

Updates to view state are centralized in one area of the view model. This allows to leverage operators like .receive(on:) and removeDuplicates() to insure updates are on the main thread and avoid unnecessary view rebuilding
As we add more inputs and actions, the compiler will complain until you account for them.
The pattern forces you to account for both the happy and not so happy paths.
And more that i'll explain in my next post.

There's quite a bit of stuff going on with this approach. I was super confused when I was first introduced to these concepts. If you find yourself scratching your head, I highly recommend you give the video by Jake a look, as he does a great job in explaining the concept in a lot more detail.

I hope you found this article useful. This is my first attempt at blogging, so any feedback and suggestions would be super useful. Follow me on Twitter for future updates and articles.

In my next post, I'll go over some of the extra benefits of this pattern, namely side effects and how they fit well for related tasks such as event tracking. I'll also share some tips on how to make this approach a lot less boilerplate

stay tuned.