[Experiment] Dynamic domain embedding

[tgrapperon]

Hey!
While working on modularized projects, there are situations where some module A needs to embed a domain living in a module B which itself need to present a domain from the module A. The straightforward solution is to bring both features into the same module, but this is not scalable at all, and one may end with all features living in the same module.

One solution to this kind of problem is brought by NavigationStack, but:

• It is limited to navigation destinations
• It is not yet convenient to use in TCA

So I wondered what would it take to embed fully erased domains, so we can for example dynamically embed A into B. I've managed to implement something that is relatively general, relatively usable and relatively testable. I've pushed results in a branch here.

In this example, I'm injecting a full Animations domain into the TwoCounters case study. In this case, they both live in the same module, but it would work the same if they'd live in different ones.

DynamicDomains are keyed by an arbitrary ID (and Hashable or a Type). In what follows, the integer 42 is used a key for the Animations dynamic domain.

In TwoCounters, we make some room for the dynamic domain's state:

struct TwoCounters {
  struct State {
    …
    @DynamicState(id: 42) var animation
  }
}

Similarly, we declare a case for this domain

enum Action {
  …
  case animation(DynamicAction)
}

We can then scope the dynamic domain in body:

var body: some ReducerProtocolOf<TwoCounters> {
  …
  Scope(state: \.animation, action: /Action.animation) {
    DynamicReducer()
  }
}

Now, in TwoCounter's view, we make room for the dynamic domain view:

HStack {
  …
}
DynamicDomainView(
  store.scope(
    state: \.$animation,
    action: TwoCounters.Action.animation
  )
)

And that's it for TwoCounters. As you can see, we didn't refer to the Animations domain at all.

Now, somewhere upstream in the view hierarchy (typically in a parent module that knows both A and B), we bind a domain to 42 using a view modifier:

VStack {
  …
}
.dynamicDomain(
  id: 42,
  reducer: Animations(),
  initialState: Animations.State(),
  view: AnimationsView.init(store:)
)

So we provide the reducer, an initial state and a view. All these values will be surfaced appropriately in TwoCounters

Now, if we want to communicate between the two domains, we can for example define a general protocol that allows to conveniently extract or set values from the dynamic domain. In the sample from the branch, I'm using a simple protocol that allows to assign each coordinate of the circle's center from the animation domain to both counter counts from TwoCounters, and reciprocally.

Finally, this dynamic embedding can be tested. We simply need to register the dynamic domain early with the dynamicDomains dependency:

let store = TestStore(
  initialState: .init(),
  reducer: TwoCounters(),
  prepareDependencies: {
    $0.dynamicDomains.register(
      id: 42,
      reducer: Animations(),
      initialState: Animations.State(),
      view: AnimationsView.init(store:)
    )
  }
)

We can then perform tests more or less as usual. Equatability is inferred using existentials like it's done for TaskResult.

I guess there are many ways to improve this, but it can probably already help in a few situations. Please let me know what you think!

[evjand]

This is really interesting. We currently have a large UIKit project with a lot of cross feature navigation and circular navigation. So far we have merged features when necessary. Something like this would be highly beneficial for us, especially as we migrate to SwiftUI and NavigationStack in the future.