Extremely basic question about Dependencies motivation

[kamcma]

Hello!

I have watched with much interest as you have developed the Dependencies library, going back to the reducer protocol series. As ever, the from-first-principles teaching is so great.

But a few times I would catch myself thinking: it seems like they're doing a lot of work to re-implement SwiftUI's Envrionment, but I'm not quite sure what it's buying us beyond Environment. Because Apple does explicitly enable adding values to Environment and overriding environment values, and I wonder if some of the Dependencies functionality could be achieved with Environment extensions.

I theorize the reason is: perhaps Environment cannot be used outside the context of SwiftUI Views, so you lose it as soon as you move logic to TCA reducers or ObservedObjects? But I've actually struggled to find that explicitly confirmed anywhere.

Is that the case, or is there some other fundamental benefit of Dependencies over Environment? (To be clear, I am a big TCA fan and fully intend to use Dependencies, so I am asking not out of skepticism, just trying to understand.)

[mbrandonw]

Hi @kamcma,

It's a good question. The biggest reason why we can't leverage Environment is, as you alluded to, it cannot be used outside a view. Just put this somewhere outside a view to see:

@Environment(\.colorScheme) var colorScheme;
print(colorScheme)

You will get a purple runtime warning letting you know this isn't right:

🟣 Accessing Environment<ColorScheme>'s value outside of being installed on a View. This will always read the default value and will not update.

But, even if that wasn't the case, there would be more reasons to not leverage Environment. All the tools Apple provides to update an environment value are baked directly into views. There is just the view modifier, e.g. environment(\.colorScheme, .dark), but there is no withEnvironmentValue(\.colorScheme, .dark) { ... }. This means we can't run arbitrary closures in an alternated execution context.

But our dependencies library ships that tool, called withDependencies, and on its back other tools can be built, such as in TCA we have the reducer method .dependency(\.apiClient, .mock).

Further, even if Apple shipped withEnvironment { ... }, we still probably wouldn't leverage it because we baked a lot of additional logic into the retrieval of dependencies that Apple/SwiftUI doesn't care about. Such as the concept of live/test/preview dependencies. This will help make sure people do not accidentally use live dependencies in tests, and that's just not a concept that is important for environment values.

Hope that clears things up.

[mbrandonw]

Oh, and another reason… we want this library to build on Linux so that it can be used in server apps. We wouldn't be able to do that using APIs from SwiftUI. 🙂

[kamcma]

Excellent, thank you. I guess I'd never actually tried to run Environment outside a view, so that runtime warning is news to me.