How to handle session-based dependencies?

[zachwaugh]

I'm starting to adopt the library, but I'm still confused about the correct way to handle session-based dependencies that don't have a reasonable default/static liveValue and that will need to change over time? For example, if you have a User type and want a currentUser dependency, what would you use as liveValue, and how do you update that value on sign in/out? I'm assuming here that we don't want it to be an optional and only screens that require authentication will reference @Dependency(\.currentUser) var currentUser.

Can you provide some examples for that use case? I couldn't find any clear answers in the docs or the discussions. Thanks!

[WedgeSparda]

I'm facing the same issue. When a logged user logs out or switchs to a different account, we recreate our dependencies tree and recreate all needed objects. Using @dependency is not working on that scenario since liveValue is created once.

I'm guessing the answer is not, but is there any way to force recreation of this type of dependencies? Maybe that's out of the scope of this library.

[mbrandonw]

Sorry, we must have missed this when it first came in.

I don't think there is any way to have a currentUser dependency that is non-nil and only accessible when the user is "logged in". That kind of static typing information is just not available to the compiler, and it must be done at runtime. There are some DI libraries that provide tools to approximate this concept with various incantations of containers, but at the end of the day it's all runtime and can be done incorrectly.

In isowords we have a client that exposes session information, but of course it is optional:

struct APIClient {
  public var authenticate: @Sendable (ServerRoute.AuthenticateRequest) async throws -> CurrentPlayerEnvelope
  public var currentPlayer: @Sendable () -> CurrentPlayerEnvelope?
  public var logout: @Sendable () async -> Void
  public var refreshCurrentPlayer: @Sendable () async throws -> CurrentPlayerEnvelope
  // ...
}

It works well enough for us.

Using @​dependency is not working on that scenario since liveValue is created once.

In the situation of a user switch or logout I imagine you would recreate the base view of the application. Just seems like a good way to reset everything, and in that can you can do:

withDependencies {
  $0 = .live
  $0...
} operation: {
  AppModel()
}

…to reset everything back to the default live implementations, as well as any further customizations you want to make.

However, due to the design of the library (in particular, using @TaskLocal under the hood), you will need to make sure to be strict with yourself and propagate dependencies to child models. I recommend reading these two articles for more information:

• Overriding dependencies
• Dependency lifetimes

[alexito4]

This is related to the discussion here pointfreeco/swift-composable-architecture#1775 maybe it helps ^^

[zachwaugh]

Thanks for the feedback @mbrandonw! Sorry for the delay, just getting back to this project now after working on something else. So removing the requirement that the dependency returns a non-nil value, and assuming it's modeled as an optional, I'm still unsure where is the appropriate place to do this using TCA:

In the situation of a user switch or logout I imagine you would recreate the base view of the application. Just seems like a good way to reset everything

Take a simplified version of the TicTacToe example:

  public var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      switch action {
      case let .login(.loginResponse(.success))
        state = .newGame(NewGame.State())
        return .none

      case .login:
        return .none

      case .newGame(.logoutButtonTapped):
        state = .login(Login.State())
        return .none

      case .newGame:
        return .none
      }
    }
    .ifCaseLet(/State.login, action: /Action.login) {
      Login()
    }
    .ifCaseLet(/State.newGame, action: /Action.newGame) {
      NewGame()
    }
  }

Where would you handle updating the dependency in a case like this? Feels like we'd want to do it when we're changing the state between login and newGame, but we can't update dependencies there. What I'm now doing is something approximately like this:

    .ifCaseLet(/State.login, action: /Action.login) {
       Login()
          .dependency(\.currentUser, nil)
    }
    .ifCaseLet(/State.newGame, action: /Action.newGame) {
      @Dependency(\.keychain) var keychain
      NewGame()
         .dependency(\.currentUser, try? keychain.get(.currentUser)))
    }

It seems to work, but I'm not sure it's correct. The docs for transformDependency mention this warning:

The trailing closure of transformDependency(_:transform:) is called for every action sent to the reducer, and so you can expect it to be called many times in an application’s lifecycle. This means you should typically not create dependencies in the closure as that will cause a new dependency to be created everytime an action is sent.

I noticed the code above behaves the same, Login() and NewGame() reducers are recreated on every single action sent in the app, recreating both their dependencies every time, so I feel like I'm missing something about the right way to approach this.

[zachwaugh]

My alternate solution is just to make a Session reference type and directly mutate it. I initially discounted this approach since it felt wrong to have this globally mutable state anyone could change, but I guess it's no different than mutating the Keychain or UserDefaults or a database via a dependency, and it's simpler all around.

@Dependency(\.session) var session

public var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      switch action {
      case let .login(.loginResponse(.success(let user))):
        session.currentUser = user
        state = .newGame(NewGame.State())
        return .none

      case .login:
        return .none

      case .newGame(.logoutButtonTapped):
        session.currentUser = nil
        state = .login(Login.State())
        return .none

      case .newGame:
        return .none
      }
    }
    .ifCaseLet(/State.login, action: /Action.login) {
      Login()
    }
    .ifCaseLet(/State.newGame, action: /Action.newGame) {
      NewGame()
    }
  }