This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-10-26
Channels
- # announcements (9)
- # babashka (98)
- # beginners (53)
- # boot (2)
- # calva (19)
- # cider (58)
- # clj-kondo (4)
- # cljdoc (11)
- # clojure (49)
- # clojure-dev (12)
- # clojure-nl (3)
- # clojure-uk (4)
- # clojurescript (42)
- # core-async (6)
- # cursive (9)
- # data-science (1)
- # fulcro (23)
- # jobs-discuss (2)
- # nrepl (30)
- # off-topic (42)
- # pedestal (6)
- # re-frame (8)
- # reitit (7)
- # remote-jobs (2)
- # shadow-cljs (134)
- # specter (1)
- # vim (13)
@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.
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)
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
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
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