Fork me on GitHub
#re-frame
<
2019-10-26
>
isak04:10:08

@lilactown what if you needed to listen to one more signal to compute <expensive thing>? You'd then need to modify the components controlling the state the signal is derived from to have the same debouncing logic, no? The thing I posted above doesn't have that problem.

isak04:10:46

Another thing - what if you wanted the computed thing to be able to visualize whether it is up to date or not? (also solved above)

lilactown05:10:38

I missed that earlier.

lilactown05:10:08

In my specific case, the calculations were happening within the event handler. Ideally they would be done in a subscription, in which case your debounced sub would also work

lilactown05:10:54

It also can depend; sometimes you want immediate recalc for certain actions (ex. New data), but for user interaction to debounce because the stream of updates is much faster. Not sure which is better, but that is a very good option if your depending on multiple streams with high throughput

isak05:10:58

Interesting, hadn't thought of that case. In my case, I think it was similar to one you mentioned - aggregation/filtering/pivoting in response to user interacting with checkboxes, switches, etc

lilactown05:10:09

Yeah. I think it's 6 of one, half dozen of the other. Yours is probably more re-frame-esque

isak05:10:01

Hmm yea, though not sure if mine is re-frame-esque, since I think dispatching from subscriptions is generally frowned on