TCA driving UIViewRepresentable/NSViewRepresentable

[kamcma]

Hello!

Has anyone played around with driving UIViewRepresentable/NSViewRepresentable with TCA? I am enjoying working with SwiftUI, but do quickly find myself looking outside its limited library of views.

I will concede up front I am inexperienced with UIKit and AppKit. I looked at the UIKit case studies in the TCA repository, but this UIViewRepresentable/NSViewRepresentable space is neither pure SwiftUI nor pure UIKit/AppKit and I wasn't able to piece it together myself.

For example, I went to wrap NSComboBox with NSViewRepresentable, and this is what I sketched out.

struct ComboBoxRepresentableState: Equatable {
    let options: [String]?
    var selection: String
}

enum ComboBoxRepresentableAction {
    case selectionDidChange(Notification)
    case selectionIsChanging(Notification)
    case willDismiss(Notification)
    case willPopUp(Notification)
}

let comboBoxRepresentableReducer = Reducer<ComboBoxRepresentableState, ComboBoxRepresentableAction, Void> { state, action, _ in
    switch action {
    case let .selectionDidChange(notification):
        guard let comboBox = notification.object as? NSComboBox,
              let value = comboBox.objectValueOfSelectedItem as? String else { return .none }
        state.selection = value
        return .none
    case .selectionIsChanging, .willDismiss, .willPopUp:
        return .none
    }
}

struct ComboBoxRepresentable: NSViewRepresentable {
    let store: Store<ComboBoxRepresentableState, ComboBoxRepresentableAction>
    @ObservedObject private var viewStore: ViewStore<ComboBoxRepresentableState, ComboBoxRepresentableAction>
    
    init(store: Store<ComboBoxRepresentableState, ComboBoxRepresentableAction>) {
        self.store = store
        self.viewStore = ViewStore(store)
    }
    
    final class Coordinator: NSObject, NSComboBoxDelegate {
        @ObservedObject private var viewStore: ViewStore<ComboBoxRepresentableState, ComboBoxRepresentableAction>
        
        init(_ viewStore: ViewStore<ComboBoxRepresentableState, ComboBoxRepresentableAction>) {
            self.viewStore = viewStore
        }
        
        func comboBoxSelectionDidChange(_ notification: Notification) {
            viewStore.send(.selectionDidChange(notification))
        }
    }
    
    func makeCoordinator() -> Coordinator {
        Coordinator(viewStore)
    }
    
    func makeNSView(context: Context) -> NSComboBox {
        let comboBox = NSComboBox()
        comboBox.delegate = context.coordinator
        if let options = viewStore.options {
            comboBox.addItems(withObjectValues: options)
        }
        
        return comboBox
    }
    
    func updateNSView(_ nsView: NSComboBox, context: Context) {
        nsView.stringValue = viewStore.selection
    }
}

Setting aside that this implementation is not complete because it does not propagate options changes into the NSComboBox, I think it is also not communicating selection changes back to my store when I think it should be, and I am not quite sure why. So my first question is if any of you good people see what my bug is? Or possibly, explain why what I am trying to do here is not the right way to go about this.

But second, if this is a reasonable thing to do, my Spidey-sense feels like there's some API improvements to be had here, but I'm not quite able to figure them out. E.g., it almost seems like a ViewStore itself could be a Coordinator, in that it serves a similar function, but Coordinators must inherit from NSObject and I don't think that's an inheritance I can add. Also: it almost feels like I wish could make the Action enum my NSComboBoxDelegate directly, because its cases are literally the delegate methods I want to handle.

Thank you for any thoughts. Have a nice day 🙂.

[RabugenTom]

About your issue with the Store not updating, it is very easy to forget to pullback the combo reducer into its parent, as it will compile and will most likely not produce errors at runtime. You also don't need to use @ObservedObject in your Coodinator as it is not a View (it shouldn't cause any issue though). I would also check that state.selection = value after the guard in the reducer is hit.

When I'm using UI/NSViewRepresentable, I totally forget that I'll use them with TCA later, and I try to make them behave as vanilla SwiftUI views.

For NSComboBox, I would personally use a binding (you can even use generic values if you want), and use the Coordinator as a delegate like you did.

In other words, I would do something like this (not tested, but I think you'll get the idea)

struct MyView: View {
  @ObservedObject var viewStore: ViewStore<State, Action>
  var body: some View {
    ComboBoxRepresentable(options: viewStore.options,
                          selection: viewStore.binding(get: \State.selection,
                                                       set: Action.selection))
  }
}

struct ComboBoxRepresentable: NSViewRepresentable {
  let options: [String]
  var selection: Binding<String>
  init(options: [String], selection: Binding<String>) {
    self.options = options
    self.selection = selection
  }
  
  final class Coordinator: NSObject, NSComboBoxDelegate, NSComboBoxDataSource {
    let selection: Binding<String>
    init(selection: Binding<String>) {
      self.selection = selection
    }
        
    func comboBoxSelectionDidChange(_ notification: Notification) {
      let combo = notification.object as! NSComboBox
      selection.wrappedValue = combo.stringValue
    }
  }
    
  func makeCoordinator() -> Coordinator {
    Coordinator(selection: selection)
  }
    
  func makeNSView(context: Context) -> NSComboBox {
    let comboBox = NSComboBox()
    comboBox.delegate = context.coordinator
    comboBox.addItems(withObjectValues: options)
    return comboBox
  }
    
  func updateNSView(_ nsView: NSComboBox, context: Context) {
    nsView.stringValue = selection.wrappedValue
  }
}

Of course, the coordinator can handle more delegate methods, or even be the dataSource. I personally like to put these very general struct at the same level as other SwiftUI controls, as they'll behave the same when used together.

Again, this is my personal take on the matter and I'm not bearing any universal truth. Using TCA to achieve this seems absolutely doable, but I'm afraid you'll introduce a lot of boilerplate for very little returns. You can also write the vanilla wrapper, and then wrap it itself in a pure SwiftUI/TCA view, but here again, I don't know if it will be easier to use than a vanilla-like SwiftUI control.

[kamcma]

Thank you for the pointers! Good food for thought. Yes, perhaps it is wiser to keep the view wrapping just vanilla.

[mbrandonw]

Yeah, I agree with @RabugenTom. Anytime I've had to deal with view representables I've kept them as a plain SwiftUI entity using bindings and then passed in TCA derived bindings from the outside. This may not work with really complex view representables, but it's a good idea to start there.

We have an example of this in the ComposableCoreLocation repo where we have a MapView that uses bindings:

https://github.com/pointfreeco/composable-core-location/blob/main/Examples/LocationManager/Common/MapView.swift

And then we pass in a view store binding here:

https://github.com/pointfreeco/composable-core-location/blob/main/Examples/LocationManager/Mobile/LocationManagerView.swift#L24

[kamcma]

Thank you for the link to an example. I should've guessed there might be one in the composable framework libraries.