Proposal: ReducerOperation

[Alkenso]

Guys, TCA is amazing framework. It solves lots of problems in v-v-very elegant way!
With the last update in Swift 5.7 it became awesome!

Have an idea/proposal regarding dealing with the Reducer.

The Problem
When dealing with Reducer, I have single place of modifying the State - reduce method that takes the State and the Action.
In real-world apps there are lots of places where the code is similar or reused.
With current approach when I need additional functions to keep duplicated code, I have to pass at least inout State parameter all the time.

The Proposal
Think about some auxiliary structure like (sorry for bad-naming =) )

struct FeatureReducerOperation<State, Action> {
  var state: State

  // All dependencies comes here as well
  // @Dependency(\.uuid) var uuid

  mutating func reduce(_ action: Action) {
    // modify the `state` according to incoming `action`
  }
}

or alternatively

struct FeatureReducerOperation<State, Action> {
  var state: State
  let action: Action

  // All dependencies comes here as well
  // @Dependency(\.uuid) var uuid

  mutating func reduce() {
    // modify the `state` according to `action`
  }
}

Internal mechanics of TCA will

1. Create the Operation with current State and incoming Action
2. Call reduce on it
3. Get modified State back from it

Conclusion
In such approach we get an ability to skip polluting each auxiliary function with inout State and/or Action, accessing them directly from our variables.
Mark auxiliary method as 'mutable' - it mutates the State
Do not mark as 'mutable' - it only reads the state

[stephencelis]

@Alkenso Thanks for the discussion. I'm not sure I fully understand, though, so could you clarify a few things for me?

When dealing with Reducer, I have single place of modifying the State - reduce method that takes the State and the Action. In real-world apps there are lots of places where the code is similar or reused. With current approach when I need additional functions to keep duplicated code, I have to pass at least inout State parameter all the time.

In general, depending on the reuse, we typically see two flavors:

1. Reducer composition (using builders and reducer modifiers) that reuse a single reducer conformance in multiple places.
2. Helper methods. E.g. you could define mutating functions directly on the state type (instead of on a "reducer operation" that wraps it. You can also define helper methods directly on the reducer conformance to clean up duplication.

Also, are you suggesting this as something to complement ReducerProtocol? Or something to replace it? If you're seeing this as an alternative, I think we may come into problems with Swift concurrency, actors, and ownership. If you haven't already, it might be helpful for you to sketch out a prototype and see what happens.

[Alex293]

@Alkenso is your suggestion about moving the state mutations into separate types (Operations) and then have the reducer dispatch an Operations type and effects ? Operation would encapsulate a group of mutation to the state ? I think I saw this approach used somewhere but never needed something like this for now.

[Alkenso]

@stephencelis , thanks for response.
I made such proposal like a replacement of define mutating functions directly on the state type. The main issue here: where is no access to the Environment/Dependencies, so such functions have to accept all parameters from the outside (from Reducer)
If that would be replacement of ReducerProtocol or just some convenient addition - I'm not sure at the moment.

Probably you're right, I'll try to prepare some sketch and share it later in this discussion

@Alex293 Operation will encapsulate the State + single Action. In the calling context of Reducer, it may looks like

var operation = FeatureOperation(state: state, action: action)
operation.injectAllFeatureReducerDependencies(...) // forward dependencies here
operation.reduce()
state = operation.state

[stephencelis]

The main issue here: where is no access to the Environment/Dependencies, so such functions have to accept all parameters from the outside (from Reducer)

You can technically use @Dependency wherever you like, including inside state structs, and we've heard from folks in the community that do just that to control things like UUIDs (we haven't personally done much of this, though). So in this case, it still seems like the extra ReducerOperation might not be necessary.

Definitely interest to see what happens if you try to replace ReducerProtocol with your operation type, though! We've tried out form factors like this in the past and didn't have much luck, but maybe you'll unlock something we missed! 😄