@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 defined 🙂

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

Hm, maybe? The code looks like it should work though

https://github.com/JedWatson/react-codemirror/blob/master/src/Codemirror.js#L65

It sets the value of the internal code mirror instance to the prop received, if I read that correctly

looks like you're right

https://github.com/JedWatson/react-codemirror/issues/121 ?

🙂

Whoops 😄

Haha, I actually checked the issues, but apparently missed that

Thanks!

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

Right

in normal cases it's also significantly slower

ok, going to try the 2.0 then 😉

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

https://github.com/tonsky/rum#updating-components-manually

I guess for small components that's fine

ah

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

ah, ok

entirely re-mounting requires some hackery, like tricking react into thinking it's a different component, or using a different key

yeah, would want to avoid that

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

nice, thanks again for the thorough help and explanations!

what am I doing wrong here with r/track?

(defonce track-foo
  (reagent/track (fn [] (let [x @(a-ratom)] (do-something x)))

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