Debouncing TextField bindings makes last input char lost

[oskargargas]

Hello!

I have a problem with debouncing bindings. I perform save operation on every input to a TextField. When raw it works as intended. But to optimize writes to disk a bit I created a custom Effect based on Effect.fireAndForget and added a debounce to id. And here the problem starts. Some times (50%?) I don't get last input saved. For example when I input "1234" to a TextField it saves "123". If I delete whole field pressing backspace it saves "1" instead "".

Let's see some code.

View looks so:

SomeHelperView(
    title: "Some Data",
    binding: viewStore.binding(\.$someData.data.value),
    keyboardType: .numberPad)

struct SomeHelperView: View {
    var title: String
    var binding: Binding<String>
    var keyboardType: UIKeyboardType

    var body: some View {
        VStack(alignment: .leading) {
            Text(title).font(.headline)
            TextField(title, text: binding)
                .textFieldStyle(.roundedBorder)
                .disableAutocorrection(true)
                .keyboardType(keyboardType)
        }
    }
}

Store like this:

struct SomeState: Equatable {
        @BindableState var someData = SomeManagedData.loadOrCreate(.someIdentifier)
}

Action:

enum SomeAction: BindableAction {
        case binding(BindingAction<SomeState>)
}

And Reducer:

static let someReducer = Reducer<SomeState SomeAction, SomeEnvironment> { state, action, environment in
    switch action {

    case .binding(\.$someData.data.value):
        return .saveManagedData(state.someData, scheduler: environment.mainQueue)
    case .binding:
        return .none
    }
}.binding()

And most important, my custom effect:

extension Effect {
    static func saveManagedData<T: ManageableData>(_ data: ManagedData<T>,
                                                   scheduler: AnySchedulerOf<DispatchQueue>,
                                                   dueTime: DispatchQueue.SchedulerTimeType.Stride = 0.3) -> Effect {
        return .fireAndForget {
            data.save()
            DDLogDebug("[TCA] Saving managed data with id: \(data.id), data: \(data.data)")
        }.debounce(id: data.id, for: dueTime, scheduler: scheduler)
    }
}

ManagedData is a class that wraps other data types. It has id: UUID and various helper methods with save() being a synchronous save to a file.

Funny thing is that when I add logging to the Effect it starts to work as expected. Like logging (it's CocoaLumberjack) forced some state synchronization, don't know for sure, I'm riffing here.

Any insight will be appreciated!

[tgrapperon]

ManagedData is a class […]

I have a feeling that's the root of the issue, or at best is hiding what's going on. Is is possible to refactor your effect to use a String value that is snapshotted when you emit the effect? To check if it would help, you can simply add a String argument to the effect, and in the fireAndForget, you can check if data still has the same value as when the effect was emitted. The problem with the current setup is that the outside world can touch the Store's State without informing it. I'm also wary about the data being instantiated by itself in State. Is data the same instance each time in .fireAndForget?

In my experience with reference types, it is safer to keep them in the Environment and to interface with them with value-type snapshots you store in State. If you use reference types to store your data, you need to setup an observation mechanism to update the State value when the content changes, so the corresponding ViewStore can spot the changes and update the UI accordingly.

It is possible to work with reference types in State, but you still need an observation mechanism to update some Int token (for example) in the State when your data changes.

If the uncontrolled reference type is not responsible there, and when the incomplete data is saved, does the TextField still shows the complete String value? I've seen some strange behaviors sometimes with them too. If you add a .debug() to the reducer, do you see the binding being triggered for each character, even when the data is incompletely saved? If some action is missing and if you're using a WithViewStore, does installing manually instead a ViewStore(store: store) that you generate in the parent view init helps? (You need to declare it as an @ObservedObject in the parent view).

[oskargargas]

Not being able to store reference type in State would be unfortunate... My ManagedData is a naive implementation of Active Record Pattern. Everything that needs persistence is ManagedData.

In above setup outside world cannot touch anything in State. State instantiates its copy of a managed object from disk and nothing else has access to this instance. If anything else would instantiate same object from disk it would have it's own copy (with the same data). We could argue what would happen when multiple copies would be saved at the same time... but it doesn't happen here for sure.

Is data the same instance each time in .fireAndForget?

Nothing besides State, binding and reducer doesn't touch this data. I'm 100% sure of that. Also nothing on my side doesn't reinitialize State/Store or any other TCA component.

If the uncontrolled reference type is not responsible there, and when the incomplete data is saved, does the TextField still shows the complete String value?

Yes. In UI everything is perfect. I see the problem only after I dismiss the screen and load it again effectively recreating Store, State and loading all the data from ground up.

If you add a .debug() to the reducer, do you see the binding being triggered for each character, even when the data is incompletely saved?

Yes... and then some. Thanks for the .debug() hint, I'm using TCA for the first time and forgot about that function. It shows something strange to me. When I quickly double tap 1 to enter "11" it shows 3 actions. 1, 11 and again 1. I don't understand where from comes the third action.

Here's log:

received action:
  TCA.Action.DevOptions.binding(
    BindingAction.set(
      WritableKeyPath<DevOptions, BindableState<String>>,
      "1"
    )
  )
  (No state changes)

received action:
  TCA.Action.DevOptions.binding(
    BindingAction.set(
      WritableKeyPath<DevOptions, BindableState<String>>,
      "11"
    )
  )
  (No state changes)

received action:
  TCA.Action.DevOptions.binding(
    BindingAction.set(
      WritableKeyPath<DevOptions, BindableState<String>>,
      "1"
    )
  )
  (No state changes)

Binding<String> action tried to update multiple times per frame.
Binding<String> action tried to update multiple times per frame.
received action:
  TCA.Action.DevOptions.close
  (No state changes)

[tgrapperon]

Ok, the third set action with "1" shouldn't happen. This is probably the TextField emitting an old value for some reason.
You can observe the transit across your binding using the bimap function I've presented here, with something like

viewStore.binding(\.$someData.data.value)
  .bimap(
    get: {
      print("Get: \($0) - \(viewStore.someData.data)")
      return $0
    },
    set: {
      print("Set: \($0) - \(viewStore.someData.data)")
      return $0
    }
  )

You should be able to see what TextField sees, and eventually put a debugger breakpoint to see where the last "1" comes from. The binding emitting "1" while displaying "11" in the TextField would be a SwiftUI bug. "Binding<String> action tried to update multiple times per frame." is suspicious in this case too. Are you sure the data instance is effectively the same? (that's why I put the "\(viewStore.someData.data)" in the bimap).

What happens in your exact setup if you declare a String value in your State, and bind to it instead of some property of your data? (it will not work for your domain, but it allows you to test your SwiftUI stack). That is if you update a dummy String value in your State. Is it working OK?

[tgrapperon]

BTW, the "(No state changes)" in .debug() are expected there because of the reference type, but pathological. This let me think that:

• Your data instance indeed doesn't seem to change between actions;
• Your TextField binding is "loose". It doesn't receive back in get the value it sets (or even anything else). I guess that's the cause of the issue. If you'd use a vanilla @State var string: String instead, it would receive in get the value it did set. This wouldn't happen with a value type state. Try to update an Int count in State for each received binding action to see if it helps. It may not be enough though, and it would probably be better to have a String that mirrors what's going on in data.value. Is the data part of your SomeManagedData a reference type too?

[tgrapperon]

I thought a bit more about your issue, and I think you'll have a hard time dealing with reference-type and TCA, especially if you're new to the framework. You'll encounter many similar bugs where the UI is not in a one-to-one relation with the state.

If you're absolutely sure that no one modifies your class outside of a reducer, a simple approach would be to extract a value type snapshot of your class that you store aside your class, in the state. You also need a setter method to inject a snapshot into your class. This snapshot only needs the properties you're going to access. You never directly access properties from your class: you extract a snapshot when you initialize the state, and you inject your snapshot back to update your class when changes are made.
You build your TCA reducer/view around this snapshot. When the snapshot changes, you update the class and after debouncing, persist the changes.

As you see, in this setup, the class could either be in the state or in the environment. It will work as a standard TCA stack, with all-value type states, and it should perform without surprises/bugs.

I'm not super fond of the debounced effect that only brings the reference type to touche it later. There are many cases this will go wrong. I would pass the snapshot as an (additional) argument and apply it to the class in the fireAndForget. In your case, it would look like:

struct Snapshot: Equatable {
  var value: String
  init(_ managedData: SomeManagedData) {
    self.value = managedData.data.value
  }
  func inject(into managedData: SomeManagedData) {
    managedData.data.value = value
  }
}

struct SomeState: Equatable {
  let someData: SomeManagedData
  @BindableState var snapshot: Snapshot
  init() {
    let reference = SomeManagedData.loadOrCreate(.someIdentifier) //<- This is problematic, you're accessing the 
// outside world from the state, that why I thing it would be better to consider the reference type as a dependency.
    self.someData = reference
    self.snapshot = Snapshot(reference)
  }
}

static let someReducer = Reducer<SomeState SomeAction, SomeEnvironment> { state, action, environment in
    switch action {
    case .binding(\.$snapshot.value):
      return .saveManagedData(state.someData, snapshot: state.snapshot, scheduler: environment.mainQueue)
    case .binding:
      return .none
    }
}.binding()

extension Effect {
  static func saveManagedData<T: ManageableData>(
    _ data: ManagedData<T>,
    snapshot: Snapshot,
    scheduler: AnySchedulerOf<DispatchQueue>,
    dueTime: DispatchQueue.SchedulerTimeType.Stride = 0.3
  ) -> Effect {
    return .fireAndForget {
      snapshot.inject(into: data)
      data.save()
      DDLogDebug("[TCA] Saving managed data with id: \(data.id), data: \(data.data)")
    }.debounce(id: data.id, for: dueTime, scheduler: scheduler)
  }
}

But this implementation is problematic in several ways, with many unaccounted mutations routes. Here's how I would set up things (this is my personal opinion, not a canon):

• Consider SnapShot as a state itself. Your TCA feature works unaware of the existence of the reference type. Its only responsibility is to present an editable slice of your data.
• Embed it in another feature that is responsible for extracting a reference-type from a dependency datastore and creating the Snapshot. Ideally, your datastore (or some wrapper) can vend a publisher of your data class that emits on changes. You can subscribe to it and convert its events to an action that sets the Snapshot value in the parent state.
• When this Snapshot is changed, update the reference-type from the parent reducer as an effect to the outside world. The parent only responsibility is to handle the Snapshot lifetime and modification as a whole. You can switch on the child binding action from the parent reducer to manually detect changes for example, or use some higher-order reducer like the onChange from isowords to detect them automatically.

All these features have limited responsibility and are testable more easily than a monolithic one.

[tgrapperon]

In case having a reference type in State is unavoidable, this property wrapper may help standardizing things:

@propertyWrapper
public struct ReferenceState<State>: Equatable where State: AnyObject {
  struct Token: Hashable {
    let sec: Int
    let nsec: Int
    init() {
      var uptime = timespec()
      guard clock_gettime(CLOCK_MONOTONIC_RAW, &uptime) == 0 else {
        fatalError("Unable to retrieve uptime")
      }
      self.sec = uptime.tv_sec
      self.nsec = uptime.tv_nsec
    }
  }

  private var didChangeToken: Token
  public var wrappedValue: State

  public init(wrappedValue: State) {
    self.wrappedValue = wrappedValue
    self.didChangeToken = Token()
  }

  public var projectedValue: Self {
    get { self }
    set { self = newValue }
  }

  public mutating func didChange() {
    self.didChangeToken = Token()
  }

  public static func == (lhs: ReferenceState<State>, rhs: ReferenceState<State>) -> Bool {
    lhs.wrappedValue === rhs.wrappedValue && lhs.didChangeToken == rhs.didChangeToken
  }
}

You can simply call .didChange() on the projectedValue to invalidate the state's value from the parent's point of view.

If SomeClass is a class, you can use it as:

class SomeClass {
  var string = ""
  var count = 0
}

struct State {
  @ReferenceState var object = SomeClass()
}

// In the reducer, when reducing an action:
[…]
  state.object.string = "Hello!"
  state.object.count += 1
  state.$object.didChange()
  return .none
[…]

NB: The monotonically increasing Token is maybe overkill, and it can probably safely be replaced by some random UUID or even some random Int.

[oskargargas]

Thank you @tgrapperon for your input. I created a struct wrapper on my data which copies its id and value and based on that is able to save it when it's necessary. It works well.

To be honest I didn't expect such problem will arrive. Personally I would consider this as a framework bug. I understand your point about risk of values being modified by outside world but as long as this is not happening I would expect everything to work the same. I have to learn a lot about TCA and SwiftUI and how all this works at low level. Will remember about this limitation.

Thanks

[tgrapperon]

This is a common issue with many "reactive" frameworks: you need to be able to spot when a value has changed to automatically keep the UI in sync with the model. It's automatic with value types, but not with reference types. You probably would have the same kind of issues with Vanilla SwiftUI. That's also why ObservableObject exists (but they're using a publisher instead of a Token value).

The tropism of Swift toward value types is partly there to prevent action at distance. To implement this kind of protection with reference types, we would end with things like "MutableString" or "MutableArray" like in Objective-C. What happens if .save() updates a counter in your ManagedObject class in the .fireAndForget? I understand you know you have control over the class and what's going on, but what about in 2 years when you'll update the type to add some sanitization that uppercases value on .save()? Would you remember to check what's going on if you edit the TextField, go back and edit the TextField again to discover that now, the value is uppercased? This is the kind of safeguard value-type are providing.