Clojurians Log v2

I had a somewhat similar situation at one point and my lazy hack was to store the last request and abort it if a new one were to take place. Not the best, but it works.

Three solutions that I know of: • The mentioned above, with canceling requests (I assume "not the best" means that the implementation wasn't the best because the approach itself is IMO actually the best) • Track the ordinal of the request and only respect the results of the request with the right ordinal • Same but track input arguments instead

Got it! Since I’m using re-frame-http-fx, I think I can use the :on-request handler to track requests (as explained in the link below), and if a new request comes in, I can call the abort method on the previous one. Does that sound right? https://github.com/day8/re-frame-http-fx#optional-handler-for-on-request

Yeah. You just have to make sure that you're aborting requests for that specific component for that specific task and not something else.

depending on the result size you send back, I'd personally probably store each request and match that up with the current input, then clear all the results on blur or selection or whatever. that way when a user backspaces, if the results were there it'd show immediately.

Sounds like a good idea. Thanks!

Just curious, how would you track the order of requests in the second approach? I was thinking of using a timestamp to see if the response is too old and should be ignored. Is that what you had in mind?

I mean, the “Track the ordinal of the request and only respect the results of the request with the right ordinal” option.

Something like this would be really easy to deal with:

{:autocomplete {"a" [<results>]
                "abc" [<results>]}}

@hprange Nah, just have an integer value somewhere and only increment it whenever a new request comes in. The idea is stolen from here, where that integer is named "epoch": https://lucywang000.github.io/clj-statecharts/docs/integration/re-frame/#discard-stale-events-with-epoch-support

But for typeahead, I actually like Omar's solution with storing the results.

Yeah, it seems like a solid choice, especially because we can cache the results if the user goes back and edits their input.

I'd just make sure that it's a limited LRU cache or something similar.

Got it! Now I’ve got what I need to make an informed decision. Thanks for the assistance, folks!

In the event that dispatches the http effect, you increase a counter in app-db and you include that counter in the event vector that is dispatches when the http event completes. If the count in that event vector and app-db match, you use the returned value, otherwise discard it. EDIT: Sorry, I hadn’t read the whole thread (forgot to scroll 🤯 ), I was describing the same solution that @p-himik linked to.