Delegate mechanism in TCA

[JeromeTonnelierOgury]

Hi everyone :-)

I'm struggling with the implementation of a delegate pattern (external to a framework containing the core TCA feature). I d'ont know if it is a design issue or just a lack of knowledge of TCA, but here I am ^^

I'm building a framework that generates some standalone cards to play some Videos. It generates only some cards, not some card list (important, I'll come back to it later)
Here is a simplistic view of such a card :

So to keep it as simple as possible, I have a CardFeature that pilots the card and all the underlying data and mechanism. It makes the call to the API when loading a Video, it displays it, handles callbacks and stuff.
I have a couple of card and all share a common ActionBar (basically it holds the common actions like load and show). So I created a View with a dedicated Reducer and Scope the ActionFeature from the CardFeature when I add the view to the hierarchy. Therefore I can handle the ActionBar.Action inside the CardFeature to load and show Videos. Works great.
For the sake of it, here is what it would look like

struct ActionFeature: Reducer {
   struct State {
      // any necessary data
   }
   enum Action {
      case loadVideoButtonTapped
      case showVideoButtonTapped
      case deleteCardButtonTapped
   }
   var body: ReducerOf<Self> {
      Reduce {state, action in 
         return .none
      }
   }
}

struct ActionBar: View {
   var body: some View {
   WithViewStore(self.store, observe: { $0 }) { viewStore in 
         HStack {
            Button("Load") {
               viewStore.send(.loadVideoButtonTapped)
            }
            Button("Show") {
               viewStore.send(.showVideoButtonTapped)
            }
            Button("Delete") {
               viewStore.send(.deleteCardButtonTapped)
            }
         }
      }
   }
}

struct CardFeature: Reducer {
   struct State {
      // any necessary data
      var actionBar: ActionFeature.State {
         get { ... }
         set { ... }
      }
   }
   enum Action {
      // ...
      case actionBar(ActionFeature.Action)
   }
   var body: ReducerOf<Self> {
      Scope(
         state: \.actionBar,
         action: /Action.actionBar,
         child: { ActionFeature() }
      )
      Reduce {state, action in 
         return .none
      }
   }
}

struct CardBar: View {
   var body: some View {
   WithViewStore(self.store, observe: { $0 }) { viewStore in 
            // ...
            ActionBar(store: self.store.scope(state: \.actionBar, action: { .adBarAction($0) }))
      }
   }
}

Ok so far, everything works fine.
Now, I want to use this framework inside an application, and I can't figure out how to handle the deleteButtonTapped from the AppFeature.
I created a MinaFeature whose only responsability is to handle the cards loaded from the framework and display them into a list. And I created an AppFeature (like the one from the Tour of the Composable Architecture: Domain Modeling episode) that encapsulates a MainFeature.State as its own non optional root State.

I tried to mimic the Path example, but I encountered 2 issues :

1. the MainFeature is not in the path, so I cannot listen to .path(.element(id: _, action: _)
2. Even if I manage to populate the path StackState with an initial value, I don't know how to access the actionBar Feature State.

I guess there are some pretty straightfoward Delegate patterns in TCA, it's just that I don't know them!

Thanks for your help 🙏

[JeromeTonnelierOgury]

Hi!
just FYI, since the Reducer is solely handled by the framework, maybe there would be a way to "wrap" into a parent reducer and handle actions from there, but maybe I'm saying some stupid things 😬

[JeromeTonnelierOgury]

If you allow me, I just comment this post so that it is not forgotten. Any ideas on how to handle delegates external to the TCA framework ? Thanks

[mbrandonw]

Hi @JeromeTonnelierOgury, I'm personally having a hard time wrapping my head around your problem. It would help if you could build a very small, minimal project that demonstrates the problem you are having.

I will say one thing, which is that this pattern you are using for deriving ActionFeature domain from CardFeature domain:

var actionBar: ActionFeature.State {
  get { ... }
  set { ... }
}

…is not going to play nicely with the new observation tools coming to the library soon. This computed property will create a whole new ActionFeature.State every time it is accessed, which means its observation registrar will be cleared out each time.

So you may want to rethink that part a bit.

[JeromeTonnelierOgury]

Thanks for your answer! as soon as I get back from holidays, I will create a small project to illustrate my purpose :-)