Reducing scoped enum state

[rcarver]

I'm working on some onboarding flows that tend to look like this, some state and a set of routes that you move through.

public struct NewUserFeature: ReducerProtocol {
    public struct State: Equatable {
        var route: Route
        // other state
    }
    public enum Route: Equatable {
        case carousel(CarouselFeature.State)
        case permissions(PermissionsFeature.State)
        case personalUpgradePrompt(PersonalUpgradePromptFeature.State)
        case upgradeSuccess(SuccessFeature.State)
    }
    public enum Action: Equatable {
        case carousel(CarouselFeature.Action)
        case finished
        case permissions(PermissionsFeature.Action)
        case personalUpgradePrompt(PersonalUpgradePromptFeature.Action)
        case productResponse(TaskResult<SeriesProduct?>)
        case task
        case upgradeSuccess(SuccessFeature.Action)
    }
}

---

Trying to figure out the best way to scope to \.route and then run each case. This works, but is rather awkward. FYI I had to specify EmptyReducer<Route, Action> to avoid slow compilation.

public var body: some ReducerProtocol<State, Action> {
  Scope(state: \.route, action: /Action.self) {
    EmptyReducer<Route, Action>()
      .ifCaseLet(/Route.carousel, action: /Action.carousel, then: CarouselFeature.init)
      .ifCaseLet(/Route.permissions, action: /Action.permissions, then: PermissionsFeature.init)
      .ifCaseLet(/Route.personalUpgradePrompt, action: /Action.personalUpgradePrompt, then: PersonalUpgradePromptFeature.init)
      .ifCaseLet(/Route.upgradeSuccess, action: /Action.upgradeSuccess, then: SuccessFeature.init)
  }
  Reduce { state, action in
    // core behavior
  }
}

---

Another way seems to be using Scope for key path, then case path. That looks cleaner, but the compiler is having trouble. 1 case compiles quickly, 2 is ok, 3 is slow, and 4 never completes.

Scope(state: \.route, action: /Action.self) {
  Scope(state: /Route.carousel, action: /Action.carousel, CarouselFeature.init)
  Scope(state: /Route.permissions, action: /Action.permissions, PermissionsFeature.init)
  Scope(state: /Route.personalUpgradePrompt, action: /Action.personalUpgradePrompt, PersonalUpgradePromptFeature.init)
  Scope(state: /Route.upgradeSuccess, action: /Action.upgradeSuccess, SuccessFeature.init)
}

---

Both forms have the potential ordering problem that the 'trailing' style of .ifLet() is supposed to avoid.

Questions

• Does anyone have a preferred way of defining this?
• Any tips for helping the compiler?

---

Side note: this is a tiny nitpick from the new ReducerProtocol style. It's been a joy to use on some new work with very common iOS patterns - onboarding, purchase, settings, etc.

[iwt-sebastian-boldt]

@rcarver I experienced the same issues and that is why I went for the first solution in the end.
I kinda like the readability of the double-scoped approach more but as you already mentioned, the compiler is not playing very well with this. It worked nicely for a single child but just after adding a second scope, everything felt apart.

Fingers crossed that the maintainers of this Project will release the new navigations tools soon 🤞

PS: You can find an ongoing discussion about this topic right here:
#1297