How to throttle action sending?

[notcome]

Let's say we are building a search UI, and would like to throttle search requests. We would have an action to represent the user changed the text field, and a new search request effect can be initiated there. How would we throttle it?

I have three ideas in mind:

The first is just putting throttling management state as part of the feature state. I haven't went it the details of this approach, but it certainly feels redundant, error-prone, and obfuscating the core logic of the feature.

Creating an coordinator object from the search client and storing the object in our state. We can hold an AsyncChannel in the object, and whenever a new request is received from the channel, we can perform an search operation. There is an additional output channel that would be used to publish the search results. We can start an observation in the reducer at the start of the feature for those search results. When the object is deinitialized, we can cancel all those channels, which would ending our observation (if we are not using PresentationState/Action).

I chose this approach, but just by writing the above done I already feel like this is tricky to get right. For instance, older search requests can return later than more recent ones, leading to outdated results.

The primary concern I had over this one is that storing an object in the state feels extremely wrong. I can probably get over this during testing since we are doing patch-style equality check, but something just feels wrong.

Moving the job to the client. Maybe there we can use an search caller id and do throttling using id. If globally the app will only use this search functionality once, we can even get rid of this. It does feel the reverse of the first approach though, making reusing logic a little bit difficult. And technically throttling is a part of the UI, not the backend.

Do you people have any suggestions, or sharing some light into what you did in similar situations? Thanks

[Alex293]

Have a look here : https://github.com/pointfreeco/swift-composable-architecture/blob/main/Examples/Search/Search/SearchView.swift

Easy and testable, not much management to be done in state

[notcome]

Thanks!

[mbrandonw]

As @Alex293 mentioned, the Search demo app shows how to debounce text field changes in order to perform a network request. It does so in the easiest way, which is to defer the debouncing logic to the task(id:) view modifier in the view. This sends the minimal amount of actions into the store, and so your reducer can just concentrate on the bare essentials of work it needs to do.

Alternatively you can debounce actions going into a reducer via a pattern like this:

case let .textFieldChanged(text):
  state.text = text
  return .run { send in 
    enum CancelID { case debounce }
    try await withTaskCancellationHandler(id: CancelID.debounce) {
      try await Task.sleep(for: .milliseconds(300))
      // API request...
    }
  }

[notcome]

Thanks for sharing both ways. Very illuminating. I do wonder if we need more customized control, such as throttle, or some arbitrary flow-control operator, what would be some good way to do it? Has this topic ever been discussed in your collection before?

[mbrandonw]

We had a throttle operation for effects but unfortunately it was removed in 1.0. We do plan on bringing it back soon, we just don't know when we will have time right now.

Other than that there has not been much general discussion around other kinds of customized flow control.

[notcome]

Glad to hear that! TBH I asked precisely for the migration to 1.0😂😂😂

[mbrandonw]

We just released 1.1 that brings back throttling: https://github.com/pointfreeco/swift-composable-architecture/releases/tag/1.1.0

[pro100filipp]

I am working on the search feature also right now and after digging into the docs a question arrived:

• using task modifier for debouncing is a very elegant solution in my own opinion but why do we even need doing so? Isn't it simpler to implement debouncing logic inside 'searchQueryChanged(text)' action itself? It's already invoked on each user's typing (because it's required to handle correct state of query) and we can create effect there with '.denounce'. Furthermore it eliminates separate action for "debounced search" thus simplifying the code and reducing amount of actions sent.

Could you please convince if these are right thoughts or am I missing something?