How to debounce or delay a dispatch?

[m9dfukc]

Sorry for the ignorance ... what's the best way to debounce or delay a dispatch? In redux land there are various kinds of middleware for that.

Maybe you could add an answer to this to the FAQ section?!

[danielcompton]

There's a built-in :dispatch-later fx handler in re-frame.

These issues for re-frame are for bug reports and feature requests. Support requests and usage questions should go to the Clojure Slack channel, the ClojureScript mailing list, or the Reagent mailing list. Feel free to discuss this further on one of those channels. I've thought a little bit about debouncing, but haven't really needed it so far.

[mike-thompson-day8]

First, let me say that I've never run into this issue, so I'm not confident I fully understand all the requirements. I'm going to need guidance here on what's needed, particularly on any fine detail.

My first thought is that this should be done via an effect handler, supplied in a library (not in re-frame itself). That's exactly why the effect handlers system was created to be extensible. So, this would be a very small library (30 lines of code?) for someone to write (not me) but we can thrash out the details in this ticket.

An event handler (which needed to issue a debouncable event) might look like this:

(def-event-fx 
   :search-key-pressed
   (fn [cofx [_ current-search-string]]
     {:dispatch-debounce {:key     ::search     ;; a unique key
                          :event   [:do-search current-search-string]    ;; an event vector 
                          :delay  250}]}))       ;; the future time at which to issue

The idea is that the event [:do-search current-search-string] would be dispatched after a delay of 250ms, unless another one (with the same :key) is re-issued within that time, in which case the new event would be issued instead, but not until after a further delay of 250ms, and only if it too was not itself replaced.

Notes:

• what other requirements? What about the need for cancellation?
• what about testing? How should it be stubbed out?
• made a part of a small standalone library or put into re-frame itself?

Later: Uggh. I accidentally managed to click "Close and Comment' instead of "Comment". So read nothing into the following closing and reopening noise.

[f-f]

Looks good to me! The requirements for the usage I have in mind are all there.
Comments:

• Is the :key really needed? Why not using as key the keyword of the event vector itself?
• To cancel I guess another effect handler like :stop-debounce would be needed?
• Probably it's better to include it in re-frame itself, since there are similar things that are taken care of already, like :dispatch-later.

[rafd]

I've just run into this for a project, and implemented it as follows:

(defonce timeouts
  (atom {}))

(reg-fx :dispatch-debounce
        (fn [[id event-vec n]]
          (js/clearTimeout (@timeouts id))
          (swap! timeouts assoc id
                 (js/setTimeout (fn []
                                  (dispatch event-vec)
                                  (swap! timeouts dissoc id))
                                n))))

(reg-fx :stop-debounce
        (fn [id]
          (js/clearTimeout (@timeouts id))
          (swap! timeouts dissoc id)))

Example of using it:

(def-event-fx 
   :search-field-updated
   (fn [_ [_ current-search-string]]
     {:dispatch-debounce [::search [:do-search current-search-string] 250]}))

(def-event-fx 
   :cancel-search
   (fn [_ _]
     {:stop-debounce ::search}))

[rafd]

@ff- I think a :key is necessary, because you could have the same event being dispatched by different sources for different reasons.

For example, say I had two search fields, with dispatches such as: (dispatch [:search-field-updated :field-a "value-of-field-a"]) and (dispatch [:search-field-updated :field-b "value-of-field-b"]).

In my handler, if I did:

(def-event-fx 
   :search-field-updated
   (fn [_ [_ field current-search-string]]
     {:dispatch-debounce [[:do-search field current-search-string] 250]}))

...then the two fields wouldn't be debounced independently.

This specific example is a bit contrived, but I have run into the need for a :key in a situation where I am validating multiple fields in a form (and they all dispatch [:update-value :field-name "value"]).

[f-f]

@rafd very true, thanks for the answer!
Moreover, your implementation looks very clean; I would love to see this merged in.

[danielcompton]

Probably it's better to include it in re-frame itself, since there are similar things that are taken care of already, like :dispatch-later.

I won't comment for Mike, but will give my thoughts on this:

• re-frame is written to be open for extension, where people can provide different fx and cofx. Providing a 'default' debouncer may discourage people from writing their own, or prevent the flourishing of competing alternatives
• I could see this as a separate library (possibly under the day8.re-frame group or otherwise)
• This is such a small fx with no external dependencies, and seems to be moderately useful, which is an argument for inclusion.
• If it is in re-frame core, then it is subject to the slower release cycle of re-frame
• Once we include it, there is strong pressure to not break backward compatibility by removing it.
• It could start out as an external library, and once it is stabilised, if it is useful then be brought in to core.

I have no particularly strong feelings either way, just sharing my perspective.

[danielcompton]

There's a PR for this in #249.

[danielcompton]

At this stage, we're going to keep debounce and throttle effects as separate from the core of re-frame. More details in #258 (comment).