Not-session scoped dependencies in SessionStageContainer about uikit-swiftui HOT 1 CLOSED

Hey, thanks for the kind words!

How would you envision the consumption of a dependency not-session scoped, even authService to perform logout or any other dependencies that doesn't require AuthToken, in a session-scope flow (so that has access only to the SessionStageContainer?)

In this case, you can add authService to SessionStageContainer. This doesn't have to be the same instance from LoginStageContainer, you can create a new one inside the container's init. As long as services are lightweight (don't own any data) this is perfectly fine.

And how would you combine this locks and keys usage in the ContainerBuilder with the Composition Root implementation in the AppEnvironment of the CountriesSwiftUI MVVM example project?

That project has one default container for dependencies - but certainly can be refactored to have another one unlockable with some params. One nuance is that you'd need to pass along already instantiated Repositories from the default container to the derived one - so the repos should be part of the "key". Configured URLSession (and other data-access level details) don't have to be transferred as they are already isolated inside Repositories.
I wouldn't pass the repositories individually but as part of a struct, so it'd be easier to add more repos later as needed. It doesn't hurt to pass them all - if the services from the derived container end up not using some - no problem, the UI layer won't get any extra access either way.

Another note is that we'd need to introduce a separate Environment key so that SwiftUI could distinguish different containers in the View:

@Environment(\.injected) private var injected: DIContainer

Depending on the structure of the view hierarchy you can make so that derived views will have access to both containers from the Scope 1 and Scope 2, or just to Scope 2.

The views either can omit @Environment(\.injectedScope1) and only reference @Environment(\.injectedScope2). However, this is possible to completely forbid Views referring to previous stage container - for that, its injection should happen in a different branch in view's hierarchy:

var body: some View {
    if let scope2 = scope2Container {
         HomeScreen().environment(\.injectedScope2, scope2)
    } else {
         LoginScreen().environment(\.injectedScope1, scope1)
    }
}

from uikit-swiftui.