This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-03
Channels
- # announcements (12)
- # babashka (36)
- # beginners (126)
- # calva (26)
- # cider (10)
- # clj-kondo (71)
- # cljdoc (3)
- # cljsrn (2)
- # clojure (232)
- # clojure-australia (1)
- # clojure-europe (11)
- # clojure-france (20)
- # clojure-nl (4)
- # clojure-norway (1)
- # clojure-serbia (4)
- # clojure-uk (6)
- # clojurescript (62)
- # conjure (5)
- # cursive (12)
- # data-science (1)
- # datomic (57)
- # deps-new (1)
- # duct (3)
- # emacs (5)
- # events (8)
- # fulcro (6)
- # graalvm (5)
- # helix (3)
- # jobs (6)
- # jobs-discuss (3)
- # kaocha (4)
- # lsp (128)
- # malli (12)
- # missionary (22)
- # off-topic (1)
- # pathom (7)
- # polylith (27)
- # quil (1)
- # re-frame (20)
- # react (9)
- # reitit (12)
- # releases (8)
- # remote-jobs (3)
- # sci (3)
- # shadow-cljs (9)
- # spacemacs (10)
- # tools-deps (7)
- # vim (7)
- # xtdb (14)
I’m trying the new :fx
feature and the doc states that within :fx the ordering is sequential
. I’m have two effects in my :fx handler
:fx [[:dispatch [:a 1]
[:dispatch [:b 2]]
The issue is that :a
is and fx
effect and it emerges it’s own sub effects. As I can see from the logs - those sub-effects are executed after :b
(defn what-a-did [db]
{:db (... db ...)
:fx [[http ...] [other-actual-effect ...]]})
(defn what-b-did [db]
{:db ....
:fx ....})
(rf/reg-event-fx
::event-name
(fn [{:keys [db]} _]
(let [composed (exercise-for-the-reader what-a-did what-b-did)]
(composed db))))
I’ve got an HTML color picker and it fires events very rapidly when the user is changing the color. What’s the best place to debounce this change?
Normally, I’d debounce in the UI on-change
handler with goog.functions/debounce
so I don’t have the overhead of having a million events being processed. Is that frowned upon? It feels less pure based on the docs I’ve read about re-frame, but it seems more pragmatic than debouncing within the even handlers.
(defn color-input [label {:keys [key value]}]
(let [on-change (fn [^js evt]
(let [v (-> evt .-target .-value)]
(re-frame/dispatch [::events/update-user-preference key v])))
state (reagent/atom {:on-change (gfun/throttle on-change 200)})]
(fn [label {:keys [key value]}]
[:div.form-group
[:label {} label]
[:input {:type "color"
:value value
:on-change (:on-change @state)}]])))
That’s what I’m thinking, it seems to work as expected and I think I need to put the throttled function into local state to avoid a memory leak. It’s been a while since I’ve used React.Dispatch-debounce and dispatch-throttle are built into reframe, you could either use those or look at the implementations for reference
They are not built into re-frame.
:dispatch-debounce
is offered by e.g. this lib: https://github.com/7theta/re-frame-fx
No idea what offers :dispatch-throttle
- I've never seen it.
My mistake, I remember Daniel talking about it and have used it on projects but seems like they decided not to put them in the core library https://github.com/day8/re-frame/pull/258, anyway that link has the implementations and discussions
@U2FRKM4TW throttle is much like debounce, expect it fires the first an last event whereas debounce only fires the last event
at least that’s the goog.functions/throttle