Why are structs with closure vars are used instead of protocols?

[surajbarkale]

I have just started learning TCA and I am going through the examples. I am struggling to understand why structs are used instead of protocols. Apologies if this is already explained. For example in AudioRecorderClient.swift, following declaration can be replaced:

struct AudioRecorderClient { .. }

struct AudioRecorderClient {
  var currentTime: (AnyHashable) -> Effect<TimeInterval?, Never>
  var requestRecordPermission: () -> Effect<Bool, Never>
  var startRecording: (AnyHashable, URL) -> Effect<Action, Failure>
  var stopRecording: (AnyHashable) -> Effect<Never, Never>

  enum Action: Equatable {
    case didFinishRecording(successfully: Bool)
  }

  enum Failure: Equatable, Error {
    case couldntCreateAudioRecorder
    case couldntActivateAudioSession
    case couldntSetAudioSessionCategory
    case encodeErrorDidOccur
  }
}

by a protocol and associated implementations.

protocol AudioRecorderClient { .. }

protocol AudioRecorderClient {
  func currentTime(id: AnyHashable) -> Effect<TimeInterval?, Never>
  func requestRecordPermission() -> Effect<Bool, Never>
  func startRecording(id: AnyHashable, into filePath: URL) -> Effect<Action, Failure>
  func stopRecording(id: AnyHashable) -> Effect<Never, Never>

  enum Action: Equatable {
    case didFinishRecording(successfully: Bool)
  }

  enum Failure: Equatable, Error {
    case couldntCreateAudioRecorder
    case couldntActivateAudioSession
    case couldntSetAudioSessionCategory
    case encodeErrorDidOccur
  }
}

Why is protocol based approach not used for external effects? I find it more readable than the struct+vars approach.

Thanks,
Suraj

[mstfy]

Hi Suraj
Here is the video series that explains why structs preferred over protocols:
https://www.pointfree.co/episodes/ep110-designing-dependencies-the-problem

[mbrandonw]

In addition to what @mstfy posted, there's a full collection of material on the subject here and here.

There are many reasons to use a struct over a protocol (if possible), but I can distill one example for you. The main reason one puts an interface in front of a dependency (whether it be via structs or protocols) is so that you can create multiple instances of the dependency that serve different purposes. The most common are:

• You can have a "live" instance that runs the real code under the hood (e.g. audio player, location manager, database, etc.), which is what you would use in the production app.
• You can have a "mock" instance that returns some mock data immediately rather than reaching out into the real world, which is what you use in tests and SwiftUI previews.

Whether you use structs or protocols for the interface of the dependency, creating the "live" and "mock" instances looks about the same:

struct Dependency {
  var fetch: (Int) -> Effect<User, Error>
  var save: (User) -> Effect<Bool, Error>

  static let live = Self(
    fetch: { id in /* load user from disk/database/network */ },
    save: { user in /* save user to disk/database/network */ }
  )

  static let mock = Self(
    fetch: { _ in .init(value: User(name: "Blob") },
    save: { _ in .init(value: true) }
  )
}

// vs

protocol Dependency {
  func fetch(id: Int) -> Effect<User, Error>
  func save(user: User) -> Effect<Bool, Error>
}

struct LiveDependency: Dependency {
  func fetch(id: Int) -> Effect<User, Error> {
    // load user from disk/database/network
  }
  func save(user: User) -> Effect<Bool, Error> {
    // save user to disk/database/network
  }
}

struct MockDependency: Dependency {
  func fetch(id: Int) -> Effect<User, Error> {
    .init(value: User(name: "Blob"))
  }
  func save(user: User) -> Effect<Bool, Error> {
    .init(value: true)
  }
}

However, for the mock instance you probably do not want to hard code the data directly into the instance. You may want an instance that successfully returns data for all endpoints to test the happy path, and then an instance that fails for all endpoints to test the unhappy path. Now you could certainly create HappyDependency and UnhappyDependency conformances, but maybe you also want instances that succeed on some endpoints and fail on others. Or maybe even the manner in which they succeed/fail dynamically depends on the data fed to the endpoint.

For the struct style of the dependency you can simply override any endpoint to supply the data you want:

var dependency = Dependency.mock
// Make fetch fail
dependency.fetch = { _ in .init(error: CouldNotLoad()) }
// Make save return false instead of true
dependency.save = { _ in .init(value: false) }

But doing this for the protocol style is not possible. Because the protocol requirements are implemented with methods you cannot override them. You could enhance MockDependency to hold onto the data that is returned from each endpoint:

struct MockDependency: Dependency {
  var fetchResult: Result<User, Error>
  var saveResult: Result<Bool, Error>

  func fetch(id: Int) -> Effect<User, Error> {
    .result { self.fetchResult }
  }
  func save(user: User) -> Effect<Bool, Error> {
    .result { self.saveResult }
  }
}

var dependency = MockDependency()
dependency.fetchResult = .failure(CouldNotLoad())
dependency.saveResult = .success(false)

But this also means can't provide custom logic for each endpoint. It just pinned to that one value. For example, say you wanted to simulate an instance of the dependency that successfully fetches a user for id <= 100 and then failed otherwise. There's no way to do that MockDependency, even though it would be quite easy with struct version:

var dependency = Dependency.mock
dependency.fetchUser = { id in
  id <= 100
    ? .init(value: User(name: "Blob \(id)"))
    : .init(error: CouldNotLoad())
}

So, to recover this with MockDependency we have to further enhance it so that it holds onto closures for each endpoint:

struct MockDependency: Dependency {
  var fetch: (Int) -> Effect<User, Error>
  var save: (User) -> Effect<Bool, Error>

  func fetch(id: Int) -> Effect<User, Error> {
    self.fetch(id)
  }
  func save(user: User) -> Effect<Bool, Error> {
    self.save(user)
  }
}

var dependency = MockDependency()
dependency.fetchUser = { id in
  id <= 100
    ? .init(value: User(name: "Blob \(id)"))
    : .init(error: CouldNotLoad())
}

At this point MockDependency looks no different than Dependency, except it has a bunch of methods on it that call down to the closures. So, if you want a completely flexible mock dependency you are naturally led to create a struct version of the interface with var closure fields for all the endpoints.

That's why we decide to just start there. Start with a struct that has var fields, and then it is trivial to take any existing instance of the interface and slightly tweak it to customize it. No need to manage a protocol along side this struct if the struct can handle everything.

Now, having said all that, if you prefer to use protocols then that is totally fine. Protocols work great, they will continue to get better in the future, and I don't know of any reason why they won't work for a TCA application.

[georgescumihai]

I know this is an old discussion and @mbrandonw explained quite well the advantages of the struct based interface.
I want to present the exact solution but with Protocols instead of structs.

One way how you can take advantage of the interface using Protocols is to use a Mock generator, like Sourcery, this will take care of creating all the boilerplate code of the mock to handle all the use cases.

// sourcery: AutoMockable
protocol Dependency {
  func fetch(id: Int) -> Effect<User, Error>
  func save(user: User) -> Effect<Bool, Error>
}

The generate mock will look like this.

// swiftlint:disable all
public class DependencyMock: Dependency {

    public init() {}

    //MARK: - fetch

    public var fetchIdCallsCount: Int = 0
    public var fetchIdCalled: Bool {
       fetchIdCallsCount > 0
    }
    public var fetchIdReceivedId: Int?
    public var fetchIdReceivedInvocations: [Int] = []
    public var fetchIdReturnValue: Effect<User, Error>!
    public var fetchIdClosure: ((Int) -> Effect<User, Error>)?

    public func fetch(id: Int) -> Effect<User, Error> {
        fetchIdCallsCount += 1
        fetchIdReceivedId = id
        fetchIdReceivedInvocations.append(id)
        return fetchIdClosure.map({ $0(id) }) ?? fetchIdReturnValue
    }

    //MARK: - save

    public var saveUserCallsCount: Int = 0
    public var saveUserCalled: Bool {
       saveUserCallsCount > 0
    }
    public var saveUserReceivedUser: User?
    public var saveUserReceivedInvocations: [User] = []
    public var saveUserReturnValue: Effect<Bool, Error>!
    public var saveUserClosure: ((User) -> Effect<Bool, Error>)?

    public func save(user: User) -> Effect<Bool, Error> {
        saveUserCallsCount += 1
        saveUserReceivedUser = user
        saveUserReceivedInvocations.append(user)
        return saveUserClosure.map({ $0(user) }) ?? saveUserReturnValue
    }

}

To provide custom logic you can use the creation closure.

var dependency = DependencyMock()
dependency.fetchIdClosure = { id in
  id <= 100
    ? .init(value: User(name: "Blob \(id)"))
    : .init(error: CouldNotLoad())
}

To conclude you can use both in the same way.

One thing that the struct vs protocol solution has, which you can either call it an advantage or not, is using the live, noop / mock instances .
Creating the static instances makes your dependencies more or less like singletons or single instances and this hides one of the issues /ways of TCA, the scoped environment is recreated with each event for chained Stores.

[surajbarkale]

I personally like the protocol based approach. But I went the struct route as mocking is broken in Swift. I looked at using Sourcery and MockingKit. However, it is just simpler to replace vars in a struct 🤷🏽‍♂️.
I agree about the recreation of environment. I am ensuring that environment only contains references so this does not cause any surprises.