Integration in TCA

[Mika5652]

Hello guys,

I want to use this new navigation logic in ComposableArchitecture, but I'm stuck on how to correctly implementing. Because there is used pullbacks and then in view functions like store.scope(state:action:), so I don't know, how to glue that together. I even saw whole series of this new navigation logic in https://www.pointfree.co/collections/swiftui/navigation, but there you don't build that on top of TCA, I think.

Did you consider some example of how to use in TCA please?

Thank you for response!

[kamcma]

Having pondered this a bit myself, my thought is that you would not use this exact library in a TCA application. Part of what this library does is create Bindings, and they are of the vanilla-SwiftUI variety that directly mutate their wrapped value, not of the TCA variety that send actions rather than mutating values directly.

The PF guys have said that when they cover navigation in TCA, the principles will be the same, but the actual APIs "tools involved" will be different (which I interpret to mean APIs that are not these APIs, but that is just a guess):

https://twitter.com/pointfreeco/status/1460696031448821764

If my intuition about this is wrong, I am happy to be corrected.

[stephencelis]

That's right! 😄 While you could use swiftui-navigation in TCA, its focus on bindings make it far less useful. We'll get to building some better TCA nav tools soon, though!

[Mika5652]

Ok, thanks for reply. I'm looking forward to update for TCA 😀

[lukeredpath]

I put together a small demo showing how you might use TCA to model navigation and routing in a similar way to the recent navigation series on Pointfree here: https://github.com/lukeredpath/tca-navigation-demo

As you can see though and as mentioned above, the problem is that this library is very focused on bindings. Whilst bindings are used in TCA too (and you can generate them from a ViewStore), there's a difference in the way you scope down to child domains in TCA vs vanilla SwiftUI (e.g. with view models).

With a view model, you can have a binding that produces a value (e.g. the child domain state/value) wrapped inside some route and this library provides the tools to work with these - when creating your child views you can pass this child state into a new child view model and pass this in to the child view.

With TCA though, your domain and any child domains need to stay encapsulated by the store - working with child domains in TCA means using .scope to produce a child store that you can pass into your child view. This library will not help you with that.

What we really need are tools like IfLetStore, ForEachStore etc. that produce child stores from some parent domain. If you think about the "grand unified theory of SwiftUI navigation" discussed in episode 166, all navigation has the following shape:

(Binding<E?>, CasePath<E, C>, (Binding<C>) -> some View) -> some View

The TCA version of this would probably look something like this:

(Store<E?, A1>, CasePath<E, C>, (A2) -> A1, (Store<C, A2>) -> some View) -> some View

Note that this also needs to account for local actions, not just local state, which is why it needs to have the action transformation (A2 -> A1). Based on this, we might imagine a the following state:

struct ParentDomainState {
  var route: Route

  struct Route {
    case child(ChildDomainState)
  }
}

enum ParentDomainAction {
  case child(ChildDomainAction)
}

And a hypothetical .sheet API based on the above shape:

// In this example, let store: Store<ParentDomainState, ParentDomainAction>
.sheet(
  unwrapping: store.scope(state: \.route),
  case: /ParentDomainState.Route.child,
  action: ParentDomainAction.child
) { childStore in // childStore: Store<ChildDomainState, ChildDomainAction>
  ChildView(store: childStore)
}

Of course, for completeness, we'd probably also want some additional helpers to make it easier to integrate the child domains into the parent domains in the reducer.