This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-13
Channels
- # bangalore-clj (1)
- # beginners (40)
- # boot (22)
- # clara (19)
- # cljs-dev (265)
- # clojure (160)
- # clojure-dev (6)
- # clojure-italy (5)
- # clojure-russia (47)
- # clojure-spec (10)
- # clojure-uk (63)
- # clojurescript (88)
- # core-async (8)
- # cursive (54)
- # datomic (48)
- # emacs (32)
- # garden (3)
- # graphql (29)
- # hoplon (54)
- # jobs (1)
- # klipse (4)
- # luminus (5)
- # lumo (21)
- # mount (5)
- # off-topic (16)
- # om (2)
- # pedestal (10)
- # play-clj (1)
- # portkey (32)
- # re-frame (21)
- # reagent (48)
- # rum (1)
- # spacemacs (4)
- # sql (3)
- # unrepl (5)
@mattgeb see ref callbacks: https://presumably.de/reagent-mysteries-part-3-manipulating-the-dom.html
@mrchance is state
a ratom rather than a clojure.core/atom?
@pesterhazy Yes, it is. See the example I posted above, the div updates
@mrchance you're not showing where the atom is def
ined ๐
ah but maybe that's just the way code mirror works?
sort of like "uncontrolled components", i.e. when you're using input with :default-value
: https://facebook.github.io/react/docs/uncontrolled-components.html
It sets the value of the internal code mirror instance to the prop received, if I read that correctly
looks like you're right
you could work around that by manually re-mounting the whole thing
hm, the ticket mentions that someone started react-codemirror2, maybe I'll try that first
But that's actually something I've been wondering, how much different is the performance on remounting everything instead of updating components through ratoms?
I guess it's just the additional overhead of running the render methods for all components?
in the case of codemirror, it's probably a significant overhead
because it needs to tear down/set up its state
build the dom etc
in normal cases it's also significantly slower
you want to avoid remounting in general
note that comprehensive updates are fine
usually that's fast enough IME
That's what I thought. I read the rum intro, where they also recommend that as an easy way to re-render
can you link to the document? that's interesting
but running mount again doesn't necessarily un-mount and re-mount
if the component is the same, it only triggers an update
react is smart like that
entirely re-mounting requires some hackery, like tricking react into thinking it's a different component, or using a different key
But it's probably still slower than only updating children deeper in the tree directly, right?
that's the optimal case yeah
My understanding was that the most performant way is to dereference ratoms as late as possible
that's right
what am I doing wrong here with r/track?
(defonce track-foo
(reagent/track (fn [] (let [x @(a-ratom)] (do-something x)))
when I manually call a swap! or reset! to a-ratom
the tracking function doesnt run .. but interestingly if I reload the code via figwheel, then the track triggers?maybe atom shouldn't be in parens? @lwhorton
yeah- that seems weird, unless a-ratom
is a function returning an atomโฆ
also according to https://reagent-project.github.io/news/news060-alpha.html the result of calling (r/track ...) must be derefed, e.g. in the component