Thoughts on "Action Boundaries" to keep Actions organized and their intent explicit

[tylerjames]

I recently read this article by Krzysztof Zabłocki, an avid TCA user, who raises some interesting points about observing and handling actions of child reducers in parent reducers. Here's the article: https://www.merowing.info/boundries-in-tca/

Some takeaways:

1. Many actions are often private implementation details of a feature, but since enums don't have access control (public, private etc) they are always exposed—many, if they were functions, would be marked private.
2. When a parent reducer consumes a child reducer's actions it will often explicitly handle one or two actions and then ignore the rest. It would be a big mess to have to explicitly handle every single child action as most would not be relevant. The problem here is that if the child reducer added more actions we would not get any compiler help in the parent reducer letting us know that there are more cases that need to be handled.
3. The conclusion reached is that we should make it explicit, by convention, which actions can/should be consumed by a parent reducer by placing them in a different sub-enum within the child reducer's Action enum.

It looks something like this:

enum MyFeatureActions: Equatable {
  enum Delegate: Equatable {
    case userLoggedIn
  }

  case onDidTapLogin // User Action
  case _someInternalAction // Internal Action
  case delegate(Delegate)  // Delegate Action
}

Later he mentions another user (@IanKeen) who takes it a step further and scopes the actions into delegate, view, and internal action types.

I think this makes a lot of sense. I've only recently started integrating features into bigger stores and I can already see how it is becoming a bit tricky to know which child actions I should be looking at from parent reducers.

What does everyone think? Does this all seem like a good idea?

[Alex293]

I do tend to use the "delegate" pattern for this.

One nice thing when you group your actions is that you can ignore certains groups while switching but handle all actions in another group. You are then notified when there is a new action in the handled group. ex:

switch action {
case .delegate(. userLoggedIn): // Do something 
case .internal, .internalFromAnotherFeature: return .none
}

Here I'm notified whenever there is a new action that the parent /delegate should handle but not when adding a private one.

Thought you then need more types, scoping / pullback ... which can be turned into an operator.

TBH it really differs from feature to feature. I see TCA as composability oriented and a lot of time there is not much gain to hide those actions.

One last thing, splitting your actions force you to clone some actions that would be one if flattened. Like starting a refresh task from a timer and from the UI..

[tylerjames]

One nice thing when you group your actions is that you can ignore certains groups while switching but handle all actions in another group. You are then notified when there is a new action in the handled group.

Yeah that was one of the key points he made in the article. You can get exhaustive handling and compiler help without having to explicitly handle every possible action from the child reducer.

[tylerjames]

The more comprehensive grouping looked like this:

public protocol TCAFeatureAction {
    associatedtype ViewAction
    associatedtype DelegateAction
    associatedtype InternalAction

    static func view(_: ViewAction) -> Self
    static func delegate(_: DelegateAction) -> Self
    static func internal(_: InternalAction) -> Self
 }
 
 public enum MyFeatureAction: TCAFeatureAction {
   enum ViewAction: Equatable {
      case didAppear
      case toggle(Todo)
      case dismissError
   }

   enum InternalAction: Equatable {
     case listResult(Result<[Todo], TodoError>)
     case toggleResult(Result<Todo, TodoError>)
   }

   enum DelegateAction: Equatable {
     case ignored
   }

  case view(ViewAction)
  case internal(InternalAction)
  case delegate(DelegateAction)
}

[fabstu]

@andriyslyusar

As far as I understand, Scope(state: action:) takes in the action argument (ChildAction) -> (ParentAction), you can call it a function that turns a child action that the child emitted into a parent action. Its so that child actions also arrive at the parent, but wrapped in a parent action for when the parent cares to handle it (for example delegate methods that the parent wants to handle).

For a nested enum, the ChildAction is first wrapped inside the InternalAction.childFeature(action:) action of the InternalAction enum. But since that is not the Action Scope wants (it wants an Action, not an InternalAction), that InternalAction is then wrapped with the Action.interna parent action, which the parent can then handle.

I'm not sure that's correct, but that is how I explain it to myself.

fwiw: Currently, I'm trying out out a helper to not have to define the parent Action enum in every reducer that follows the paradigm, and instead having a separate reducer function for each category (feature, delegate, internal and view) as well. I like the cleanliness of separating possible delegates of child features from view actions.

Update: It really depends on the view. For complex view there can be a small benefit, but for simple views using multiple enums is useless. Most is gained already by factoring-out logic from the reducer body.

[mbrandonw]

edit: After some experimentation I got it to work with this:

Yep, that's the way to do it. Alternatively you can nest 2 scopes, or you can use the .appending(path:) method on case paths.

[andriyslyusar]

Thanks everybody for replies. Xcode is quite bad with discoverability of custom operator implementations. As Brandon mentioned I used 2 nested scopes, but the custom operator syntax in way cleaner.

[krzysztofzablocki]

In the extended article I added extension to make this easier:

extension Store where Action: TCAFeatureAction {
    func scope<ChildState, ChildAction>(
        state toChildState: @escaping (State) -> ChildState,
        action fromChildAction: CasePath<Action.InternalAction, ChildAction>
    ) -> Store<ChildState, ChildAction> {
        scope(
            state: toChildState,
            action: { ._internal(fromChildAction.embed($0)) }
        )
    }
}

Then it becomes this:

store.scope(
  state: \.settings,
  action: /AppFeature.Action.InternalAction.userSettings
)

[acosmicflamingo]

Oh this is really interesting. I imagine something like this would make its way to TCA probably after 1.0.0 has been released?

[acosmicflamingo]

@mbrandonw @stephencelis I see that isowords is actually utilizing multiple actions enums like what is described in this discussion: https://github.com/pointfreeco/isowords/blob/main/Sources/OnboardingFeature/OnboardingView.swift#L153.

Would I be better off going all-in on adopting the ideas mentioned in this discussion or is there something you both are cooking up that deviates a bit from this approach? I'm reluctant to write a bunch of code that will eventually need to be refactored in a few months, but then again that could just come with the territory, so to speak ;)

[stephencelis]

@acosmicflamingo We're fans of this approach and think it's totally additive on top of TCA. Don't think TCA will change in a way that nullifies this idea any time soon 😄

[acosmicflamingo]

YEAHHHHHHHHHHHHHHHHHH!!! 🎊 Sounds great!

[patch-benjamin]

Love this idea! We're just getting around to looking at this approach for our app.
@stephencelis I'm curious, does "any time soon" still apply now (a year later) or is this scheduled on a roadmap currently?

[stephencelis]

@patch-benjamin We still utilize Delegate actions throughout our apps. It's still a totally fine thing to do and it shouldn't go against the grain of the app.

[acosmicflamingo]

@krzysztofzablocki by the way, I've been a huge fan of your work (e.g. LifetimeTracker) way before I knew how much of an influence you are in the Swift/iOS community :) nice to see you heavily involved with TCA too :D

So reading the very end of your article TCA Action Boundaries, am I correct to say that you now prefer to make ViewAction calls within a View/ViewController and that InternalActions should explicitly be called within the reducer? If so, does that mean the cleaner scope is worth the potential performance cost of sending multiple actions within a reducer where one action would have sufficed?

The reason I ask is because in the Performance article, I learned that sending actions is a bit more costly than just calling a simple function. To use a concrete example, let's say I have a MusicLibrary reducer that is supposed to load the music library into state with a .loadSongs action. Before reading your article, I would've just executed a simple viewStore.send(.loadSongs) in viewDidLoad and the MusicLibrary reducer would comprise the following:

switch action {
case .loadSongs:
  state.songs = fetchSongs()
  return .none
}

With this new approach, I would be executing viewStore.send(.didLoad) in viewDidLoad and in the MusicLibrary reducer, I'd have something like this:

switch action {
case let .view(viewAction):
  switch viewAction {
    case .didLoad:
      return .run { send in
        send(._internal(.loadSongs))
      }
  }
case let ._internal(internalAction):
  switch internalAction {
    case .loadSongs:
      state.songs = fetchSongs()
      return .none
  }
}

Would this be new approach be frowned down upon because we are now sending two actions where it would've just taken one? Perhaps what I should be taking away from the Performance article is not that sending multiple actions is always discouraged, but that it is costly when an action is being treated as a function executing shared logic throughout the reducer. Sorry if this is me being overly analytical too; I have a tendency to not see the forest for the trees ;)

[acosmicflamingo]

Perhaps I shouldn't have used fetchSongs because you are right; a better way to do it would be something like:

return .run { send in
  await .didLoadSongs(fetchSongs)
}

What I'm really trying to figure out here is whether the Performance article saying "Sending actions are more computationally expensive than simple function calls" also apply to scoping the Action enum to its sub-enum ViewActions in a View/ViewController like what Krzysztof says he does in the August 28th update of his "TCA Action Boundaries" article:

What this tells me is that all the internal logic is called in the reducer, and I don't know if sending another action back into the store is always seen as an anti-pattern or whether it's only an anti-pattern when dealing with sharing logic with actions. Does that help?

[mbrandonw]

and I don't know if sending another action back into the store is always seen as an anti-pattern or whether it's only an anti-pattern when dealing with sharing logic with actions.

Hi @acosmicflamingo, I don't feel strongly enough about this topic to give a universal answer, but I will at least say that in that vast majority of cases, sending a synchronous action back into the system is an anti-pattern. The biggest exception is the use of "delegate" actions, which are a communication mechanism from child to parent that help the parent not make assumptions about what is happening in the child domain.

But sending actions from child to child is superfluous and unneeded. You should just invoke internal logic via helper methods defined on the reducer or mutating methods defined on the state.

Having said all of that, I don't think any of the above contradicts the pattern @krzysztofzablocki discusses in his blog post. If you notice, his "internal" actions are the results of executing effects, such as toggleResult and listResult. They are not actions such as fetchSongs, which is a description of what you want to do and not what happened. Those are the types of actions we are discouraging since it leads toward a pattern of firing off needless, synchronous actions just to execute logic.

We plan on writing more about this in our documentation, but our personal recommendation is to name actions after things that are happening rather than a command to be performed. So, it's things like .viewDidAppear and not .fetchSongs. Even effect actions fall into this category, after all, all effects are the result of a user action and then feed data back into the system. Delegate actions also fall into this pattern as they represent some goal the user accomplished that the parent domain may be interested in.

And I will end with the caveat that this is our personal recommendation. Others have different opinions, and so hopefully when Stephen and I get around to gathering up our recommendations we can provide links/context for other styles out there.

Hope that clarifies some things.

[acosmicflamingo]

@mbrandonw Oh okay! Yes, this clarifies an absolute ton; I had not noticed that the internal actions are indeed the results of executing effects. I really appreciate you (and @lukeredpath) taking the time to chime in with your thoughts :)

[krzysztofzablocki]

I wouldn't translate from View to Internal just to do something as that would be performance-costly and unnecessary abstraction IMO, Internal is usually used for actions unrelated to view actions like server response coming from environment registration, I agree with what @mbrandonw said above, sorry if that was unclear from the article

[acosmicflamingo]

For anyone in the future reading this post and liking the nested switch statement that I wrote, please DON'T do that. When your reducer gets large, it becomes SO hard to figure out whether the current case is for your X action or Y action. Flattening out the switch statements may mean you have a long case like case let .view(.foo(.bar(.hahahaha(.success(ohboy))))) but at least you know what the action is, no matter where in the reducer you are looking.

switch action {
-case let .view(viewAction):
-  switch viewAction {
-    case .didLoad:
-      return .run { send in
-        send(._internal(.loadSongs))
-      }
-  }
-case let ._internal(internalAction):
-  switch internalAction {
-    case .loadSongs:
-      state.songs = fetchSongs()
-      return .none
+case .view(.viewDidLoad):
+  return .run { send in
+    send(._internal(.loadSongs))
   }
+
+case ._internal(.loadSongs):
+  state.songs = fetchSongs()
+  return .none
}

[davdroman-rdx]

Related to this, I'm looking for some clarification about why

swift-composable-architecture/Examples/TicTacToe/tic-tac-toe/Sources/NewGameSwiftUI/NewGameView.swift

Lines 24 to 30 in b8294b8

	enum ViewAction {
	case gameDismissed
	case letsPlayButtonTapped
	case logoutButtonTapped
	case oPlayerNameChanged(String)
	case xPlayerNameChanged(String)
	}

is defined at the view level as opposed to the action level as presented by @tylerjames #1440 (comment).

Is this simply a case of outdated code or is there a different purpose to this I might've missed?

[tgrapperon]

This one is more in the same spirit as ViewState where you limit what you can see from the View. Here, you limit what you can send to the store from the UI, mostly for safety reasons. This idea predates Krzysztof works, where the segmentation is more a Reducer domain stuff. This explains why it was defined at the View level, but it could totally work if embedded in the main Action one.

[davdroman-rdx]

This makes sense, so then with WithViewStore(_:observe:send:) surely it's better not to have to duplicate view actions at the view level and do this instead:

extension MyFeature {
    enum Action {
        case view(ViewAction)
        case `internal`(InternalAction)
        case delegate(DelegateAction)
    }
}

...

WithViewStore([...], observe: \.state, send: MyFeature.Action.view) { viewStore in
    // viewStore can only send `Action.view(...)`.
}

[tgrapperon]

Yes, this is the canonical way if you mix Krzysztof's style with the latest APIs.

[lukeredpath]

One reason why you may still want to take the approach of defining your view-specific actions closer to your view rather than your reducer is in the case where a feature isn't strongly coupled to a specific UI implementation. In most cases you might not need this, but you could for example have the same feature domain logic shared between iPhone, iPad and tvOS UIs for example which have their own view specific actions that are translated into domain actions.

[colemcampbell]

@krzysztofzablocki @IanKeen I'm new to TCA, so this may be a naive suggestion, but how do you feel about using the name EffectAction instead of InternalAction? It seems to me like it would be nice to create a parallel with how ViewAction indicates the source of the action, and it might encourage users not to send actions back into the system unnecessarily.

[rzolin]

I like the approach of separating the actions! But I got bogged down in the scoping:

   public enum Action: TCAFeatureAction {
        
        case view(ViewAction)
        case `internal`(InternalAction)
        case delegate(DelegateAction)
        
        public enum ViewAction: Equatable {
            case showLogin(ATLoginFeature.Action)
            
            public enum Alert {
                case logout
                case retry
            }
        }
        
        public enum InternalAction: Equatable {
            case logout
            case handleError(EquatableError)
        }
        
        public enum DelegateAction: Equatable {
        }
    }

    public var body: some ReducerOf<Self> {
        
        Reduce<State, Action> { state, action in
            switch action {
        }

        // Error below: Static method 'buildExpression' requires the types 'ATAppFeature.Action' and 'ATAppFeature.Action.ViewAction?' be equivalent
        Scope(state: \.login, action: /Action.ViewAction.showLogin) {  
            ATLoginFeature()
        }
    }

and similar in the view:

    NavigationStack {
        ATLoginView(
            store: store.scope(
               state: \.login,
               // Error below: Cannot convert value of type '(ATLoginFeature.Action) -> ATAppFeature.Action.ViewAction' to expected argument type '(ATLoginFeature.Action) -> ATAppFeature.Action'
               action: ATAppFeature.Action.ViewAction.showLogin
            )
        )
    }

I used the extension(s) for scoping internal and view actions:

extension Store where Action: TCAFeatureAction {
    func scope<ChildState, ChildAction>(
        state toChildState: @escaping (State) -> ChildState,
        action fromChildAction: CasePath<Action.InternalAction, ChildAction>
    ) -> Store<ChildState, ChildAction> {
        scope(
            state: toChildState,
            action: { .internal(fromChildAction.embed($0)) }
        )
    }
}

extension Store where Action: TCAFeatureAction {
    func scope<ChildState, ChildAction>(
        state toChildState: @escaping (State) -> ChildState,
        action fromChildAction: CasePath<Action.ViewAction, ChildAction>
    ) -> Store<ChildState, ChildAction> {
        scope(
            state: toChildState,
            action: { .view(fromChildAction.embed($0)) }
        )
    }
}

What am I missing? Any help would be appreciated!

[krzysztofzablocki]

I use

extension Scope where ParentAction: TCAFeatureAction {
    @inlinable
    public init(
      state toChildState: WritableKeyPath<ParentState, Child.State>,
      action toChildAction: CasePath<ParentAction.InternalAction, Child.Action>,
      @ReducerBuilderOf<Child> _ child: () -> Child
    ) {
        self = .init(state: toChildState, action: (/ParentAction._internal) .. toChildAction, child)
    }
}

and

extension Store where Action: TCAFeatureAction {
    func scope<ChildState, ChildAction>(
        state toChildState: @escaping (State) -> ChildState,
        action fromChildAction: CasePath<Action.InternalAction, ChildAction>
    ) -> Store<ChildState, ChildAction> {
        scope(
            state: toChildState,
            action: { ._internal(fromChildAction.embed($0)) }
        )
    }
}

[rzolin]

Thanks @krzysztofzablocki . Will give it a try

[pm-dev]

New to TCA, but it quickly noticed this issue. Before seeing this thread, here's what I came up with as a workaround:

enum FeatureAction<ViewAction, SideEffect> {
    case viewAction(ViewAction)
    case sideEffect(SideEffect)
}
protocol Feature: Reducer where Action == FeatureAction<ViewAction, SideEffect> {
    associatedtype ViewAction
    associatedtype SideEffect
    func reduce(into state: inout State, viewAction: ViewAction) -> Effect<SideEffect>
    func reduce(into state: inout State, sideEffect: SideEffect) -> Effect<SideEffect>
}
extension Feature {
    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .viewAction(let viewAction):
                reduce(into: &state, viewAction: viewAction).map { .sideEffect($0) }
            case .sideEffect(let sideEffect):
                reduce(into: &state, sideEffect: sideEffect).map { .sideEffect($0) }
            }
        }
    }
}

[pm-dev]

Thanks for the reply and help. I figured out how to adapt the Feature protocol to work with parent/child scoped stores

struct ChildFeature {
    struct State {}
    enum ViewAction {}
}
struct ParentFeature: Feature {
    struct State {
        var childState: ChildFeature.State
    }
    enum ViewAction {}
    @CasePathable enum SideEffect {
        case childViewAction(ChildFeature.ViewAction)
    }
}

Then to get the child store:

let parentStore: StoreOf<ParentFeature>
let childStore: Store<ChildFeature.State, ChildFeature.ViewAction> = parentStore.scope(
    state: \.childState,
    action: \.sideEffect.childViewAction)

This works how we'd want. The parent and child views can only send their respective ViewAction's. My misunderstanding previously was from thinking ChildFeature was supposed to be a Reducer itself, but now I see the ParentFeature is supposed to handle actions from its children.

But SideEffect now contains child view actions which isn't quite right. What we need is to update the Feature protocol to keep these 3 things separate (ViewAction from the parent, ViewAction from the child, SideEffect of the parent's reducer):

@CasePathable
enum FeatureAction<ViewAction, SideEffect, ChildViewAction> {
    case viewAction(ViewAction)
    case sideEffect(SideEffect)
    case childViewAction(ChildViewAction)
}
protocol Feature: Reducer where Action == FeatureAction<ViewAction, SideEffect, ChildViewAction> {
    associatedtype ViewAction
    associatedtype SideEffect: Sendable
    associatedtype ChildViewAction
    func reduce(into state: inout State, viewAction: ViewAction) -> Effect<SideEffect>
    func reduce(into state: inout State, sideEffect: SideEffect) -> Effect<SideEffect>
    func reduce(into state: inout State, childViewAction: ChildViewAction) -> Effect<SideEffect>
}
extension Feature {
    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .viewAction(let viewAction):
                reduce(into: &state, viewAction: viewAction).map { .sideEffect($0) }
            case .sideEffect(let sideEffect):
                reduce(into: &state, sideEffect: sideEffect).map { .sideEffect($0) }
            case .childViewAction(let childViewAction):
                reduce(into: &state, childViewAction: childViewAction).map { .sideEffect($0) }
            }
        }
    }
    func reduce(into state: inout State, childViewAction: Never) -> Effect<SideEffect> {}
}

Then to get a scoped store:

parentStore.scope(state: \.childState, action: \.childViewAction.myChildViewAction)

[mbrandonw]

My misunderstanding previously was from thinking ChildFeature was supposed to be a Reducer itself, but now I see the ParentFeature is supposed to handle actions from its children.

I may be misinterpreting this, but from our perspective this is definitely not the case. There definitely should be a ChildFeature reducer that gets composed into the ParentFeature reducer, and the parent should not be handling all of the child's logic. In fact, doing this only prevents you from making use of all of our powerful navigation tools.

I want to iterate that we feel this kind of over abstraction seems to only be complicating something that should be quite simple, and we would recommend scaling it back a bit.

[pm-dev]

As mentioned, I'm new to TCA so learning as I go here. Since the Store.scope function doesn't take a reducer, I assumed any child components/views that take a scoped store, shouldn't user their own reducer. Looking at examples where a scoped store is used, I don't see those children having their own reducer. Is there a more illustrative example of children that use a scoped store and have their own reducer?

I disagree this is an "over abstraction". Allowing a view to send a "requestCompleted" action or allowing an effect to send a "buttonTapped" action feels broken to me. This discussion as well as others is evidence it's not just me that thinks this.

[mbrandonw]

Since the Store.scope function doesn't take a reducer, I assumed any child components/views that take a scoped store, shouldn't user their own reducer.

Store.scope is an operation to derive child stores from parent stores, and is a separate thing from composing reducers. Reducer composition is still important, and necessary to properly wield stores.

Typically you have a Store that is generic over some feature domain, StoreOf<Feature> where Feature is a reducer, and further Feature typically holds onto some child features, which are also reducers. You then scope StoreOf<Feature> down to a child store StoreOf<ChildFeature> by using key paths to single out the child state and actions in the parent feature.

Looking at examples where a scoped store is used, I don't see those children having their own reducer. Is there a more illustrative example of children that use a scoped store and have their own reducer?

That example is actually showing what I am describing. The ForEachStore derives a store for each element in a collection:

ForEachStore(self.store.scope(state: \.filteredTodos, action: \.todos)) { store in

And then that child store is handled to the child view of TodoView:

TodoView(store: store)

And the todo domain is a reducer itself:

@Reducer
struct Todo {
  …
}

struct TodoView: View {
  let store: StoreOf<Todo>
  …
}

Is there a more illustrative example of children that use a scoped store and have their own reducer?

Every example in the repo follows the pattern of scoping a parent domain into a child domain, where the child is a reducer itself. The simplest example is in the TwoCounters case study:

HStack {
  Text("Counter 1")
  Spacer()
  CounterView(store: self.store.scope(state: \.counter1, action: \.counter1))
}

HStack {
  Text("Counter 2")
  Spacer()
  CounterView(store: self.store.scope(state: \.counter2, action: \.counter2))
}

…where CounterView is a reducer feature all on its own.

But really, every case study and demo app does the same thing. It may not always be as simple as seeing store.scope directly in the view because there are many helpers the library comes with for transforming stores in more complex ways. For example, turning stores of optional domains into stores of honest domains (IfLetStore), turning stores of collections into stores of elements (ForEachStore), and more. But luckily all of those tools are going away once the observation tools are merged into main, and then you will see simple store.scope directly in views.

This discussion as well as others is evidence it's not just me that thinks this.

There is merit in some of these abstractions, but it is still possible to go overboard. And since you said you are new to TCA, I believe that jumping into these kinds of abstractions is putting the cart before the horse. I think you would get a lot more use out of reading the documentation and going through the tutorials than reaching for these kinds of abstractions.

[pm-dev]

This is helpful. I was missing where child reducers were created and how they were managed/composed with the parent (i.e. this).

fwiw some of my gap in understanding here is likely due to the fact that I've been looking to integrate TCA with a UIKit app, as a preliminary step before migrating the app to SwiftUI. TCA is built with SwiftUI in mind, and as such, the examples/guides/docs use SwiftUI. With limited resources, it makes sense why there's not equivalent guides for integrating with UIKit, but the learning material has seemed less useful/applicable for me, beyond learning the major concepts. With that said, I agree it'll be useful to understand the SDK better so I can work with what's provided.