Fork me on GitHub
#re-frame
<
2018-09-06
>
danielneal07:09:36

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

danielneal07:09:02

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

danielneal07:09:12

I think that was what I was missing

danielneal07:09:21

Before I started adding them in

Hukka13:09:34

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.

Hukka13:09:58

I found some solutions for debouncing, https://github.com/Day8/re-frame-http-fx/issues/3 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?

lwhorton14:09:31

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
b2berry21:09:55

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