Handle complex logic cases may create huge code inside Reducer. Ideas in how to handle that?

[joelCHonor]

Hi all,
I have a very complex SwiftUI screen (It has a lot of different states and interactions in how to present the controls).
Each state change handling in the reducer will have complex logic. As the reducer became huge, I just moved code to separated functions to handle each state. The only downside is as I need to change properties for the State, each function I created will prepare and update models and returning that into the Reducer to update the State.
Is there a better way to handle this case of cases where the screen is so complex, that each state handling has lot of code?

[tgrapperon]

The only downside is as I need to change properties for the State, each function I created will prepare and update models and returning that into the Reducer to update the State.

Hey @joelCHonor! Extracting cases as functions is indeed a good idea, but I have trouble understanding this. Are you defining functions of state: inout State and not state: State only?

func onValueChange(value: Value, state: inout State) -> Effect<Action, Never> { … }

If you call functions like that from your reducer, they will update the state transparently:

case let valueDidChange(value):
  return onValueChange(value, state: &state)

If you have many actions, it is also maybe a sign that you can decompose your domain into smaller sub-domains (with their own smaller reducers).
Please let me know if I'm misunderstanding the problem, with a simplified example if possible.

[joelCHonor]

Yes, I can do that. The thing is that I don't want to use inOut because that means I would make the functions responsible for editing the state internally, and I would like to keep those functions agnostic of the state

[tgrapperon]

Do you have a specific reason to want to avoid that if this function is private and its sole purpose is to mutate a state value and produce an Effect? Are you working with reference-type states?

You can always rewrite your functions as func process(state: State) -> (State, Effect), but I'm not sure you'll gain anything beside being more complex to handle on your side. At some point, if the state needs to be updated (as it seems it needs to be), then where will it'll be?

Of course, you can reserve inout only for functions that are effectively mutating the state if you prefer, and don't use a state value or pass a simple State value in the other cases.

If you want, you can also implement functions that will only mutate the state, and other that will only produce the effect from an already updated state, and call the both in sequence into your reducer. But again, I'm not certain that you gain much from doing that in the general picture.

The state value you receive in your reducer is private and if it's a value type, you can update it how much you want without producing any side effects along the way. It will only be reinserted into the app's state at the end of the reduction.

A simplified example would very likely help clarifying things.

[tgrapperon]

Please also note that you can be more restrictive with what the function needs to have access to, and you can inout a writeable property of State only:

func handleAction1(count: inout Int) -> Effect<Action, Never> { … }

and

case action1:
  return handleAction1(&state.count)

[natemann]

I have done this by defining functions inside of the reducer. That way, you already have access to the state.

[joelCHonor]

@tgrapperon Thanks for all the feedback you gave me. I really appreciate it. I will take in consideration your suggestions.
I'm new to TCA, so I'm still figuring it out what are the best practices for complex applications