Binding with custom focusable views

[seanmrich]

I tried using the .bind modifier from swiftui-navigation on a custom view using .focusable(), but it behaves erratically. Here's a simple setup to demonstrate:

class Model: ObservableObject {
    @Published var title = ""
    @Published var focus: Focus? = .circle
    enum Focus: Hashable {
        case title
        case circle
    }
}

struct ContentView: View {
    @ObservedObject var model: Model
    @FocusState private var focus: Model.Focus?
    
    var body: some View {
        VStack {
            TextField("Title", text: $model.title)
                .focused($focus, equals: .title)

            Circle()
                .focusable()
                .focused($focus, equals: .circle)
                .frame(height: 50)
            
            Text(model.focus?.display ?? "nil")
        }
        .frame(maxWidth: 200)
        .bind($model.focus, to: $focus)
    }
}

extension Model.Focus {
    var display: String {
        switch self {
        case .title: return "title"
        case .circle: return "circle"
        }
    }
}

To see the behavior, you must have keyboard navigation turned on (System Settings→Keyboard→Keyboard navigation). When launched the view will have focus on the circle and the model indicates its focus is circle. When you hit TAB, the focus moves to the title, but the model still thinks the focus is on the circle. Any further TABs have no effect--well, not exactly. There's a flash of the focus ring when you hit TAB. Presumably it's trying to move to the next key view, but is immediately reset back to the title.

If you replace the bind modifier with something along the lines of the focus state episode from last year,
you get a better result:

extension View {
    func synchronize<Value: Equatable>(
        _ modelValue: Binding<Value>,
        to viewValue: FocusState<Value>.Binding
    ) -> some View {
        self
            .onChange(of: modelValue.wrappedValue) { viewValue.wrappedValue = $0 }
            .onChange(of: viewValue.wrappedValue) { modelValue.wrappedValue = $0 }
    }
}

Replace .bind with .synchronize and now you get the expected behavior. Focus moves back and forth between the title field and the circle. I tried replicating the bind modifier and stripping it down to the same logic as in the synchronize modifier, but I get no improvement. Somehow, wrapping the logic in a ViewModifier changes the behavior. Can anyone help me resolve this issue? If it makes a difference, I'm using Xcode 14.1 on Ventura 13.0.1.

---

Parenthetically, I don't understand how the synchronize modifier compiles. The FocusState property wrapper requires its Value to be Hashable, but the modifier only requires Equatable. The same Equatable requirement is in the bind modifier. How does that compile without Hashable conformance?

[tgrapperon]

Hey @seanmrich!
FocusState<Value> requires the Value to be Hashable, so this constraint is implicit an propagates to the whole declaration. If you have FocusState<Value>, Value needs to be Hashable. As a consequence, you can check that removing the Equatable requirement compiles and works too.

I'm not 100% sure about what's going on here. bind would work if we wouldn't check that the view's value is the same as the new model's one before assigning it. I feel that even with this check removed, infinite loops would be prevented by the other branch, but I don't know if this is the right move to do, nor if this should be platform-specific. This is maybe related to some weirdness around @Published that emits on willSet, or something else specific to @FocusState.

@available(iOS 14, macOS 11, tvOS 14, watchOS 7, *)
private struct _Bind<ModelValue: _Bindable, ViewValue: _Bindable>: ViewModifier
where ModelValue.Value == ViewValue.Value, ModelValue.Value: Equatable {
  let modelValue: ModelValue
  let viewValue: ViewValue

  @State var hasAppeared = false

  func body(content: Content) -> some View {
    content
      .onAppear {
        guard !self.hasAppeared else { return }
        self.hasAppeared = true
        guard self.viewValue.wrappedValue != self.modelValue.wrappedValue else { return }
        self.viewValue.wrappedValue = self.modelValue.wrappedValue
      }
      .onChange(of: self.modelValue.wrappedValue) {
//        guard self.viewValue.wrappedValue != $0
//        else { return }
        self.viewValue.wrappedValue = $0
      }
      .onChange(of: self.viewValue.wrappedValue) {
        guard self.modelValue.wrappedValue != $0
        else { return }
        self.modelValue.wrappedValue = $0
      }
  }
}

[tgrapperon]

All these mixed signals around invalidation made me try to remove Bindable inheritance to DynamicProperty, and it seems to work. I guess this was somehow interfering with the way SwiftUI observes these values that are already DynamicProperty by themselves.
I've created the PR #46 accordingly.
@seanmrich I think the differences between StateObject and ObservedObject was coincidentally making it work by invalidating different orbits in the attributes graph. We're in a very grey area regarding internal DynamicProperty handling, so it's hard to draw definitive conclusions.

[seanmrich]

A final post on this issue--not sure if anyone else has the same use case so I might be wasting everyone's time. An update to the demo project I mentioned above shows that when displaying (via Text view) both model and view focus, the modifier version of the view works normally. Same when displaying the view focus alone. If only displaying the model focus (or not displaying at all), the weird behavior comes back. Somehow referencing the view's focus value within the view (outside the focused calls) seems to get the binding to work normally.

Bottom line is that using the bind method from @tgrapperon that doesn't use a ViewModifier seems to solve the issue in all cases I've tested. Perhaps it's worth considering a change to the version in the swiftui-navigation repo?

[seanmrich]

Feedback filed on the issue: FB11853306

[stephencelis]

@seanmrich I just merged that and cut a 0.4.3 release, so you should be good to go after you update!

[seanmrich]

Thanks, @stephencelis!