Fork me on GitHub

Whoa I never saw that but kind of ended up evolving that same structure


The db layer is important for things common to handlers subs and events


I think that was what I was missing


Before I started adding them in


Anyone have a good solution to debounce and match requests? Usecase is autocomplete, where the user might type faster than the replies come in. So should send requests only after some delay that's a bit more than typing speed, and when replies come back should not override with older data. Bonus points if the whole tcp connections for stale requests get killed.


I found some solutions for debouncing, discussing aborts, and none that readily match responses to requests (though this wouldn't be too difficult to implement). Though I wonder if it's possible to type so quickly, that there are multiple onChange events resolved at same time and they are not resolved FIFO?


the underlying closure http lib (or native browser http xhrio) both support cancellation. i always write my own :http effect that can be configured via {:http {:cancellable? true}}. you can easily wire up something to store in-flight requests, then check against those in-flight for an opportunity to cancel if another event comes along that would supersede the results

👍 4

What are folks using for drop-in datepickers in re-frame?