TCA and new SwiftUI focus APIs from WWDC21

[gohanlon]

WWDC21 introduced the SwiftUI FocusState API in the session: Direct and reflect focus in SwiftUI.

Before iOS 15, to direct focus I’d use UIRepresentable views and/or hook into the assumed internal UIView structure that’s created to render SwiftUI views (using Introspect). Both of these approaches are hard to get right and hard to maintain.

To use the new iOS 15 focus API with TCA, my first thought was to create my own binding to provide to the View.focused(…) view modifier, much like we’d typically use viewStore.binding(get:send:) to create a Binding<String> for use with a TextField. But, the View.focused(…) modifier takes a new type of binding that has no accessible initializers:

enum Field {
  case name
}

let _: FocusState<Field?>.Binding = .init()
// → 'FocusState<Field?>.Binding' cannot be constructed because it has no accessible initializers

So, I’ve resorted to observing and replaying changes back and forth between the TCA Store and a vanilla SwiftUI @FocusState property:

• When the TCA reducer updates State.focusedField, observe that change using ViewStore<State, ...>.publisher.focusedField, and then update the value of the vanilla SwiftUI @FocusState property.

• When the user taps a TextField to set or change the focused view, or dismisses focus by pressing return on the keyboard, observe that change to the vanilla SwiftUI @FocusState property using a View.onChange modifier, and then send an action to the ViewStore.

I used this approach to TCA-ify Apple’s enum-usage example for FocusState. I’d love to find a better solution, but here’s what I’ve come up with so far:

Edit: See the latest code, which includes a great improvement suggested by @mbrandonw.

import Combine
import ComposableArchitecture
import SwiftUI

struct LoginFormState: Equatable {
  var username: String = ""
  var password: String = ""
  var focusedField: Field?

  enum Field: Hashable {
    case username
    case password
  }
}

enum LoginFormAction: Equatable {
  case usernameChanged(String)
  case passwordChanged(String)
  case focusedFieldChanged(LoginFormState.Field?)
  case signInTapped
}

let reducer = Reducer<LoginFormState, LoginFormAction, Void> { state, action, _ in
  switch action {
  case .usernameChanged(let username):
    state.username = username
    return .none

  case .passwordChanged(let password):
    state.password = password
    return .none

  case .focusedFieldChanged(let focusedField):
    state.focusedField = focusedField
    return .none

  case .signInTapped:
    if state.username.isEmpty {
      state.focusedField = .username
    } else if state.password.isEmpty {
      state.focusedField = .password
    } else {
//      handleLogin(username, password)
    }
    return .none
  }
}
.debug()

struct FocusTestView: View {
  let store: Store<LoginFormState, LoginFormAction>

  @FocusState private var focusedField: LoginFormState.Field?
  @State private var cancellables: [AnyCancellable] = []

  var body: some View {
    // iOS 15 Beta 1 bug: Placing FocusState-focusable views within a Form view, as in Apple's doc example,
    // completely breaks FocusState. Assigning to the @FocusState property has no effect--it will always
    // be nil. Wrapping in a VStack and/or TCA's WithViewStore works, tho.
    WithViewStore(self.store) { viewStore in
      VStack {
        TextField(
          "Username",
          text: viewStore.binding(get: { $0.username }, send: LoginFormAction.usernameChanged)
        )
        .focused(self.$focusedField, equals: .username)

        SecureField(
          "Password",
          text: viewStore.binding(get: { $0.password }, send: LoginFormAction.passwordChanged)
        )
        .focused(self.$focusedField, equals: .password)

        Button("Sign In") {
          viewStore.send(.signInTapped)
        }
      }
      .onChange(of: self.focusedField) { newValue in
        viewStore.send(.focusedFieldChanged(newValue))
      }
      .onAppear {
        viewStore.publisher.focusedField
          .sink { self.focusedField = $0 }
          .store(in: &self.cancellables)
      }
    }
  }
}

@main
struct TestFocusApp: App {
  var body: some Scene {
    WindowGroup {
      FocusTestView(
        store: .init(
          initialState: LoginFormState(),
          reducer: reducer,
          environment: ()
        )
      )
    }
  }
}

Aside: True to custom, iOS 15 Beta 1 is buggy. Apple’s FocusState example code showing how to use an enum to control focus doesn’t work in the Simulator—I haven’t tested on a real device, yet. (Apple’s example is also missing its View conformance declaration.) This issue has also been discussed in this thread on the Apple Developer Forums. The workaround is to not nest FocusState-focusable views inside a Form.

This approach could be made more ergonomic by creating a custom modifier to bundle the onChange and onAppear modifiers together into a single function.

Does anyone see any problems/opportunities for improvement? Or, does anyone have any ideas for an entirely different approach?

[mbrandonw]

Hi @gohanlon, thanks for starting this discussion!

We've played with this API a bit and the solution we've come up with is essentially what you have. Listen for changes in each of @FocusState and TCA state in order to replay that change to the other. One small difference is that you can use another .onChange for viewStore.focusedField rather than subscribing to the publisher in .onAppear.

And this is actually apart of a bigger pattern that affects not only TCA but even vanilla SwiftUI. If you wanted to capture focus state inside an ObservableObject view model (in order to make it testable) you would need to do the same pattern of replaying changes to connect the VM world to the view world.

We actually have some episodes coming in a few weeks where we explore this and other WWDC topics.

[gohanlon]

… you can use another .onChange for viewStore.focusedField rather than subscribing to the publisher in .onAppear.

Ah, yes—that’s a great improvement that I missed. For anyone who comes by later, I put the updated code in a Gist.

We actually have some episodes coming in a few weeks where we explore this and other WWDC topics.

Wonderful. I look forward to those episodes. 😁