This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-13
Channels
- # beginners (71)
- # boot (61)
- # clara (49)
- # cljs-dev (9)
- # cljsjs (2)
- # cljsrn (5)
- # clojure (55)
- # clojure-android (1)
- # clojure-italy (4)
- # clojure-spec (39)
- # clojure-uk (56)
- # clojurescript (69)
- # cursive (5)
- # data-science (1)
- # defnpodcast (6)
- # devcards (1)
- # duct (12)
- # figwheel (3)
- # fulcro (18)
- # leiningen (35)
- # lumo (19)
- # midje (1)
- # off-topic (22)
- # om (3)
- # onyx (23)
- # portkey (3)
- # re-frame (20)
- # reagent (23)
- # ring-swagger (6)
- # shadow-cljs (119)
- # specter (7)
- # unrepl (25)
if a component needs some data nested in central app state, would it generally be considered wise and more performant to create different reactions for each piece of nested data and then only refer to those reactions in components? i'm assuming this is better performance than dereffing the whole app state in the components
@ajs, your assumption is correct
but personally I don't bother until I see performance issues
then it's pretty easy to clean up unnecessary re-renders
remember that rendering performance in JS land is usually not the main bottleneck
and react makes sure that if the element trees stay the same, the DOM doesn't need to be updated
the first principle then is to make sure the element trees are stable, i.e. essentially add keys where necessary
but that is the same in reagent and in other ways of using react
has anyone tried replacing the hiccup in reagent with the hiccup from sablano? I saw a guy report a 2x speedup; other libraries like Rum use sablano under the hood to provide this facility, i wonder why reagent didn't also do this
i guess reagent's function-based vs macro-based workflow was the reason, and wrapping the hiccup in html
doesn't meet its standard for elegance
@ajs >I saw a guy report a 2x speedup; other libraries like Rum use sablano under the hood to provide this facility It’d be interesting to actually see what the codebase was like that had that improvement
what is the purpose of track!
-- i understand track
just fine (it's cool) but I don't understand when you'd need the eager version
track
is great when you want a computed value, because somewhere down the line you will deref the result and thus the computation will run. Where as track!
is great when you want a side-effect, which you won’t ever deref because you don’t care about the returned value.
Yes. So both track
and track!
will only be re-executed when it’s “input” atoms have changed. track
additionally is also only rerun when it’s deref
’d while track!
is rerun right when the input atoms change.
and if you didn't have any input atoms, then you could just use track as a way to wrap a calculation in a way that it never runs again
For calendar display, or for a datepicker?
For calendar display, or for a datepicker?
Hi - question about ordering of :component-did-update
calls. From what I can find in the react docs, it indicates that these should be called in an order that matches the nesting of components. For example if component A contains B contains C, it should call :component-will-update
on A, then B, then C, and then :component-did-update
on C, then B, then A. Instead I'm seeing will-A, did-A, will-B, did-B, will-C, did-C. I was hoping to find out if that were in fact the expected behavior before putting together a repro case.
fwiw, I do see this nesting behavior with the *-mount
methods, just not the *-update
ones