Failable + Complex Dependencies

[rhysm94]

Hi all

I'm having a little bit of a problem migrating some of my dependency containers to the new Dependencies types.
Some of the dependencies can (at least in theory) fail to create, and so the static method to create them is marked as throws. The whole app's Environment is then created inside a do/try/catch block, to catch any depdendency failure that might fail and fatalError out of the application.

I guess in my own DependencyKey.liveValue, I could just do:

static let liveValue: SomeDependency = {
  do {
    return try SomeDependency.live()
  } catch {
    fatalError("Couldn't create SomeDependency")
  }
}()

but is there any way that static var liveValue: Value { get } could instead become static var liveValue: Value { get throws }? Or maybe a ThrowingLiveDependency protocol could be introduced? That said, I'm sure this is something that could work...

Perhaps a bigger dilemma is with complex dependencies which can rely on each other.
For example, I have an AuthClient, and our APIClient live dependency relies on the AuthClient for token refresh. What's the best way to go around this? Is it OK to do something like this? Seems like it would work - might be useful to add something like this as an example if it does work correctly

static let liveValue: APIClient = {
  @Dependency(\.authClient) var authClient
  return APIClient.live(authClient: authClient)
}()

Another question is what happens when my live dependency is created with configuration data - i.e. a URL for the database file?
Should I repeat the same pattern as above, registering that URL with a DependencyKey, and using a local @Dependency(\.databaseURL) var url in the static let liveValue: Database = { closure? (Actually, in this case, I think I'd be registering a DatabaseWriter, as I'm using GRDB, but still...)

What's everyone else doing regarding these two use cases?

[mbrandonw]

Hi @rhysm94, I'd be curious how this looked in the pre-@Dependency world. If a dependency failed to initialize did you just not create an environment, and hence not create the root store for your application?

I think in both pre- and post-@Dependency it is best to think of dependencies as a thing that lives forever in the application. It has no lifecycle as a top-level concept and as such as no ability to fail to initialize.

Instead, any notions of lifecycle and failability should be baked into the internals of the dependency rather than the creation of the dependency. For example, a location manager forever lives in the application, even if you haven't started it or are listening for location updates. Then, when a view appears you can start the manager, and when it disappears you can stop the manager.

And in your example, your dependency could have a throwing initialize endpoint to do any initialization work. Then, you could have a parent "bootstrap" feature that initializes all of the dependencies, and if any fail you show an alert, or whatever you need. You can even use enum state to express this:

struct Bootstrap: ReducerProtocol {
  enum State {
    case bootstrapping
    case bootstrapped(App.State)
  }
  enum Action {
    case onLaunch
    case bootstrapResponse(success: Bool)
    case bootstrapped(App.Action)
  }
  @Dependency(\.client) var client

  var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in 
      switch action {
        case .onLaunch:
          return .run { send in 
            try self.client.initializer()
            // Initialize any other dependencies...
            await send(.bootstrapResponse(success: true))
          } catch: { error, send in 
            await send(.bootstrapResponse(success: false))
          }

        case .bootstrapResponse(success: true):
          state = .bootstrapped(App.State())
          return .none

        case .bootstrapResponse(success: false):
          // Do something here... show an alert?
          return .none

        case .bootstrapped:
          return .none
      }
    }

    Scope(state: /State.bootstrapped, action: /Action.bootstrapped) {
      App()
    }
  }
}

And the view would use SwitchStore to switch over the state enum.

---

And then for your second question:

Perhaps a bigger dilemma is with complex dependencies which can rely on each other.

This is something that @stephencelis and I need to explore more, and I hope others share their experience too. As of right now we think using @Dependency from within a dependency is a totally fine and powerful thing to do.

You do have to be mindful of how dependencies can be overridden in an application. For example, in the snippet you posted:

static var liveValue: APIClient {
  @Dependency(\.authClient) var authClient
  return APIClient.live(authClient: authClient)
}

…you are capturing authClient at the moment of first access to apiClient.

(side note: I removed the static let = { ... }() style because as of #1510 we will start caching dependencies when they are accessed)

Now this could work totally fine, but if you have the concept of overriding the auth client in a certain child feature, then this may not work as you expect. Because you are capturing the authClient at the moment of first access of apiClient, you will never get later opportunities to override it.

Instead of passing an authClient to APIClient.live, why not just use @Dependency(\.authClient) whenever you need it in the API client's endpoints? For example:

APIClient(
  // …a bunch of endpoints
  login: { username, password in 
    @Dependency(\.authClient) authClient
    let user = try await // network request
    authClient.login(user)
  },
  logout: {
    @Dependency(\.authClient) authClient
    authClient.logout()
  }
)

This will guarantee that you are using the correct auth client within each endpoint of the API client.

---

Those are just some quick thoughts. I do think there are a lot of really fun and interesting things left to explore in dependencies, and hope everyone shares what they find!

[rhysm94]

Wow, thank you for getting back to me with such a detailed answer so quickly!

On the first point, yes - if, say, our DatabaseManager failed to initialise, we currently fatalError out of the whole application.
Due to SwiftUI's inability to present screens stacked in the way we need, we moved back from the SwiftUI lifecycle to the SceneDelegate lifecycle, so we create the AppEnvironment and Store in the SceneDelegate's initialiser - not 100% sure it's the right place, as we've seen some weird crashes when exiting the app, but otherwise it seems to have worked fine.

final class SceneDelegate: UIResponder, UIWindowSceneDelegate {
  private let store: Store<AppState, AppAction>
  var keyWindow: UIWindow?

  override init() {
    do {
      let authClient = try AuthClient.live()
      self.store = Store(
        initialState: AppState(),
        reducer: .app,
        environment: AppEnvironment(
          authClient: authClient,
          apiClient: .live(authClient: authClient)
          ... // other dependencies, some of which are also throwing
        )
    } catch {
      fatalError("Unable to initialise required dependencies")
    }

    super.init()
  }

  func scene(
    _ scene: UIScene,
    willConnectTo session: UISceneSession,
    options connectionOptions: UIScene.ConnectionOptions
  ) { ... }
}

In moving a couple of these throwing to @Dependency, I've at least pushed the do/try/catch dance into the liveValue getter, ultimately retaining the same behaviour as before, but allowing me to remove the do/try/catch from the SceneDelegate.init.
It's definitely not as ideal as being able to "bootstrap" the app, like in your example though. Something to consider when I get onto the next phase of work in this project 😄 We already have a Splash Screen view, for getting some data from the API before the rest of the app - seems like the exact place that this bootstrapping would make sense to live... 🤔

---

I really like the even more local use of @Dependency(\.authClient) var authClient inside each method, and simplifies things even further. Thanks for making me more aware of when it's being captured and wouldn't be updated in child features!

---

I'll proceed for now with do/try/catch in the liveValue, and consider in the future how best to make dependencies more "bootstrappable" like you suggest.

Thanks again! Really appreciate the quick response!

[Alex293]

If you fatalError() anyways why don't you try! MyDependency() without the try catch dance ?

[rhysm94]

If you fatalError() anyways why don't you try! MyDependency() without the try catch dance ?

Yeah, absolutely could do that. But, I do like the idea of being able to throw my own fatalError reason, especially if I was to introduce some sort of (non-failing, of course!) logging dependency, and reference it using @Dependency from within the catch case, to log why that dependency failed to initialise.