Optional/Dynamic dependencies

[alexanderwe]

Hey @stephencelis, @mbrandonw,

at first, great work of making Dependencies standalone and offering as package, really nice !

I didn't implement a feature with swift-dependencies yet, but I hope it's fine to ask a question anyway. I was wondering if it's possible to dynamically register dependencies at runtime. So for example it could be that I do not always to have a debug service attached in my app. I am thinking of having such an instance only present in debug builds and not in release builds. Therefore I would at runtime decide whether I want to register this kind of dependency or not and then provide this service as an optional dependency to my models.
Of course I would not get compile time safety then since my dependency could be there or not, depending on some external event.

Is something like this possible ?

[Kondamon]

Yes, this is possible.

Have a look here where you have two different options to setup the UUID generator. It can return a constant or an incrementing number for testing purposes or a regular UUID.

You can easily change the implementation of your dependency key by assigning it another value (or function) like this.

[mbrandonw]

Hi @alexanderwe, in addition to what @Kondamon mentioned, another option is to put logic directly in the liveValue of the dependency to decide which one to serve up:

static var liveValue: DependencyClient {
  #if DEBUG
    ...
  #else   
    ...
  #endif 
}

I personally think that's a bit dangerous because it means you should run your test in both DEBUG and RELEASE to get real coverage on how your application works.

It might help if you can explain a bit more of what you are trying to accomplish in concrete terms. Maybe even with some code.

[alexanderwe]

Thanks a lot for all of your answers and suggestions, highly appreciated !

Let me maybe write some pseudocode what I have in my mind right now.

So the idea is that maybe some of my dependencies are not available at runtime for a specific environment. So it could be that there is a debug service which offers a debug menu in in-house builds but for app store distribution this is not in place.

So I would expected the following dependency:

@Dependency(\.debugService): DebugService?

Meaning I don't know whether I have a debug service available or not at compile time. Which in theory yes, would mean that the app is changing it behaviour from DEBUG to RELEASE builds. I am just wondering if this approach is valid or even good ? @mbrandonw You have a valid point here that it would mean that the application needs two testing rounds.

Maybe also on technical level, is it supported to have a Optional<DependencyClient> type ? Or that the app at runtime removes instances from the dependency registry ?

[Kondamon]

@alexanderwe, for Optionals you need a simple wrapper. Then you could access it via:

@Dependency(\.debugService.wrapped) var service

It‘s pretty common to have different menus for DEBUG, BETA or RELEASE builds. You need compiler flags to distinguish between them.

The design decision, in my opinion, mainly depends on what tests you want to be carried out. You could create another ConfigurationDependencyKey (for switching between release/debug with compiler flags as @mbrandonw mentioned above) and use it in your DebugService instead of using compiler flags directly in DebugService. So you could easily test DebugService implementations.