Calling child behaviour from parent (from TCA 1.25 onwards)

[lukeredpath]

This is effectively a follow-on from the previously answered (but now outdated) discussion here #1952.

I wanted to start the discussion to see what exposing child behaviour to parent features looks like now and in the future.

The previous advice was that sending a child action from a parent reducer as a means of sharing behaviour (i.e. using actions like a function call) was an anti-pattern and could also have performance implications. There were generally two approaches you could take instead:

• Expose an API from your child feature - this could be a mutable function on the state if you just want to encapsulate a state mutation, a static helper or free function that returns a child effect, or a combination of both - a mutable state function that returns an effect.
• Send a child action by invoking the child reducer directly and avoiding the store roundtrip.

I believe the performance implications are less of a concern these days but my personal opinion is using actions in this way still feels wrong...

Opinions aside, as of 1.25, the above approaches are deprecated and will not even be possible in TCA2:

• Calling .reduce is deprecated, which rules out the second approach above.
• The first approach relied on you being able to call .map on the returned child effect in order to map its child actions back to a parent action on the parent reducer. This is also deprecated and won't be possible in future.

There remains two options if you need either a state mutation or just a re-usable effect:

• You can still encapsulate complex state mutations as a mutable state function and call them from the parent reducer.
• You can expose side-effect behaviour as static or free async functions that you can call from a parent effect.

However as far as I can tell, the only option if you need to have both to happen together is either:

• Define both of the above and make sure you call the state mutation in the parent reducer and then call the async function from an effect. Error-prone as you have no static guarantees that both things are happening and are reliant on good test coverage.
• Going back to the pattern of sending a child action and handling both the state mutation and effect in the child reducer.

As I'm working through the deprecations in our app I'm left with the view that sending a child action from the parent is now the only really viable solution to this problem. I'm curious if anyone else can think of a better way, or if there might be a better way to handle this in TCA 2.

[mbrandonw]

I'm curious if anyone else can think of a better way, or if there might be a better way to handle this in TCA 2.

TCA2 will have quite a few new features that allow for better child-to-parent and parent-to-child communication. What you are asking for in particular is parent-to-child, and one tool we will be shipping is called "triggers". This lets a child feature hold onto an object that can be "triggered" from the outside, and when triggered it will execute logic in your child feature.

As an example, suppose a child feature has the need to refresh data, which can be done with the feature first appears or when a button is tapped, but also you want the ability for a parent to tell the child to refresh. The child can represent this like so:

@Feature struct Child {
  struct State {
    @Trigger var refresh
    // Other properties
  }
  …
  var body: some Feature {
    Update { state, action in 
      switch action {
      case .refreshButtonTapped:
        state.refresh()
      }
    }
    .onMount { state in 
      state.refresh()
    }
    .onChange(of: store.refresh) { _, state in 
      // Do work to refresh state
    }
  }
}

Here we are showing off triggers in 3 ways:

• When the user takes an action (refreshButtonTapped) we can trigger the refresh
• When the feature first "mounts" we can trigger the refresh
• When the refresh is triggered (via onChange(of:)) we do the actual refresh work

So internally the child feature can "trigger" refresh to kick off async work and get fresh data for the feature.

But the parent feature can do the same:

@Feature struct Parent {
  struct State {
    var child = Child.State()
  }
  …
  var body: some Feature {
    Update { state, action in 
      switch action {
      case .tap:
        state.child.refresh()
      …
      }
    }
  }
}

So at any point the parent feature needs to tell the child to do its work it can just hit refresh(). And the best part is that everything will be completely synchronous in tests and 100% testable:

await store.send(.tap) {
  // Assert on all state changes from 'Parent' as well as all
  // states changes from 'Child.onChange'
}

Everything is still in flight for TCA2 at this moment, so things may change a bit, but so far this is a tool we were able to build and seems like it solves the problem nicely.