Reducers Action Handling Response Pattern

[thebarndog]

I've been running into this pain point with TCA for a while now and I'm curious to get people's thoughts. The problem is with reducer actions. Take the code from the README:

struct Feature: Reducer {
  struct State: Equatable { /* ... */ }
  enum Action: Equatable {
    case factAlertDismissed
    case decrementButtonTapped
    case incrementButtonTapped
    case numberFactButtonTapped
    case numberFactResponse(String)
  }
}

There are five actions here but really, there are four actions and a response. That right there is the problem; that this mechanism of responding to actions inside a reducer by doing something like

case .myAction:
    return .run { send in 
        await send(.myActionResponse)
    }

is an anti-pattern because it's

• cluttering the action api. Response handlers and actions are all grouped together even though they're conceptually different. Actions get dispatched by the store and the reducer handles them; response handlers handle the result of a side effect.
• response action cases are now exposed to whomever consumes the feature, leaking the api implementation details.
• indirect and hard to follow. Side effects should defer their results to the same shared place that's separate from actions

When apps get really large, you end up with actions that look like this:

enum Action {
    case userTappedLogin
    case userTappedLogout
    case userTappedButton
    case showPromoAlert

    case userTappedLoginResponse
    case userTappedLogoutResponse
    case userTappedButtonResponse
}

I may be alone in this, I just don't love that what should be an implementation detail, is exposed right alongside all the ways my application can be mutated.

[filiplazov]

I have seen people propose nesting enums, I might have seen in one of the example apps

enum Action {
    case view(View)
    case _internal(Internal)

   enum View {
     case userTappedLogin
     case userTappedLogout
     case userTappedButton
     case showPromoAlert
   }

   enum Internal {
     case userTappedLoginResponse
     case userTappedLogoutResponse
     case userTappedButtonResponse
   }
}

so in your view you will only invoke .view actions

viewStore.send(.view(.userTappedLogin))

[mbrandonw]

Yeah, this is definitely something people do, and you can even further scope the store to just the view actions for the WithViewStore, which makes it impossible for the view to send any actions besides the view ones.

We may even codify this pattern into TCA very soon.

[acosmicflamingo]

Here's a discussion with tons of examples on how others have approached this: #1440. I've not regretted adopting this approach, although I no longer have my ViewStore be of type <ViewState, Action.ViewAction> since ViewStore will be gone pretty soon, and there were corner cases where I wanted to be able to send a delegate action from a viewStore instance.

[thebarndog]

@filiplazov that's what I lean towards as well, not the best but pretty close!

@acosmicflamingo Thanks for the link, that's a really helpful discussion.

@mbrandonw until it's codified, if it is, is there a recommended way to handle this? How would you approach this problem?

[mbrandonw]

It's perfectly fine to demarcate a View action enum that holds only the actions your view should be allowed to send if you are worried about it.

[rcarver]

Just noting that this doesn't bother me in practice, and almost[1] every time I've added such layers it seems unnecessary. I only separate "delegate" actions to clarify the parent integration points. Everything else is internal. A parent observing those internal (non-delegate) actions is both a super power and a code smell that a new delegate action may be appropriate.

If the above example were sufficiently complex, I'd say that login, logout and promo might be separate features, for example:

enum Action {
    case login(LoginFeature.Action)
    case logout(LogoutFeature.Action)
    caes promo(PromoFeature.Action)
    case userTappedButton
}
enum LoginFeature.Action {  // LoginFeature is a Reducer
    case delegate(Delegate)
    case loginButtonTapped
    case loginResponse(TaskResult<LoginResponse>)
    enum Delegate {
        case didLoginSuccessfully
    }
}

[1] Sometimes a single domain can get really complex, I find most often when integrating with UIKit. In those cases I've carved up the actions with ViewAction or similar.