{"id":387878,"date":"2024-06-29T07:35:33","date_gmt":"2024-06-29T07:35:33","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=387878"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=387878","title":{"rendered":"How to cook reactive programming. Part 2: Side effects<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
\n

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.<\/p>\n

<\/a> <\/p>\n

Before we start, I\u2019d firstly highly recommend reading at least How to cook reactive programming. Part 1: Unidirectional architectures introduction.<\/a>. However, if you\u2019re not familiar with frameworks such as RxSwift<\/code> or Combine<\/code>, or reactive programming in general, I\u2019d suggest reading this article<\/a> as well.<\/p><\/blockquote>\n

<\/p>\n

    \n
  1. What is Reactive Programming? iOS Edition<\/a><\/li>\n
  2. How to cook reactive programming. Part 1: Unidirectional architectures introduction.<\/a><\/li>\n<\/ol>\n

    <\/p>\n

    Intro<\/h2>\n

    <\/p>\n

    Before we will move to the talk about Side Effects<\/code> I want to introduce you to the main subject of this article.<\/p>\n

    <\/p>\n

    <\/div>\n

    <\/p>\n

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

    <\/p>\n

    enum State {     case initial     case loading     case loaded(data: [String]) }<\/code><\/pre>\n
      <\/p>\n
    Much better! If you\u2019re 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<\/code> state can go to the Loading<\/code> state. The Loading<\/code> state to the Loaded<\/code> state. And the Loaded<\/code> state can go back to the Loading<\/code> state. Remember I was talking about State<\/code> 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.<\/p>\n
      <\/p>\n
    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<\/code> 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<\/code> for the experiments. And now let’s move to the main topic.<\/p>\n
      <\/p>\n
    What are Side Effects?<\/h2>\n
      <\/p>\n
    According to Wikipedia<\/strong><\/p>\n
      <\/p>\n
    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.<\/p><\/blockquote>\n
    However, here we\u2019re not talking about the strict definition of the side effects. Let’s remember where we ended up the last time.<\/p>\n
      <\/p>\n
    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)     } }<\/code><\/pre>\n
      <\/p>\n
    Generally, nearly all unidirectional architectures look like this. We have a State<\/code> on which the rest application relies as only one source of truth. A reducer<\/code> which alongside Event<\/code> is the only way to mutate or update State<\/code>. However, there should be something else. We don’t live in a synchronous world, where every update for State<\/code> can be done only with a synchronous reduce<\/code> 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<\/code> are something asynchronous, which could mutate State<\/code> and this «something» works on the side of the reducer<\/code>. 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 \u2018unidirectional\u2019.<\/p>\n
      <\/p>\n
    One remark: Event<\/code> in different implementations of unidirectional architectures could be called a Mutation<\/code> or Action<\/code> or Message<\/code>, or maybe something different, for our purposes however naming is not so important. <\/p>\n
      <\/p>\n
    Why is the architecture called unidirectional?<\/h2>\n
      <\/p>\n
    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.<\/p>\n
      <\/p>\n
    I think it should be quite easy to understand with theState<\/code> reduce<\/code> approach from the beginning. We can change or mutate State<\/code> only with a strict described Event<\/code>. As a result we’ve got a one-way (unidirectional) data flow. However, what should we do with Side Effects<\/code>? <\/p>\n
      <\/p>\n
    Imagine that for the State<\/code> we have a service which as a result returns a list of the news titles.<\/p>\n
      <\/p>\n
    func loadNewsTitles(completionHandler: ([String]) -> ()) {     completionHandler([\"title1\", \"title2\"]) }<\/code><\/pre>\n
      <\/p>\n
    We know that reducer<\/code> takes Event<\/code> as an input not a closure\u2026 How can we connect this service to the reducer<\/code>? The answer is quite simple. Let\u2019s have a Side Effect<\/code>, which will return Event<\/code>, not just requested data.<\/p>\n
      <\/p>\n
    The resulting system will look like this:<\/p>\n
      <\/p>\n
    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     } }<\/code><\/pre>\n
      <\/p>\n
    As you can see for now loadNewsTitles<\/code> returns an Event<\/code>, 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<\/code>. After I\u2019d answered one question, I’ve subsequently produced another one. How can we connect Side Effects<\/code> 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.<\/p>\n
      <\/p>\n
    Which types of side effects exist?<\/h2>\n
      <\/p>\n
    In nearly every unidirectional architecture<\/code> you’ll see a collaboration of State<\/code> and some function for reducing<\/code> this State<\/code> according to the input Event<\/code>. With Side Effects<\/code> 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.<\/p>\n
      <\/p>\n
    Middleware<\/h3>\n
      <\/p>\n
    Let’s start with the Middleware<\/code> approach. Middleware<\/code> provides a third-party extension point between dispatching an Event<\/code>, and the moment it reaches the reducer. In simple terms Middleware<\/code>, sits in the middle between you performing or dispatching an Event<\/code> and mutating your State<\/code> inside the reducer<\/code>.<\/p>\n
      <\/p>\n
    <\/div>\n
      <\/p>\n
    Let me provide you with a code example, which I found in one well-known framework for Redux<\/code> implementation for Swift.<\/p>\n
      <\/p>\n
    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)         }     } }<\/code><\/pre>\n
      <\/p>\n
    As you can see a Middleware<\/code> could be treated as an asynchronous preReducer<\/code>. It catches all Events<\/code>, carries out some manipulations over it \u2014 in our case, loading news titles -, and performs a new Event<\/code> for the system if it’s necessary. So, if the Event<\/code> is loadData<\/code>, listed Middleware<\/code> will load news titles and in the closure send another Event<\/code> to the Store<\/code>. The next dataLoaded<\/code> Event<\/code> will just be ignored by this Middleware<\/code>. One of the pros of this method is the possibility to chain Middlewares<\/code> quite easily.<\/p>\n
      <\/p>\n
    Also, if you want to read more about this approach, I\u2019d highly recommend taking a look at ReSwift<\/code> framework<\/a>. This framework is an implementation of a unidirectional architecture, which is called Redux<\/code> for Swift language. For those, who still refuse reactive frameworks, ReSwift<\/code> could be a good start, because ReSwift<\/code> doesn’t use any.<\/p>\n
      <\/p>\n
    Effects<\/h3>\n
      <\/p>\n
    The next approach I want to talk about is the Effects<\/code> approach. The main idea is almost the same as the Middleware<\/code>, but all actions are going on inside Reducer<\/code> itself.<\/p>\n
      <\/p>\n
    <\/div>\n
      <\/p>\n
    In this approach Reducer<\/code> has a little bit of a different shape, that I showed you before. It has a shape, which you can see below.<\/p>\n
      <\/p>\n
    func reducer(state: inout State, event: Event, environment: Environment) -> Effect<\/code><\/pre>\n
      <\/p>\n
    Nearly everything should be familiar. State<\/code> is a type that holds the current state of the application. Event<\/code> is a type that holds all possible events that cause the state of the application to change. However, there are two new characters: Environment<\/code> and Effect<\/code>. Environment<\/code> is a type that holds all dependencies needed in order to produce Effect(s)<\/code>, such as API clients, analytics clients, random number generators, and so on.<\/p>\n
      <\/p>\n
    So, how does it work for our example?<\/p>\n
      <\/p>\n
    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)     } }<\/code><\/pre>\n
      <\/p>\n
    How does this approach work? For every call of Reducer<\/code> you provide all necessary dependencies via Environment<\/code> to the Reducer<\/code> itself, and afterward your Store<\/code> will perform every workItem<\/code> from the Effect<\/code> itself. And then every Effect<\/code> will return another Event<\/code> to the Reducer<\/code>. Unidirectional data flow works with all power here.<\/p>\n
      <\/p>\n
    You may ask, but what about the pure Reducer<\/code> over there? You told us that Reducer<\/code> is a pure function, and now you put Side Effects<\/code> directly inside this function. Moreover, we mutate State<\/code> inside this function, not just creating a new value. So, I can definitely explain that this variation of the Reducer<\/code> is the most complicated one which we’ve seen so far. It has the Environment<\/code> inside and it mutates State<\/code>. However, let\u2019s take a closer look. If we provide one implementation for the loadNewTitles<\/code> service, our Reducer<\/code> will perform the same and our State<\/code> 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 \u2014 Effect<\/code> as a return value, with the same network client in it. I hope you\u2019ve got the idea. What about State<\/code> mutation? Since all real mutations are always going on inside the Store<\/code>, the main situation around changing State<\/code> hasn’t changed itself. Moreover, mutating State<\/code> against creating new values for every reduce<\/code> saves some performance for us. We don’t need to allocate new memory each time.<\/p>\n
      <\/p>\n
    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<\/code><\/a> 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<\/a>. I’m sorry I couldn’t miss this chance…<\/p>\n
      <\/p>\n
    Query Feedback<\/h3>\n
      <\/p>\n
    Let’s move forward or downstairs. In contrast with Middleware<\/code> or Effect<\/code> approaches from the previous sections, there’s a Query<\/code> approach. The Query Feedback<\/code> approach reacts<\/code> to new changes from the different side of the Reducer<\/code> compared to Middleware<\/code>.<\/p>\n
      <\/p>\n
    <\/div>\n
      <\/p>\n
    Did you notice? We\u2019ve moved the whole way through Side Effects<\/code> approaches? Middleware<\/code> was before Reducer<\/code>, Effects<\/code> approach was inside Reducer<\/code> and now Query Feedback<\/code> is after reducer. Quite a journey, huh?<\/p>\n
      <\/p>\n
    However, how does it work? We need to take a small piece of the State<\/code> and start to Observe<\/code> every change of this state. For the previous example it will look like:<\/p>\n
      <\/p>\n
    extension State {     var loadQuery: Void? {         guard case .loading = self else { return nil }         return ()     } }<\/code><\/pre>\n
      <\/p>\n
    In other words, there’s some kind of Observer<\/code>, which follows every change of this query and performs some actions over it. The optional Void<\/code> type for my taste is the best representation when you need to understand whether you need to do any work or not.<\/p>\n
      <\/p>\n
    I think you\u2019ve 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<\/code> 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<\/code> over vanilla Swift. Technically Combine<\/code> is already vanilla as well, but you\u2019ve got the point.<\/p>\n
      <\/p>\n
    Here is a small table of concepts for those who are new in Combine<\/code>.<\/p>\n
      <\/p>\n