RFC: Remove public-facing reduce requirement from Reducer

[stephencelis]

Hi all!

We’d like to make a pretty substantial change to the Composable Architecture, and that is to remove the public-facing reduce method requirement of the Reducer protocol. Instead, we’d like to encourage that folks always use the body property as the single way of conforming to the reducer protocol:

// Before:
struct Feature: Reducer {
  struct State { /* ... */ }
  enum Action { /* ... */ }
  func reduce(into state: inout State, action: Action) -> Effect<Action> {
    // ...
  }
}

// After:
struct Feature: Reducer {
  struct State { /* ... */ }
  enum Action { /* ... */ }
  var body: some Reducer<State, Action> {
    Reduce { state, action in
      // ...
    }
  }
}

We have found that most people tend to start new reducers with the body property anyway since the vast majority of time you will eventually compose more reducers into your reducer.

Pros:

• Less surface area and fewer quirks to learn or know about. You don’t need to know about reduce or think about when to use it vs. body with a Reduce.
• Less churn when refactoring a leaf feature from reduce to body.
• It will allow us more freedom to make substantial changes/improvements to the underlying structure of reducers in the future.

Cons:

• Theoretically, Reduce may incur a small performance penalty. We don’t think it will be measurable in most applications, as the closures do not actually escape the body of most reducer conformances. This probably will not actually affect many people since as we mentioned above, most people seem to use the body style of reducer anyway.
• Swift can have a little bit of a harder time type-checking Reduce closures vs. the reduce method, and in some earlier versions of Swift, explicit generics (Reduce<State, Action>) are required to restore diagnostics and autocomplete. Recent versions of Swift, however, have mitigated many of these problems.

We plan on starting to make these changes soon, but we wanted to communicate to users of the Composable Architecture to give them time to ask any questions, and communicate any feedback or concerns.

Please let us know what you think!

[ZevEisenberg]

As someone who loves premature optimization and pedantic rules, I'll miss it, but I think the wins in consistency and similarity to View's body var are worth it.

[stephencelis]

While we don't want folks to reach for it without a measurable reason to do so, we could theoretically make the underlying, inlinable core method still available for such a purpose.

[tgrapperon]

I'm all-in for the change! That being said, reduce has its merits when implementing higher order reducers like Scope or _IfLet. Are there plans to expose the function again in some way¹, or will Reduce { state, action in … } be the way to implement such reducers?

Footnotes

1. If it works like SwiftUI, it seems that we can still implement reduce ourselves without completion, but I'm wary that we'll perform additional stuff with it at some point. ↩

[stephencelis]

I think we'd still recommend Reduce for these purposes outside the library. Do you have any particular concerns with that?

[tgrapperon]

No, I don't. An app where it would make a difference would probably have more serious issues!

[tgrapperon]

I've just benchmarked a few examples, and it doesn't make any significative difference.

[ibrahimkteish]

I consistently utilise var body: some Reducer<State, Action> { ... } in my code. 👍

[acosmicflamingo]

Me too; I'm all for this change :)

[klundberg]

I've been bit by the issue where providing both the current reduce method and the body property at the same time causes undesired behavior, so removing it in favor of one true way of making a reducer sounds good to me as a way of removing that potential strange issue from happening again!

[Jager-yoo]

Great change! I've always struggled to explain the difference between the two styles of creating a Reducer, and even I wasn't confident in my understanding of it. 😅
If there was a recommended way to create a Reducer, it would definitely lower the hurdle for TCA beginners.

One question though, When declaring var body: some ~, it's possible to use either Reducer<State, Action> or ReducerOf<Self> as the opaque type.
This leads to some inconsistencies in our code, as team members have their own preferred style.
Will you guys settle on one style, or let developers continue to have the choice? I'd appreciate your opinion. Thanks!

[stephencelis]

@Jager-yoo It's really a stylistic thing, but ReducerOf<Self> is shorter and almost always works, so it might be worth defaulting to that if your team agrees.

[Jager-yoo]

Will do. Thanks, stephen!

[TC72]

This is great, consistency is key, especially when you're learning like myself.