A mechanism to access @Environment values in the reducer

[kamcma]

Apple has added a few useful side effects to SwiftUI's EnvironmentValues. In particular, I am interested in @Environment(\.webAuthenticationSession), added in iOS 16.4, a super-clean SwiftUI, async wrapper around ASWebAuthenticationSession.

My issue is I want to invoke this environment value not directly from UI event, but after executing some logic in the reducer. I've previously explored wrapping ASWebAuthenticationSession as a dependency directly, signaling out to the view (#1683) and of course swift-dependencies-additions.

But I'm always looking to slim down and reduce dependencies and maintained code, and I had a small lightbulb that maybe I could do this with swift-dependencies directly, and I just wanted to see if there's anything inadvisable about the following.

Step 1, declare an unimplemented dependency that matches the Environment value's API:

import AuthenticationServices
import Dependencies

struct AuthenticateEffect: Sendable {
  let handler: @Sendable (URL, String, WebAuthenticationSession.BrowserSession?) async throws -> URL

  func callAsFunction(
    using url: URL,
    callbackURLScheme: String,
    preferredBrowserSession: WebAuthenticationSession.BrowserSession? = nil
  ) async throws -> URL {
    try await self.handler(url, callbackURLScheme, preferredBrowserSession)
  }
}

enum AuthenticateKey: TestDependencyKey {
  static let testValue = AuthenticateEffect { _, _, _ in unimplemented() }
}

extension DependencyValues {
  var authenticate: AuthenticateEffect {
    get { self[AuthenticateKey.self] }
    set { self[AuthenticateKey.self] = newValue }
  }
}

Step 2, override the dependency from the Environment value in the view's initializer:

import ComposableArchitecture
import SwiftUI

struct AuthenticationHostingView: View {
  let store: StoreOf<AuthenticationHostingFeature>

  public init(store: StoreOf<AuthenticationHostingFeature>) {
    @Environment(\.webAuthenticationSession) var session
    // Is this 👇 even valid to do?
    self.store = withDependencies {
      $0.authenticate = AuthenticateEffect { try await session.authenticate(using: $0, callbackURLScheme: $1, preferredBrowserSession: $2) }
    } operation: {
      store
    }
  }

  var body: some View {
    WithViewStore(self.store, observe: { $0 }) { viewStore in
      Button("Authenticate") { viewStore.send(.authenticateButtonTapped) }
    }
  }
}

Step 3, use the dependency value in the reducer:

import ComposableArchitecture

struct AuthenticationHostingFeature: Reducer {
  struct State: Equatable {

  }

  enum Action {
    case authenticateButtonTapped
  }

  @Dependency(\.authenticate) var authenticate

  var body: some ReducerOf<Self> {
    Reduce { state, action in
      switch action {
      case .authenticateButtonTapped:
        // logic
        return .run { send in
          let url = try await self.authenticate(using: /* ... */, callbackURLScheme: /* ... */)
          // ...
        }
      }
    }
  }
}

The idea/questionable bit is setting the dependency from the Environment value in the view's initializer. I know view initializers can be called repeatedly and certain kinds of work should be avoided there, and I am unsure if this is okay or not.

What do people think?

[kamcma]

Follow up, managed to get a demo app up to test this. Doing this in the initializer does not actually work, I get a no-live-implementation error:

struct AuthenticationHostingView: View {
  let store: StoreOf<AuthenticationHostingFeature>

  public init(store: StoreOf<AuthenticationHostingFeature>) {
    @Environment(\.webAuthenticationSession) var session
    // Does not work 👇
    self.store = withDependencies {
      $0.authenticate = AuthenticateEffect { try await session.authenticate(using: $0, callbackURLScheme: $1, preferredBrowserSession: $2) }
    } operation: {
      store
    }
  }

  // ...
}

If there is a way to override a dependency from a view initializer as the store passes through, I am not aware of it.

[mbrandonw]

Doing withDependencies { … } operation: { store } doesn't really have an effect on anything. It simply executes the { store } closure in a context where dependencies are overridden, but that has no bearing on when actions are sent into that store.

If you create a store inside withDependencies, then that does override dependencies for the entire lifetime of the store. But then that is probably not what you want here because typically you want to scope a parent store into a child store.

I think the better way to handle these kinds of things is to hold onto state that communicates to the view when it wants to interact with the environment. So you could have something like:

struct WebAuthenticationRequest {
  var url: URL
  var callbackURLScheme: String
  var preferredBrowserSession: WebAuthenticationSession.BrowserSession?
}
struct State {
  var webAuthenticationRequest: WebAuthenticationRequest?
  …
}

And then in the reducer, anytime you want to invoke \.webAuthenticationSession you do:

state.webAuthenticationRequest = WebAuthenticationRequest(…)

And then in the view you use onChange to listen for changes to the ID, and then do the authentication there:

var body: some View {
  …
  .onChange(of: viewStore.webAuthenticationRequest) { request in 
    try await webAuthenticationSession.authenticate(…)
  }
}

[kamcma]

I actually just noticed the live implementation of swift-dependencies' OpenURLEffect inits EnvironmentValues to grab a value out of it. I wouldn't have guessed this would work. Very interesting! Is this valid to do with anything out of EnvironmentValues? If so, this may be a nice approach. The documentation for the initializer says you'll only get default values doing this, but that's okay, I'm only interested for the live value of my dependency. I do notice it's being done on the main actor; I presume that's a requirement.

[kamcma]

I tried it. It does seem to have worked to access the environment value that way, but the underlying ASWebAuthenticationSession threw an error about not having a presentation context, a familiar error from that API if you do not set the .presentationContextProvider property. So perhaps particular environment values are still sensitive to being called outside the context of a view, even if others, like OpenURLAction, aren't.

[kamcma]

Doing withDependencies { … } operation: { store } doesn't really have an effect on anything. It simply executes the { store } closure in a context where dependencies are overridden, but that has no bearing on when actions are sent into that store.

Ah, thank you for the reminder. In hindsight that does make sense. I was not remembering that initialization in the operation block is the important part, not just passing through it.

I think the better way to handle these kinds of things is to hold onto state that communicates to the view when it wants to interact with the environment.

Ah, okay. That sounds closer to the signaling approach explored in #1683. Thanks for the pointer, I will go back and explore that avenue more. Thanks!