This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-30
Channels
- # arachne (5)
- # beginners (42)
- # cider (35)
- # cljs-dev (25)
- # cljsrn (2)
- # clojure (107)
- # clojure-dev (32)
- # clojure-finland (2)
- # clojure-greece (3)
- # clojure-italy (6)
- # clojure-nl (7)
- # clojure-spec (27)
- # clojure-uk (45)
- # clojurescript (152)
- # core-async (3)
- # cursive (26)
- # data-science (4)
- # datomic (33)
- # defnpodcast (1)
- # duct (12)
- # editors (3)
- # emacs (6)
- # events (5)
- # fulcro (6)
- # jobs (1)
- # lein-figwheel (9)
- # off-topic (7)
- # onyx (7)
- # re-frame (1)
- # reagent (9)
- # reitit (31)
- # shadow-cljs (130)
- # slack-help (1)
- # spacemacs (53)
- # tools-deps (55)
- # yada (4)
Hi all, was trying to create a dom element resize signal that other subscriptions could depend on. First stab was something along the lines of:
(r/after-render
(fn each-render []
(when (boolean @<-node)
(let [n @<-node]
(->> (.-offsetWidth n)
(reset! <-size-signal))))
(r/after-render each-render)))
Essentially this polls every animation frame and produces a signal for the element size. It's relatively simple, cheap and it works. But it appears to play havoc with re-frame-10x. re-frame-10x generates many thousands of traces (not sure why) and fails to update app state and subscription results. If you remove those lines of code, re-frame-10x behaves as expected. I'm wondering if:
1. I'm doing something incredibly obtuse with the recursive call to each-render
.
2. Is this a bug in re-frame-10x? Is there a reason the above formulation might throw it so out of wack?