Same dependency in multiple places

[GreatApe]

Hi, I'm using the protocols-beta version and it's working great, but I have a usage question. When it comes to state, if there is some state that is used by two different features we would put it in their common ancestor, but what about the analogous situation for dependencies? Would it be considered a code smell to access the same dependency (say a data repo or audio player) from different sibling reducers?

I mean presumably we have written the dependencies so that they can handle being called from different places, but it feels a little bit like we turn them into global singletons, and the parent will still be informed that we, say, pressed the play button down in a child reducer, so perhaps it's ok to run the audioPlayer.play task from the child directly?

[mbrandonw]

While it may sound scary at first, dependencies really are like "global" singletons, but just without all the traditional baggage associated with singletons (such as coupling and last of testability). After all, a dependency's whole purpose is to talk to the outside world, and there is only one outside world.

This is why dependencies aren't designed with a specific feature in mind, but rather designed only as communicating with the outside world. The environments from the old-style reducers were designed with a feature in mind, but also they just held onto dependencies that were passed through each layer of the application. They didn't have any logic or behavior of their own.

So, we think it's definitely OK for a child feature to hit play on the audioPlayer dependency.

[GreatApe]

Thanks a lot for the reply. But then I wonder, can I take it one step further? A common situation that I haven't found a nice TCA solution for yet is this:

• I have a local context, like a menu, an alert, often something ephemeral
• It needs some state from the outside
• It has some internal logic, and may want to call some dependency
• It does NOT need to pass anything back to the parent, neither actions nor state

As far as I can tell, the two main tools in TCA for composition is scoped child reducers along with scoped child stores, and simply using only a scoped child store. In the first case we have:

A. The child state tracks parent state
B. And vice versa
C. Child actions are passed up to the parent
D. (Presumably?) child actions can be sent to the parent viewStore
E. The child reducer can react to actions, and use child state in doing so

When just scoping the store, we only get:

A. The child state tracks parent state
C. Child actions are passed up to the parent

But in the situation I describe we really only need A and E, so we could go with the scoped reducer option, but then we need to create a strange computed property on the parent that gets the child state but `sets nothing. So I wonder, given that it's totally fine to use dependencies in several places (even relying on the fact that it's the same copy everywhere), would it make sense to do something like this?

.contextMenu {
  if let track = viewStore.track {
    let initialState = PlayMenu.State(track: track.id)
    let playMenuStore = StoreOf<PlayMenu>(initialState: initialState, reducer: PlayMenu())
    PlayMenuView(store: playMenuStore)
  }
}

struct PlayMenu: ReducerProtocol {
  @Dependency(\.audioPlayer) var audioPlayer
  // ...
}

struct PlayMenuView: View {
    let store: StoreOf<PlayMenu>
    // ...
}

[mbrandonw]

I think the situation you have described, and the code you have sketched out, is totally fine. If truly the "play menu" feature is fully isolated, and the parent does not need to know about anything going on inside PlayMenuView (besides however it interacts with the dependency), then splitting off that extra store will probably work out.

There is one caveat to be mindful of though. By creating a whole new store you are exiting yourself out of the "single entry point" that the rest of your application runs on. This means that any customizations made to dependencies after the initial configuration will be lost in the PlayMenu feature. Essentially, the PlayMenu reducer will go back to seeing the liveValue versions of all the dependencies.

This may not be a problem for you if you are not customizing dependencies after launch, but if you are, then you have to do a little bit of work to capture that:

@Dependency(\.self) var dependencies

…

let playMenuStore = StoreOf<PlayMenu>(
  initialState: initialState, 
  reducer: PlayMenu()
    .dependency(\.self, self.dependencies)
)

[GreatApe]

Ah, that's good to know, thanks again!