What is the correct way to force the binding() action on a specific scheduler?

[ylorn]

For the example code below:

struct FooState: Equatable {
    @BindableState var foo = ""
}

enum FooAction: Equatable, BindableAction {
    case binding(BindingAction<FooState>)
}

typealias FooEnvironment = Void

var fooReducer: Reducer<FooState, FooAction, FooEnvironment> = .init { state, action, environment in
    switch action {
    case .binding:
        return .none
    }
}
.binding()

I want to force the mutation to FooState.foo on a specific queue, say the DispatchQueue.main. I know I can achieve this by adding a proxy action like:

enum FooAction: Equatable, BindableAction {
+    case setFoo(String)
    case binding(BindingAction<FooState>)
}

var fooReducer: Reducer<FooState, FooAction, FooEnvironment> = .init { state, action, environment in
    switch action {
+    case .setFoo(let foo):
+        return .init(value: .set(\.$foo, foo))
+            .delay(for: 0.2, scheduler: DispatchQueue.main)
+            .eraseToEffect()

    case .binding:
        return .none
    }
}
.binding()

But is there a way to avoid this redundancy of adding a specific action to do something that can already be achieved by the binding action, and apply the Effect modifier like receiving on specific queue directly to it?

[mbrandonw]

Can you explain a bit more about what you are trying to achieve?

TCA's types are not thread safe, and so it is expected you always interact with them on the main thread. It's your responsibility to do that, and the library does not automatically enforce it for various reasons.

[ylorn]

@mbrandonw Thanks for replying.

TCA's types are not thread safe, and so it is expected you always interact with them on the main thread. It's your responsibility to do that, and the library does not automatically enforce it for various reasons.

Yes, I understand that, and I am perfectly happen to maintain the thread manually.

Can you explain a bit more about what you are trying to achieve?

What I want to achieve is, to assign a queue to a binding action without having to declare a dedicated action to do so. To put it simply, I don't want to have the setFoo() action but still somehow guarantee that foo is mutated on a queue with a delay of 0.2s.

Something like (I am making this up):

enum FooAction: Equatable, BindableAction {
-    case setFoo(String)
    case binding(BindingAction<FooState>)
}

var fooReducer: Reducer<FooState, FooAction, FooEnvironment> = .init { state, action, environment in
    switch action {
    case .binding:
        return .none
    }
}
+.binding { keyPath in
+    switch keyPath {
+    case .$foo:
+        return { foo -> Effect in
+            Effect(value: .set(\.$foo, foo))
+                .delay(for: 0.2, scheduler: DispatchQueue.main)
+                .eraseToEffect()
+        }
+    }
+}

[mbrandonw]

Ok, if I'm understanding correctly, the real issue here is not so much that you want to execute something on the main queue, but that you want to delay updating your state from a binding by 0.2 seconds?

If that is the case then yes you must use a separate action.

[mbrandonw]

You can define an operator on Binding to delay writes by 0.2 seconds:

extension Binding {
  func delay<S: Scheduler>(
    for interval: S.SchedulerTimeType.Stride,
    tolerance: S.SchedulerTimeType.Stride = .zero,
    scheduler: S,
    options: S.SchedulerOptions? = nil
  ) -> Self {
    .init(
      get: { self.wrappedValue },
      set: { newValue in
        scheduler.schedule(
          after: scheduler.now.advanced(by: interval),
          tolerance: tolerance,
          options: options
        ) {
          self.wrappedValue = newValue
        }
      }
    )
  }
}

Then actions won't even be sent into the store until the delay has passed.

[ylorn]

Wouldn't this mean introducing dependencies into View directly instead of doing so in Environment?

WithViewStore(self.store) { viewStore in
    TextField(
        "Foo",
        text: viewStore.binding(\.$foo)
+            .delay(
+                for: 0.2,
+                scheduler: DispatchQueue.main
+            )
    )
}

Or am I using the extension function incorrectly?

[mbrandonw]

Yes, this would be view only logic that is not seen by the reducer, but it's an alternative if you do not want to manage the extra action.

[ylorn]

Thanks. 🙏🏼

I still prefer the way of isolating dependencies which is one of the core concepts of TCA.

Hopefully we can see enhancements to bring more customizability and composability to the library in the future.

[tgrapperon]

When the delayed value will finally come back from the model to the get side of the binding, the TextField will update with it and delete what the user may have input in between. Is this what you want?
[Edit] Ok, I get it, it was only an example of delayed binding. But this is the kind of issues this will create in other configurations.