New child state from a descendant state via action vs from state

[kodok1988]

I use optional paths + route pattern in my project.

Navigation paths are A-B-C-D and A-E-F-C-G.
C is common state and view(Agreement) and used in many paths.

D and G need many state to make a request to a server.
Necessary information comes from A, but to generate D and G in reducerC, C need to have unnecessary state. (B and E too)

in reducerC )
case .goD:
state.route = .d(DState(
param1: state.param1,
param2, state.param2
))

So CState goes messy over time.

To avoid this, I captured the action from Ancestor. and pass parameter via action.

in reducerA )
case .b(.c(.goD)):
return Effect(value: .b(.c(.goDFromAncestor(state.param1, state.param2)):

in reducerC)
case .goDFromAncestore(param1, param2)):
state.route = .d(DState(
param1: param1,
param2: param2
))

By using the pattern, CState can be keep clearly.
Is it right approach?
This patters can only work in TCA, not a vanilla SwiftUI. So I confused.

[tgrapperon]

Hello!
The fact that your domain C can navigate to two different destinations means that:

• The domain C must me configurable/reusable, or
• The domain C doesn't need to handle the navigation part and can maybe be seen as a bystander/parallel domain.

The first case correspond roughly to your solution, where you pass the information through C. As a result, C is full of generics and a little inconvenient to handle. You need to find a way to encode the navigation destination (its scoping/pullback) as some generic payload you pass to C. Your C reducer's is a function of this payload, as well as its State, Action and View. As you see, you need to either hardcode the possibilities, or build a fully generic component. There are probably ways to formalize this, and I'll experiment.

The other option is to try to see if you can extract C as a parallel domain that doesn't interact non-trivially with its children. If this is possible, you can maybe define a shell reusable View with a closure for some unconstrained ContentView. Something like

struct CView<Content: View>: View {
  let content: Content
  let store: Store<C>
  init(store: Store<C>, @ViewBuilder () -> Content) {
    self.store = store
    self.content = content()
  }
  var body: some View {
    VStack {
      WithViewStore(store) { viewStore in
        Text(store.localizedAgreement)
        Button { 
		  viewStore.send(.readMore) } 
        } label: {
          Text("Read more…")
        }
      }
      content
    }
  }
}

Coming from B, you build a composite domain C_B where C and what follows it are stored and handled separately. For example

struct C_B {
  var c: C
  var d: D?
}

In C_B's reducer, you pullback C, and separately D, like you would do with sibling domains. In B, you pullback C_B only.
In C_B's view, you can then write something in this spirit:

struct C_BView: View {
  let store: Store<C_B>
  var body: some View {
    CView(store.scope(C)) {
      WithViewStore(store) { viewStore in
        NavigationLink(isActive: viewStore.dIsNotNilBinding) { 
          IfLetStore(store.scope(D)) { dStore in
            DView(store: dStore)
          } 
        }
        label: {
          Text("Agree and go to D")
        }
      }
    }
  }
}

If C is an agreement, it is likely that it doesn't need to have knowledge of its children to perform its work. Creating a composite domain with C and something else is quite short and straightforward. If C is really reused in many, many places, you can maybe think about adapting this approach to ressemble to the 04-HigherOrderReducers-ReusableFavoriting case study. I'm afraid a general solution to this general problem will be either too simple to handle the most common situations while providing something worthy, or too complex to wield relatively to some ad-hoc implementation.

You can also maybe use the Environment to pass state information through domains a little more conveniently if that would work in your case.