Sending child actions directly from the parent to update the child

[iwt-sebastian-boldt]

I have a brief question regarding parent-child relationships and a possible method of updating the child from the parent.
Suppose I have a parent feature that encapsulates a child in the typical TCA manner.
This involves defining a child property in the state and a case in the action enum that is scoped to the correct reducer.
The child reducer is responsible for updating the text if it receives the update action.
Additionally, the child reducer may have some proprietary business logic that it does not want to expose to external parties. Therefore, updating the text should be the child's responsibility.

struct Parent: ReducerProtocol {
    struct State: Equatable {
        var child: Child.State
    }

    enum Action: Equatable {
        case child(Child.Action)
    }

    var body: some ReducerProtocol<State,Action> {
        Scope(state: \.child, action: /Action.child) {
            Child()
        }
        Reduce { state, action in
            return .none
        }
    }
}

struct Child: ReducerProtocol {
    struct State: Equatable {
        var text: String
    }
    enum Action: Equatable {
        case update
    }

    var body: some ReducerProtocol<State,Action> {
        Reduce { state, action in
            switch action {
                case .update:
                state.text = // do validation or api calls etc. that is related to the Childs Domain
                return .none
            }
        }
    }
}

And in my Parent's View, I want to have a Button that should trigger an action in the child.
Technically, I would be able to send the action directly to the child from the view
or from the reducer by using Effect(value: .child(.update))

struct ParentView: View {
    let store: StoreOf<Parent>

    var body: some View {
        WithViewStore(self.store) { viewStore in
            Button(action: {
                viewStore.send(.child(.update))
                // or..
                viewStore.send(.didPressButton) // in the reducer return Effect(value: .child(.update))
            }, label: {
                Text("Trigger Child Action")
            })
        }
    }
}

Now my question is, is this a common pattern to trigger updates in child views?
Or does it violate some of the principles of TCA?
I am not sure because it works but it feels kinda wrong

[mbrandonw]

Hi @iwt-sebastian-boldt, neither of the styles you have sketched out is recommended in TCA.

First, actions should be named after what the user did in the UI, not what you want to do inside the reducer. So the action .didPressButton is clear and concise because the user just did something in the UI. However, .update is opaque and no one unfamiliar with the intricacies of the child domain will know when that action should be sent.

Further, you should not think of actions as just weird kinds of methods defined for your domain. They are not methods, but instead a concrete description of things that can happen in the UI, and sending actions is a lot more expensive than calling methods. We have an article that goes into detail in this topic.

My suggestion for your set up is for the child state to expose a mutating helper method that can do your logic, including returning effects:

extension Child.State {
  mutating func update(…) -> Effect<Child.Action> {
    …
  }
}

Note that because this is a method and not an action, it is appropriate to name it after what it does rather than what the user is doing. And because this is a simple method you can call it from anywhere, including the child or parent domains.

For example, in the parent you could do the following:

case .buttonTapped:
  return state.child.update().map(Action.child)

That will run the mutating update method on the child state and return some child effects, which you then need to bundle back up into the parent domain using .map(Action.child).

This style gives you maximum flexibility since you can call child.update() directly anywhere you have access to child state, and it is most performant because you are just invoking a simple method and not sending a whole new action into the system.

[lukeredpath]

If you're calling this method from a parent reducer, you need to make sure you're returning the effect (you'll need to call .map to map the child action to an action in the parent) e.g.:

case .someParentAction:
  return state.child.playCurrent().map(Action.child)

Or, if you're already performing some other effect in the parent:

case .someParentAction:
  let childEffect = state.playCurrent()
  return .merge(
    .run { send in ... },
    childEffect.map(Action.child)
  )

[jerryga]

Hi, lukeredpath, please check the playCurrent() function. In that function, the following code is not called when I set a breakpoint on it.
".play" is an action of the child. In the reducer of the child, ".play" is not triggered.

[lukeredpath]

@jerryga I'm not sure what more I can do to help you here - how are you calling playCurrent() and from where? Is your child reducer composed into the parent reducer?

[kawynfurstoss]

@mbrandonw how would you do this using the @Reducer macro? I get a compiler error when trying to make an extension for Reducer.State when the Reducer struct uses the @Reducer macro

[kevinanderson7]

@kawynfurstoss you would just either move the extension to a separate file or instead of declaring the mutating func as part of an extension, you could put it directly in the Child.State declaration. See the "Circular Reference Errors" section here for more information: https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/reducers#Gotchas

[lukeredpath]

If something has to be run on an actor (any actor) then it needs to be an effect but you should be able to synchronously read the value from your device client in your mutating state function because the TCA store runs on the main thread anyway. 

On March 5, 2023, GitHub ***@***.***> wrote: @mbrandonw <https://github.com/mbrandonw> this breaks down when the dependency within child state's mutating function requires being run in main thread, right? I was thinking of doing this: extension SplitScreen.State { @mainactor mutating func updateOrientation() -> Effect<SplitScreen.Action> { @dependency(\.deviceClient) var deviceClient: DeviceClient orientation = deviceClient.interfaceOrientation return .none } } However, I realize that deviceClient.interfaceOrientation has a dependency on UIApplication (DependencyAdditions' ApplicationDependency actually), whose properties need to be retrieved from main thread. Although the fix for that would be to run it within an Effect closure, that would mean I am now attempting to modify state within a concurrent context, which is the biggest no-no ;)

— Reply to this email directly, view it on GitHub <https://github.com/pointfreeco/swift-composable- architecture/discussions/1952#discussioncomment-5209262>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AAAAEZJTFU2RSSNSIBHBQUTW2T6JLANCNFSM6AAAAAAVLWLZP4>. You are receiving this because you were mentioned.Message ID: <pointfreeco/swift-composable-architecture/repo- ***@***.***>

[acosmicflamingo]

Gotcha. I now see that this error actually has to do with how I designed the dependency. Because interfaceOrientation is being retrieved from UIApplication and that needs to be extracted from the main thread, I must add @mainactor to property like this:

extension DeviceClient {
  public var idiom: UIUserInterfaceIdiom {
    _implementation.idiom
  }

  @MainActor
  public var interfaceOrientation: UIInterfaceOrientation {
    @Dependency(\.application) var application
    return _implementation.interfaceOrientation(application)
  }

That means that in my example, I must add @mainactor here (although it leads to more problems):

extension SplitScreen.State {
  @MainActor
  public mutating func updateOrientation() -> Effect<SplitScreen.Action> {
    @Dependency(\.deviceClient.interfaceOrientation) var interfaceOrientation:
      UIInterfaceOrientation
    orientation = interfaceOrientation
    return .none
  }
}

I found the fix though that works perfectly :)

extension SplitScreen.State {
  public mutating func updateOrientation() -> Effect<SplitScreen.Action> {
    @Dependency(\.deviceClient.interfaceOrientation) var interfaceOrientation: UIInterfaceOrientation
    orientation = interfaceOrientation
    return .none
  }
}

[lukeredpath]

@acosmicflamingo if you're returning a .none effect you don't really need to return anything from this function - it can just be a normal mutating function with no return value.

[acosmicflamingo]

@lukeredpath true. That would certainly remove boilerplate code for the parent reducers making the calls. Thanks for the tip!

[WHuangz88]

In fact, I've just refactored part of our app logic from an older style that used the reducer to implement the complex logic (this was pre-swift concurrency) and requiring the parent domain to fire a child action to start some effect to this approach.

Before, to refresh session data for our logged in user (which required firing off a lot of different API requests) we'd have a high-level reducer to manage all of the effects and state and you'd need to do something like:

Hi @lukeredpath , I m still quite confuse with the solution for this statement, how do you pass the information from parent to the child if the case is like pulling to refresh that only happened in the parent domain but all the children need to have the information in order to update all the dependency inside child reducer?

First, actions should be named after what the user did in the UI, not what you want to do inside the reducer. So the action .didPressButton is clear and concise because the user just did something in the UI. However, .update is opaque and no one unfamiliar with the intricacies of the child domain will know when that action should be sent.

and for what @mbrandonw said, I totally agreed because only the child know what happened to its components, thus calling the action from parent domain doesn't make sense, but it's a different case with pulling to refresh right? where all child domains rely on the parent.

[idelfonsog2]

Insights: Following partially Brandon's suggestion, I was trying to send one of the child actions in this mutating method, but the child state was not changing. So I did the inverse; I added the reducers mutating logic in this update() method and called it from my child reducer state.update().

I also had to update the parent state after calling update()

_ = item.update()
state.items.updateOrAppend(item)

Hope it helps