Introduces operator |> (forward application) and >>> (forward composition).

  2 |> incr // == incr(2)
  (incr >>> square)(2) // 9

• Forward composition is the oposite of haskells . composition operator ((b->c)->(a->b)->(a->c))
• Use precedencegroups to avoid writing brackets
• Use operators with care.
• Tooling suffers from Free functions + operators (no autocomplete)
• Methods don't compose as well, because they have to be associated with a value all the time
• Pointfree: never refer to the value you are processing, focus on functions and compositions

Side effects break composability, eg map $ map f can have different side effects than map (f . f), but the same return value.

Take for example writing logs. We can fix the problem of returning logs alongside the computation ((_ x: Int) -> (Int, [String])). But for this kind of function/operator we need a new compose function that appends the logs from both function executions.

  func >=> <A, B, C>(
    _ f: @escaping (A) -> B?,
    _ g: @escaping (B) -> C?
    ) -> ((A) -> C?) {
  
    return { a in
        // same for lists and optionals:
        f(a).flatMap(g)
    }
  }

In haskell, it has type (>=>) :: Monad m => (a -> m b) -> (b -> m c) -> a -> m c, forward composition for monadic functions.

We can avoid having inputs from side effects with currying. <> is then defined as function composition for functions that return the input type. (In haskell this is more generally defined on semigroups, namely: (<>) :: Semigroup a => a -> a -> a.

Composite types can also be called algebraic data types, because we can do algebra with them. E.g. if an enum has cases for type A and B we can construct \(A + B\) values from it, where in this notation, \(A\) and \(B\) denote the number of values that can be constructed in the respective type. For pairs that's \(A * B\). Void has 1 value and Never 0.

How can we fit functions that we work with every day into our composition? We can define functions that manipulate functions such as curry and flip (equivalent to haskell).

How do we deal with methods? Every method secretly defines a static function, which is already curried in the way that i'ts signature is always Self -> Arguments -> ReturnType Zero argument functions can be a problem, because you have these empty parathesis flying around. Solution: Zurry (zero argument curry).

  func zurry<A>(_ f: () -> A) -> A {
    return f()
  }

Generic and throws functions are problematic, but we can redefine functions such as map and filter to free, curried functions.

  func map<A, B>(_ f: @escaping (A) -> B) -> ([A]) -> [B] {
    return { $0.map(f) }
  }

What's the point? "When they work, they work really well, saving us a lot of boilerplate. When they don’t work, we’re still using the concepts and building intuitions for them."

If you modify data structures (by returning a copy), you will end up repeating a lot of code for transforming just one value. Solution: Define generic functions for applying a function on a property. This reduces boilerplate especially when types are modified, because you need a new copy everytime the type changes.

pair
  |> first(incr)
  |> first(String.init)
  |> second(zurry(flip(String.uppercased)))
// ("43", "SWIFT")

To compose functions within setters, we need to take care that it is done in the correct order. E.g.

  let nested = ((1, true), "Swift")
  nested
  |> (second >>> first) { !$0 }
// ((1, false), "Swift")

Setter composition composes backwards. Setters lift a transformation on an individual value into a function operating on the surrounding datatype.

Key paths are generic over type they apply to, and the specific value, eg.

KeyPath<User, String>

you can use a keypath with array syntax!

user[keyPath: \User.name]

Key paths are compiler generated (generate setters/getters under the hood)

Use prop to compose functions over key paths

  func prop<Root, Value>(_ kp: WritableKeyPath<Root, Value>)
    -> (@escaping (Value) -> Value)
    -> (Root)
    -> Root
  
  (prop(\User.name)) { $0.uppercased() } // User -> User
  // composing:
  prop(\User.location) <<< prop(\Location.name)
  // ((String) -> String) -> (User) -> User
  // Even though that's equivalent to \User.location.name

prop allows you to write neat date formatters, URLrequest configurations etc. pointfree in one expression (without computed props/stateful funcs)..

Use get wrapper to bridge between function and keypath world

func get<Root, Value>(_ kp: KeyPath<Root, Value>) -> (Root) -> Value {
  return { root in
    root[keyPath: kp]
  }
}

this is nice:

users
  .filter(get(\.isStaff) >>> (!))

you can do operators as functions 💡.

Generic getters can also be helpful for sorting, max etc. because there you need a compare function A -> A -> Bool. With their, we can write

users
  .max(by: their(get(\.email), <)) // we can also use Comparable instead of passing the compare fn.

We can also write a wrapper for combining elements in reduce:

episodes.reduce(0, combining(get(\.viewCount), by: +))

We use get a lot, so you might consider using an operator ^ as prefix operator.

As we learned in the exercises from "Algebraic Data Types", there are \(B^A\) functions of type \(A->B\). Since \(a^b^c = a^(b*c)\), we can derive that C->B->A = (B, C) -> A. Shows that curry and uncurry are elemental operations. Since \(a^1 = a\), we can derive zurry and unzurry.

What happens with \(a^0=1\)? Never -> A = Void We can define absurd in swift!

func to<A>(_ f: (Never) -> A) -> Void {
  return ()
}

func from<A>(_ x: Void) -> (Never) -> A {
  return { never in
    switch never {
    }
  }
}

This can actually be useful, eg. in case of Result<Int, Never>.

Remember that inout A -> Void can be transformed to A->A? This means that you can refactor (A,B) -> A into (inout A, B) -> Void, (A, inout B) -> C to (A, B) -> (C, B) and such.

We can also see a correspondence between throws and Result<A, Error>.

There is also the power law \(a^(b+c) = a^b * a ^ c\), equivalent to Either<B, C> -> A = (B -> A, C -> A)

💡We can use exponent laws to understand which functions can't and can not be simplified.

flatMap is the mondaic bind. use compactMap to filter nil values.

If operators are not the way to go, you can use named functions. The problem is that you need an overload for any number of arguments. This might change in the future for variadic generics.

We can use `Decodable` and `Encodable` to and from json. Sometimes it can be desirable to wrap your datatypes with a custom type, e.g. use an Email struct instead of just String. This can help avoid errors, because the compiler will complain if you pass other fields to e.g. a sendEmail function.

Problem: If you have a custom struct, you need to adapt the json structure. Or implement your custom Decodable instance. Or use RawRepresentable which saves a lot of code. You will have to tag on an Equatable though:

struct Subscription: Decodable {
  struct Id: Decodable, RawRepresentable, Equatable { let rawValue: Int }

  let id: Id
  let ownerId: Int
}

This is really need, but you're gonna repeat the three protocols all over again. Akin to newtype in haskell we can use Tagged<Tag, Type>:

struct Subscription: Decodable {
  typealias Id = Tagged<Subscription, Int>

  let id: Id
  let ownerId: User.Id
}

Tagged uses Conditional conformance to implement Equatable and Decodable:

extension Tagged: Equatable where RawValue: Equatable {
  static func == (lhs: Tagged, rhs: Tagged) -> Bool {
    return lhs.rawValue == rhs.rawValue
  }
}

If you have to instantiate Tagged fields yourself, it makes sense to use ExpressibleBy...Literal protocols.

Protocol oriented programming for DI is the most common way in swift. They come with a lot of boilerplate. Another solution is to use staticly defined environments that you can swap out at test time:

struct Environment {
  var analytics = Analytics()
  var date: () -> Date = Date.init
  var gitHub = GitHub()
}

var Current = Environment()

The test setup then looks somewhat like this:

  // Define mock dependencies statically
  extension GitHub {
    let static mock = GitHub(fetchRepos: { callback in
      callback(.success([
        GitHub.Repo(
          archived: false,
          description: "Blob's blog",
          htmlUrl: URL("https://www.pointfree.co",
          name: "Bloblog",
          pushedAt: Date(timeIntervalSinceReferenceData: 547152021)
        )
      ])
    })
  }
  
  extension Environment {
      static let mock = Environment(
        analytics: .mock,
        date: { Date(timeIntervalSinceReferenceDate: 557152051) },
        gitHub: .mock
      )
  }
Current = .mock
// Do tests

Unfortunately no example of some clean test suite is provided. Downsides: it will keep you from parallelizing tests, and won't force you to overwrite dependencies with mocks during tests.

Nothing much new other than how to easily build mock structures with overture

  extension Array where Element == GitHub.Repo {
    static let mock = [
      GitHub.Repo.mock,
      with(.mock, concat(
        set(\.name, "Nomadic Blob"),
        set(\.description, "Where in the world is Blob?"),
        set(\GitHub.Repo.pushedAt, .mock - 60*60*24*2)
      ))
    ]
    static func mocks(_ count: Int) -> Array {
    return (1...count).map { n in
      with(.mock, concat(
        over(\.name) { "#\(n): \($0)" },
        set(\GitHub.Repo.pushedAt, .mock - 60*60*24*TimeInterval(n))
      ))
    }
  }
  }

When developing in UIKit, you can build something similar to previews with playgrounds. This requires you to modularize your app, or put the whole app in one framework/package.

import PointFreeFramework
import PlaygroundSupport

let vc = EpisodeListViewController()
PlaygroundPage.current.liveView = vc

• Cohesive package to solve some problems that Swift UI has
• Opinionated
• Focus on modularization and composability
• Very restrictive regarding side effects.
• Assertion helper to test the composable architecture, that forces you to deal with all effects
• Debugging capabilities (.debug to print all actions)
• Range of example projects

Why view store?

• Hide state of sub-views so that the current view is only re-rendered when it's own state changes
• More flexibility binding different front-ends to the state (platform-specific)

Equatable for duplicate filtering Bindings For a list of states, there is a lot of index juggling in bare-metal CA

We can get rid of index juggling with ForEachStore On the reducer side we need to call forEach that supplies

• Writable key path to a random access collection of subview-states
• Case path of an action that embeds an index and action into a subview-action (could write this yourself with embed and extract, but CasePaths supplies the backslash for this)
• Function to create the environment. Or key path

Strong type level guarantees

ForEachStore can be used with stores that only knows about the collection, and the indexed actions. This is done with scope, that extracts the list out of the state, and embeds an index action into the global actions. (Extract global state into local, and embed local state into global)

Then extracting the subviews into their seperate views, the code becomes very short:

    ForEachStore(
                  self.store.scope(
                      state: \.tiles,
                      action: MyActions.tileAction),
                  content: TileView.init)

combine multiple stores, if the global store also needs to handle some logic, that is unrelated to the list of subviews.

Exhaustive tests with TestStore. Basic workflow:

1. Create a TestStore

          let store = TestStore(
            initialState: AppState(
              todos: [
                Todo(
                  description: "Milk",
                  id: UUID(uuidString: "00000000-0000-0000-0000-000000000000")!,
                  isComplete: false
                )
              ]
            ),
            reducer: appReducer,
            environment: AppEnvironment()
          )
   

2. Create exhaustive assertions (effects that are not tested will throw an error)

          store.assert(
          .send(.todo(index: 0, action: .checkboxTapped)) {
            $0.todos = [
              Todo(
                description: "Eggs",
                id: UUID(uuidString: "00000000-0000-0000-0000-000000000001")!,
                isComplete: false
              ),
              Todo(
                description: "Milk",
                id: UUID(uuidString: "00000000-0000-0000-0000-000000000000")!,
                isComplete: true
              )
            ]
          }
          )
   

Some more wisdom:

• Inject dependencies via environment
• Be explicit in the assertions
• use an inline struct to define your cancellable id's:

        case .todo(index: _, action: .checkboxTapped):
        struct CancelDelayId: Hashable {}
        
        return Effect(value: .todoDelayCompleted)
          .delay(for: 1, scheduler: environment.mainQueue)
          .eraseToEffect()
          .cancellable(id: CancelDelayId(), cancelInFlight: true)
  

How to test async effects? Test helper will complain if some effects are still running.

• don't use XCTWaiter and the like
• Inject DispatchQueue using AnySchedulerOf<DispatchQueue> and use TestScheduler in the tests. You can then just advance your scheduler and don't have to wait.

This episode introduces the already common approach of abstracting away dependencies via a protocol. It then builds the case for scrapping the protocol. (No exercises)

Dependencies can now easily split into modules, and we can even seperate implementation and interface if needed. (No exercises)

Discusses how to modularise and style a wrapper library around a system API (NWPathMonitor). (No exercises)

Interesting showcase with a more complicated dependency including delegates and NSObject inheritance. Keeping a reference to the delegate after the initializer function exits is done via receiveEvents

var delegate: Delegate? = Delegate(subject: subject)
locationManager.delegate = delegate
return Self(
  delegate: delegate
    .handleEvents(receiveCancel: { delegate = nil }
    .eraseToAnyPublisher()
  ...
)

This episode demonstrates how freely you can now play with your dependencies. With this approach you can

• write tests with strong guarantees, e.g. that certain

API's are not called.

• Create transformations/setters on dependencies
• Create decorations on dependencies, such as "every effect is delayed by 1 second"
• Create a mix of dependencies, such as a live core location client that only has the final location result hardcoded
• Write a debug screen that arbitrarily taps into your environment

The problem is that it's hard to seperate concerns in vanilla swiftui. When you redact a view you don't want any interaction to happen, hence you basically want to swap out your business logic with no-ops. In a traditional swiftui setup, you'd have to sprinkle your code all over with early exits to achieve that.

The idea is simple: In CA, Just swap in a Store that has some placeholder data, no reducer and no environment while loading. You can use the .empty extension of Reducer for a reducer that doesn't care about any actions. And a void env because that's not gonna be used anyway.

• If you have a subview that you unredact within your bigger view,

you can selectively add back some logic into your empty reducer

• You cann call out to another reducer like this

appReducer.run(&state, &action, &environment)

This shows the reference solutions of part 1: You can do it more elegant with case let where, and run the original app reducer:

case let .placeholderAction(action) where state.step == .todos:
    switch action {
    case .todo(id: _, action: .checkBoxToggled),
         .sortCompletedTodos:
        return appReducer
          .run(&state.placeholderState, action, environment)
          .map(OnboardingAction.placeholderAction)

• SwiftUI Form arrangement is a great way to build simple forms
• Split sections with Section
• State handling and side effects quickly become messy with vanilla SwiftUI (guess who saves the day, the composable architecture of course)

This episode mainly showcases basic TCA stuff, and how it makes state mutations in forms more readable and testable, albeit being a bit more verbose.

Forms can be incredibly simpler than the "naive" TCA approach.

1. Wrap form actions (getters and setters of key paths) in a generic struct

struct FormAction<Root>: Equatable {
  let keyPath: PartialKeyPath<Root>
  let value: AnyEquatable
  let setter: (inout Root) -> Void

  init<Value>(
    _ keyPath: WritableKeyPath<Root, Value>,
    _ value: Value
  ) where Value: Equatable {
    self.keyPath = keyPath
    self.value = AnyEquatable(value)
    self.setter = { $0[keyPath: keyPath] = value }
  }

  // Note this is just an alias for init, for better readability
  static func set<Value>(
    _ keyPath: WritableKeyPath<Root, Value>,
    _ value: Value
  ) -> Self where Value: Equatable {
    self.init(keyPath, value)
  }

  static func == (lhs: FormAction<Root>, rhs: FormAction<Root>) -> Bool {
    lhs.keyPath == rhs.keyPath && lhs.value == rhs.value
  }
}

1. Use a single action for all state changes by form interactions:

case form(FormAction<SettingsState>)

1. use viewStore.binding with key store to hook the action into the form (⚠ This method seems deprecated, more info in Safer, Conciser Forms: Part 1&2)

extension ViewStore {
  func binding<Value>(
    keyPath: WritableKeyPath<State, Value>,
    send action: @escaping (FormAction<State>) -> Action
  ) -> Binding<Value> where Value: Hashable {
    self.binding(
      get: { $0[keyPath: keyPath] },
      send: { action(.init(keyPath, $0)) }
    )
  }
}

// And then:
Picker(
              "Top posts digest",
              selection: viewStore.binding(
                keyPath: \.digest,
                send: ConciseSettingsAction.form
              )
...

1. Reduce even more boiler plate by allowing switches on the form action on first level:

func ~= <Root, Value> (
  keyPath: WritableKeyPath<Root, Value>,
  formAction: FormAction<Root>
) -> Bool {
  formAction.keyPath == keyPath
}

neat!

This presents concise forms in action within isowords. ⚠ In the current version of TCA, the action and higher level reducer have been renamed more generally to BindingAction<T> and .binding().

Implicit animations (.animation(_,value:)) vs explicit animations (withAnimation {}). Implicit animations can give great results with very little work but are unsuitable for fine-grained control, because they animate everything in the view hirarchy. And the semantics of overriding animations is not clear. E.g. if/else branches rather than ternary operator can mess up your animation semantics.

withAnimation is a special case of a continuation: (A -> R) -> R (where A is Void in this case). Animate bindings with binding.animation() instead of withAnimation.

• Make those functions/dependencies fail that are not used in the test,

e.g. by providing an unimplemented helper. For example

extension UUID {
  static let unimplemented: () -> UUID = { fatalError() }
}

This will assert which dependencies are not used, strengthening your tests. Also if you add more usage of the dependencies later, the tests will tell you exactly where to update.

• Record function arguments by passing closures like so:

extension AnalyticsClient {
  static func test(onEvent: @escaping (Event) -> Void) -> Self {
    Self(
      track: { event in
        .fireAndForget {
          onEvent(event)
        }
      }
    )
  }
}

• use XCTDynamicTestOverlay
• create a failing dependency "constructor'

static let failing = Self(
        execute: { language in
            XCTFail("MyService.execute(\(language)) not implemented")
            return SomeDummyData()
        }
    )

it will not crash the testsuite. CA can also better point out where the error is. There is a neat failing `Effect` in CA: Effect.failing(prefix: String)

Describes the hyper-modularization, domain modelling and testing strategy for isowords.

Demonstrates how the composable architecture can be used to abstract away seperate features like app clips and app store videos on top of the existing game logic, without littering it with additional code.

You can use .refreshable { <async closure> } to implement a simple pull to refresh. We could use for example the new async URLSession to perform the data refresh, since refreshable gives us an async context.

let (data, _) = try await URLSession.shared.data(...)

If we want to be able to cancle such asnychronous work, it needs to be wrapped in a task:

let task = Task {
  //...perform work
}
task.cancel()

If this task is part of your ObservableObject view model and you want to display state based on weather the task is running or not, you had to mark it as @Published, so that SwiftUI can recompute the view when the State of Task execution changes.

When performing async things that then modify some state on completion, it can make sense to use @MainAction method annotation, to make sure work is resumed on the main thread, after finishing the async workload.

The episode then goes to explain that e.g. displaying loading state and cancelling requests when doing async tasks is hard to test. For example, it seems you have to work with TaskSleep and artificial delays to hook into the state of the view model where the request is currently executing.

When the refreshable closure is called, the loading spinner is shown as long as an async task is running in the asynchronous context of it. This is a problem with the composable architecture: While you of course can make changes to the store from an async context, the call to make these changes returns immediately.

Solution: Use a boolean to reflect weather an async process is running

func send(
  _ action: Action,
  `while` isInFlight: @escaping (State) -> Bool
) async {
    self.send(action)
    await withUnsafeContinuation { continuation in
        var cancellable: Cancellable?
        cancellable = self.publisher
          .filter { !isInFlight($0) }
          .prefix(1)
          .sink { _ in
              continuation.resume(returning: ())
              _ = cancellable
          }
    }
}

• use @BindableState in your TCA state property to opt-in to make it bindable
• This makes the domain logic safer because the view cannot arbitrarily mutate the state
• use case binding(BindingAction<SpellingChallengeState>) to handle binding actions

some swift learnings:

• Implement projectedValue to expose the wrapping type when writing your own property wrapper.

Then access the wrapping type with a $ prefix. By default, the wrapping type is just exposed privately and accessed by a _ prefix.

• Implement getter and setters within projectedValue to derive writable key paths.

We can omit stating the binding action case when we derive bindings from bindable state, or when we chain the higher level .binding(Action) reducer. Swift enums can conform to protocols with cases, like so:

protocol BindableAction {
  associatedtype State
  static func binding(_: BindingAction<State>) -> Self
}

You could even simplify creating bindings by implementing a dynamic member lookup for the view store. This has been deprecated in TCA though, because it causes some problems in the reducer. If we did't care about the type safety (Only Bindable states can be bound to) we theoretically could use this new syntax that allows bindings to be passed to closures:

struct MyView: View {
  @State var array = [1, 2, 3]
  var body: some View {
    ForEach(self.$array, id: \.self) { $number in
      let _ = $number as Binding<Int>
      let _ = number as Int
    }
  }
}