Defining Properties on the Feature/Reducer

[jagreenwood]

With the introduction of a top level type which conforms to ReducerProtocol, I'm curious about thoughts related to defining properties on this type itself.

Take for instance this simplified feature:

struct Detail: ReducerProtocol {
  let detailID: Int // <-- property on feature

  struct State: Equatable {
    var detailName: String?
  }

  enum Action: Equatable {
    case getName
    case setName(String)
  }

  @Dependency(\.detailClient) var detailClient

  func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch {
      case .getName:
        return detailClient.getName(for: detailID)
               ...
               .map(Action.setName)
    }
  }
}

detailID doesn't need to be tested or exposed to the view via the ViewStore. Taken too far I can see this as an anti-pattern, but with smaller intentional uses, is it a valid pattern?

[JacksonUtsch]

I have found this pattern important/needed in order to utilize dependencies that are needing to use protocols.

This is my example client:

public protocol JwtClient {
  func decode<T: Codable>(_ token: String) async throws -> Result<T, JwtFailure>
}

This client needs to be defined as a protocol otherwise it would need to implement every concrete type individually which would loose a TON of usability. This is because Swift properties cannot be generic but functions can be.

The feature would require the initializer with this injection:

struct SomeFeature: ReducerProtocol {
  let jwtClient: JwtClient

  init(jwtClient: JwtClient) {
    self.jwtClient = jwtClient
  }
}

I think this should only be used for dependencies that cannot be included using @Dependency. Meaning state should not exist here.

[jagreenwood]

This is good perspective. Thank you!