Communicating to outside the TCA

[alexito4]

Hello there!

Up until now I've always used the TCA in an entire app so I didn't find myself with these questions yet. But now we started using "feature packages" (pointfree style ^^) and integrating them into an existing codebase. So I'm finding myself wondering how to communicate those domains with the outside world, aka the main app.

So our app (uikit, mvvm, coordinators, etc...) reaches a point that wants to open a TCA feature. We create the store, the view, put it in a hosting controller and go! This is all fine. But then we need the TCA feature to tell the app to perform some actions (close this flow, navigate somewhere else, etc...).

Two conrecte scenarios are:

• The TCA feature has a list of notifications, when user taps on one it needs to tell the app to navigate to the screen that the notification belongs to. We do this via a route/NavigationItem and a coordinator hierarchy. Question is, how we go from the TCA feature to the outisde world of the app.
• Another TCA feature has a screen that wants to close its own flow. If this was part of the navigation (a button in the navigation bar for example) we could imagine doing that from the outside, keeping it outside SwiftUI/TCA. But in this case the button that wants to trigger the close flow is deep in the view hierarchy and totally belongs to the TCA feature.

We've gone trough multiple approaches and I would like to know others opinion on this:

1. State driven communication

This was my first approach. Just put some state in your feature domain, and let the "app" code listen to it with the ViewStore.publisher.

Something like

FeatureView(store)
.onReceive(ViewStore(notificationsStore).publisher) { state in
   // check for your specific state change and do something
}

My problems with this approach are:

• you need to check if the state you care about actually changed
• you probably want to send an action back to reset that state and things get complicated quite quickly
• you are polluting the domain of that feature with state that doesn't belong there. it belongs into the parent, which in this case is the main app.

The last point is something that bothers me a lot. This and the fact that I feel like I"m using state changes as fake "events".

2. Callbacks in the environment

Another suggested approach is to just pass callbacks in the environment and let the feature domain use that.

My issues here are:

• callbacks in the environment feel somehow... not appropriate. This is probably a dumb personal taste but I usually prefer to put in the environment actual real dependencies (a.k.a. objects). That said is probably fine to put closures in there, at the end is still a dependency.
• The fact that the feature domain will still have to "know" about this parent domain and perform calls to the env. when it shouldn't be its responsibility.

3. Listen for actions

Since what we want is to do something when an event happens, it would make sense to listen to actions and perform the changes in the app needed. The issue is that the Store/ViewStore doesn't expose a way to listen for actions, only state changes. So the way to do this is to combine the feature domain reducer with an on the fly reducer in the app to listen to actions.

let store = Store(
        initialState: ...,
        reducer: featureReducer
            }.combined(with: .init({ _, action, _ in
                // switch on the action that you want to listen to and run some code
                case .someAction:
                      runSomeCallback()
                      return .none
            }))
...

The problems I see are:

• that reducer feels dirty. it calls functions, callbacks, etc to perform side effects without going trough the TCA. this makes sense tho, since those sideeffects are not in "this" TCA world.
• this could pollute the idea of TCA to the team making them feel like running side effects like this is ok. this could be mitigated with a custom extension method that makes clear the specific purpose of this technique.

Conclusion

When I'm trying to find a solution for this the question I ask myself is "How would this work if the app was already using full TCA". In that case you wouldn't pollute your feature with state that belongs to the parent (so no option 1), and you wouldn't use the environment to do things on the parent (so no option 2). You would actually make the parent have its own state and listen for actions from the children (option 3).

So option 3 is the best one in my eyes. And if the Store already provided a publisher for actions I wouldn't even be doubting myself 😂

To finish this text with specific questions:

• Do you think that using the reducer like that is "kind of okey" or ir just a NONO?
• Do you think I'm miss-judging the other options and actually 1 or 2 are better?
• Am I approaching this from the wrong angle and there is another solution I'm not seeing?

Thanks! 🤗

[AlexisQapa]

Just as a data point while migrating an app I used the reducer (option 3) approach and it worked well thought it's quite ugly.

[tgrapperon]

Great topic! I personally used a mix of 2 and 3: I passed a PassthroughSubject<Action, Never> to the Environment, and re-emitted to the subject a subset of relevant actions. It's then easy to listen to the subject from MVC and react accordingly.

Approach 3 is the neatest in my opinion. This higher-order reducer is not in the TCA's domain in my mind. It's a kind of adapter between MVC and TCA. Furthermore, the subset of actions it will emit to the subject can be injected in the form of a predicate block (Action) -> Bool when setting the store (using only some filtering), so I won't say the higher-order reducer has intrinsic knowledge of its parent!

In some way, the higher-order reducer acts like a kind of private and type-safe notification center.

For example, with something like:

public extension Reducer {
  func relay(
    actionPredicate: @escaping (Action) -> Bool,
    destination: PassthroughSubject<Action, Never>
  ) -> Self {
    combined(with: .init { _, action, _ in
      if actionPredicate(action) {
        return .fireAndForget {
          destination.send(action)
        }
      }
      return .none
    }
    )
  }
}

We can see that we're still returning a Reducer<State, Action, Environment>. The higher-order reducer only produces side effects we want to listen to (and we need to produce side effects if we want to communicate with the outside world). The original store is totally preserved (state, environment, and logic), and unaware of what's going on.

Of course, for this to work, you need to be able to make decisions from the actions only. If the state is needed to make decisions, maybe this can be expanded to a pseudo-predicate (State, Action) -> Notification? (with PassthroughSubject<Notification, Never>), where Notification is an enum used in the same fashion as one uses Actions to describe events in TCA, but sent blindly to the subject instead of a reducer.

For example:

public extension Reducer {
  func notify<Notification>(
    notifications: @escaping (State, Action) -> Notification?,
    destination: PassthroughSubject<Notification, Never>
  ) -> Self {
    combined(with: .init { state, action, _ in
      if let notification = notifications(state, action) {
        return .fireAndForget {
          destination.send(notification)
        }
      }
      return .none
    }
    )
  }
}

You can see this as a pseudo-pullback of the reducer in the MVC's world.
I'm sure this can be better formalized, though!

[Edit: Refactored the higher-order reducers as methods of the original reducer instead of free functions]

[kamcma]

Some really neat ideas here, thanks for sharing.

I haven't been able to put all the pieces together, but I have wondered if one could encapsulate a TCA feature such that it could be initialized with a vanilla SwiftUI Binding. Obviously, that defers some important API design questions for dependencies, but still, interesting for the simple case of just synchronizing state. Maybe an extension on Binding producing a Store, or something? Could be useful for some low-level SwiftUI components, eg the DocumentGroup scene, where the scene wants to abstract away all the file effect stuff and just hand you a binding of your document.