[ReducerProtocol] Same scope syntax for every child-type

[jtouzy]

I recently tried the new reducer protocol syntax, and the main problem I faced in, is that all the pullback functions are written in different ways and can be hard to understand in first read.

For example, a module with multiple child types (optional, collection & classic) :

var body: some ReducerProtocolOf<Self> {
  Scope(...)
  Scope(...)
  Reduce {
    ...
  }
  .ifLet(...)
  .forEach(...)
}

With this example, it's easy to read thanks to the dots. But when we have 3 lines for each scope, it can sometimes not even fit on the screen, and we can't see & understand the main local reducer first. After all, all those scopes are most of the time just links to other modules.

I understand the point that the first scoped reducers have to run first, and the ifLet & other tools has been made to avoid mistakes with optional reducers order.

But we could make a simple native reducer operator to have the same syntax for all types of scopes, like this one :

extension ReducerProtocol {
  @ReducerBuilder<State, Action>
  func scope<Child>(
    state toChildState: WritableKeyPath<State, Child.State>,
    action toChildAction: CasePath<Action, Child.Action>,
    @ReducerBuilder<Child.State, Child.Action> _ child: () -> Child
  ) -> some ReducerProtocolOf<Self> where Child: ReducerProtocol {
    Scope(state: toChildState, action: toChildAction, child)
    self
  }
}

Usage:

var body: some ReducerProtocolOf<Self> {
  Reduce {
    ...
  }
  .scope(...)
  .scope(...)
  .ifLet(...)
  .forEach(...)
}

I may open a PR but I need to be sure if it's ok according to the philosophy of non-optional scoping.
I think it's more an helper for not-so-complex modules, like the reduce() function which is here to avoid a full ReducerBuilder in leaf modules.

[mbrandonw]

Hi @jtouzy, thanks for sharing your idea! I think it'd be best to get other people's opinions before opening up a PR. Also luckily this could be shipped outside the library, so easy to add in your own projects or have some kind of "TCA additions" library.

One thing I want to call out is potentially confusing ordering. With this:

var body: some ReducerProtocolOf<Self> {
  Scope(A)
  Scope(B)
  Reduce {
    C
  }
}

…it is very clear that A will be run, then B, then C.

But the equivalent for .scope:

var body: some ReducerProtocolOf<Self> {
  Reduce {
    A
  }
  .scope(B)
  .scope(C)
}

Actually runs C first, then B, and then A.

You could flip the order inside your .scope implementation so that it runs A, then B and then C, but then that means if you want to run something before the Reduce { A } you will need to use Scope anyway, so now we have two tools for the same thing.