Modular Dependency Injection: The Point

Exercises

1. It is very common for APIs that work with Equatable types to be defined alongside similar APIs that work with any type given a predicate function (A, A) -> Bool. For instance, in Combine there is a removeDuplicates() method on publishers of equatable values, while there is a similar, removeDuplicates(by:) method on publishers of any value.

   In our architecture, the assert helper is currently constrained over equatable values and actions:

   public func assert<Value: Equatable, Action: Equatable, Environment>(
     initialValue: Value,
     reducer: Reducer<Value, Action, Environment>,
     environment: Environment,
     steps: Step<Value, Action>...,
     file: StaticString = #file,
     line: UInt = #line
   )
   

   Using removeDuplicates(by:) as a template, define a version of assert that works on non-equatable values and actions:

   Solution

   You can update the function signature to take valueIsEqual and actionIsEqual functions:

   public func assert<Value, Action, Environment>(
     valueIsEqual: (Value, Value) -> Bool,
     actionIsEqual: (Action, Action) -> Bool,
     initialValue: Value,
     reducer: Reducer<Value, Action, Environment>,
     environment: Environment,
     steps: Step<Value, Action>...,
     file: StaticString = #file,
     line: UInt = #line
   )
   

   And then, rather than call to XCTAssertEqual, we can call XCTAssert with the result of actionIsEqual and valueIsEqual:

   XCTAssert(actionIsEqual(action, step.action), file: step.file, line: step.line)
   …
   XCTAssert(valueIsEqual(state, expected), file: step.file, line: step.line)
   

2. In this episode we see a problem with the offlineNthPrime dependency where inefficient computations entirely hang the interface. Update this dependency to run on a non-UI thread to fix this bug.

   Solution

   By using subscribe(on:) and receive(on:), you can ensure that the work is done on a global background queue and received on the main UI queue:

   public func offlineNthPrime(_ n: Int) -> Effect<Int?> {
     Deferred {
       Future { callback in
         …
         callback(.success(nthPrime))
       }
     }
     .subscribe(on: DispatchQueue.global())
     .receive(on: DispatchQueue.main)
     .eraseToEffect()
   }
   

3. Update the higher-order activityFeed reducer to provide the current date from the reducer’s environment.

   Solution

   You can describe the dependency of plucking a date out of the reducer’s environment like so:

   func activityFeed(
     _ reducer: @escaping Reducer<AppState, AppAction, AppEnvironment>,
     date: @escaping (AppEnvironment) -> Date
   ) -> Reducer<AppState, AppAction, AppEnvironment>
   

   Which gets the date controlled and even lets you simply swap out Date() for date(environment).

   state.activityFeed.append(.init(timestamp: date(environment), type: .removedFavoritePrime(state.count)))
   …
   state.activityFeed.append(.init(timestamp: date(environment), type: .addedFavoritePrime(state.count)))
   …
   state.activityFeed.append(.init(timestamp: date(environment), type: .removedFavoritePrime(state.favoritePrimes[index])))
   

   While it may seem scary to invoke this side effect without the cycle of running an Effect and feeding an action back into the system, it is perfectly safe and reasonable to do!

   Explore the alternative: what it would it look like to introduce the effect–action cycle in this higher-order reducer? What are the trade-offs of both approaches?