Sharing methods for actions

[jtflaten]

I'd like to share logic for updating the state in a reducer and as far as I can tell both of these compile and work:
A function inside the the reducer itself:

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
        switch action {
            case .doSomething:
                sharedThing()
        }
        func sharedThing() {
            //the code which can use state because it's in scope of the reduce action
        }
    }
}

Compared to a method outside this reducer that we pass the State into as an inout param:

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
        switch action {
            case .doSomething:
                sharedThing(&state)
        }
}
   
private func sharedThing(_ state: inout State) {
     //the code which can use state because it has the state passed into it.    
 }

I'm wondering if there is any known pros/cons that would help me choose one or the other? Alternatively is there a reason I should avoid doing both of these and find another way to share the logic?

[tgrapperon]

Hey @jtflaten! Both approaches are mostly equivalent, and if there are performance differences, they will probably not be noticeable.
Using these functions/methods to perform shared logic is indeed the way to go. You could have modelized this as a dedicated action where the shared work would be performed, and re-emit this action to perform the shared logic, but this approach is not recommended.
Another approach similar to the function/method is to implement this shared logic as some private method of the state itself. This usually allows a little simpler API's signatures, without inout State:

extension Domain.State {
  mutating func handleSharedThing(parameter: Int) {
    if parameter.isMultiple(of: 3) {
      self.value = 0
    }
  }
}

…

func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
  switch action {
  case .doSomething(let amount):
    state.handleSharedThing(parameter: amount)
    return .none
  }
}

It really depends if the shared work is more State centric or not. There is no absolute rule.
You can also produce an Effect[Task]<Action> with these functions and see them as "components" of the final Effect that can be built by merging them.