This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-26
Channels
- # aleph (3)
- # beginners (98)
- # boot (24)
- # cljs-dev (13)
- # cljsrn (16)
- # clojure (97)
- # clojure-dusseldorf (2)
- # clojure-italy (2)
- # clojure-losangeles (2)
- # clojure-russia (48)
- # clojure-spec (28)
- # clojure-uk (79)
- # clojurescript (79)
- # community-development (2)
- # cursive (4)
- # datomic (35)
- # duct (1)
- # events (1)
- # fulcro (43)
- # heroku (1)
- # jobs (1)
- # lein-figwheel (2)
- # luminus (1)
- # lumo (12)
- # nyc (1)
- # off-topic (6)
- # om (1)
- # pedestal (7)
- # portkey (9)
- # proton (1)
- # re-frame (45)
- # reagent (27)
- # rum (2)
- # shadow-cljs (78)
- # spacemacs (3)
- # specter (2)
- # testing (2)
- # vim (41)
I have strange things happening on a function that draws a chart using D3. Let’s say we have a function draw!
which receives a dom-node and then draws a chart. What happens is that the related Reagent component can update while it’s drawing, so we have a concurrency problem.
Don’t know if there is an elegant way to solve this. Maybe delegate the drawing to a Re-frame event.
I think it shouldn't happen unless you use web workers or setTimeout
or a similar mechanism inside draw!
.
Do you do anything related to setTimeout
or web workers inside draw!
? If not, do you call some D3 functions? Probably they include some code that does use setTimeout
.
I assume React waits for an update if a previous one is still in progress? Never really thought about this until now
@borkdude maybe this page could help you out? https://github.com/Day8/re-frame/blob/master/docs/Using-Stateful-JS-Components.md
The annoying thing is also when something goes wrong in the draw!
function which does a lot of d3 interop, I don’t see any errors in the console
that sucks 😕
Guess you’ll have to guard against error-causing values? (I’m guessing that this is what causes the errors)
At least you can rule that spectrum of errors our by speccing the args or something like that
Just a wild guess, but the absence of errors in the console when the errors are happening could be caused by js promises that don't have a final handler that logs these errors.
@borkdude Some resources are listed here: https://github.com/d3/d3/wiki#resources
I think I found where it went wrong. d3 adds .-x and .-y values to my clojurescript data. A lot of the same hash-maps will be re-used on an optimistic update… except for one or two. Those have .-x nil. And then the d3 algorithm doesn’t recompute all of those .-x values and gets confused. The solution is to clear them. Mutable data on immutable hash-maps!
sounds like you're using something not the way it's intended to be used
I assume it doesn't expect a PersistenArrayMap/PersistentVector though?
It expects an array of data and some functions that can get values out of that data. That’s what I did. I just passed an array of hash-maps + some functions like :foobar
which works just fine.
But not when you run it a second time, because it added properties to those maps… which is an implementation detail to me
Damn muties