How can I have an ID-ed child feature responsible for its own state?

[mrackwitz]

Assuming my state looks like this:

typealias BarId = Tagged<Bar, String>

struct BarState: Identifiable {
  var id: BarId
  var x: Int
}

struct FooState {
  var barStates: IdentifiedArrayOf<Bar>
}

And I have a dependency Baz with a method to update Bar.x which looks like this:

protocol BazType {
  func getX(for id: BarId) -> Int
}

My BarFeature would look like this:

struct BarFeature: Reducer {
  typealias State = BarState
  enum Action {
    case getX
    case setX(Int)
  }
  
  var id: BarId
  
  @Dependency(\.baz)
  var baz
  
  var body: ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .baz:
        return Effect.run { send in
          let x await baz.getX(for: id)
          send(.setX(x))
        }
      }
    }
  }
}

Now I would like to use it in my FooFeature like this:

struct FooFeature: Reducer {
  struct State = FooState
  enum Action {
    case bar(BarFeature.Action)
  }
  
  var body: some ReducerOf<Self> {
    EmptyReducer()
    .forEach(state: \.barStates, action: /Action.bar) { /* doesn't take any arguments */ in
      let id = ... // TODO: Where does this come from?
      BarFeature(id: id)
    }
  }
}

I know that I could make FooFeature responsible for interacting with the dependency, by either handling the action up there in the first place or delegating it up. But let's assume I've a few different states on the level of BarFeature. For me, this would feel tedious, lead to a lot of extra effort when introducing new capabilities to BarFeature and also break separation of concerns. So I would rather make BarFeature responsible for it.

Looking into how the _ForEachReducer was implemented, I can see that there is an internal dependency as \.navigationIDPath available, which at least keep track of the ID, but this is merely used for internal bookkeeping purposes (e.g. cancelling related effects) and not for public consumption (hence it's not part of the public API, anyway).

So for now I've resorted to implement my own _ForEachWithIdReducer, but this looses out on many of the amenities of the built-in _ForEachReducer, as e.g. automatically cancelling the outstanding effects of elements removed from the collection. It would also re-initialize a new reducer on every action on the fly instead of recycling just one.

As an alternative to initializing the Reducer with the ID, I've considered to have a scoped type for my dependency, e.g.:

struct BarSpecificBaz {
  func getX() -> Int
}

Then I could pass this in from my FooFeature, but I'd still need my .forEachWithId-reducer to get the ID in the first place:

.forEachWithId(state: \.barStates, action: /Action.bar) { id in
  BarFeature(id: id)
    .dependency(\. barSpecificBaz, baz.scope(for: id))
}

As an alternative to consider, a _DependencyKeyWritingReducer which exposes the action to the transform closure could also help here:

.forEach(state: \.barStates, action: /Action.bar) {
  BarFeature()
}
.transformDependency(\.self) { dependencyValues, action in
  dependencyValues.barSpecificBaz = dependencyValues.baz.scope(for: id)
}

The syntax of that would be a little more tedious to use, but such a Reducer seems easier to implement in user-code without loosing out on aforementioned amenities of the built-in .forEeach.

But here it starts getting really hard for me to reason about the internals of TCA and Dependencies. I'm curious to see what others have come up with to handle such scenarios.

[mbrandonw]

Hi @mrackwitz, I think I'm a little confused with this definition of the reducer:

struct BarFeature: Reducer {
  typealias State = BarState
  var id: BarId
  …
}

Why does BarFeature need an ID when state.id is available? Doesn't this even open up the possibilities of invalid data where self.id != state.id?

If you got rid of the id on BarFeature then you would just use the dependency by accessing the ID directly on state:

case .baz:
  return .run { [id = state.id] send in
    let x = await baz.getX(for: id)
    send(.setX(x))
  }

[mrackwitz]

Thanks Brandon for helping me to spot this. Now where you say it, it's actually quite obvious. 🫣

I think I was so busy porting some code from beta TCA with explicit generic Environment type that I was unable to see the forest for the trees. 🌳😅