Fork me on GitHub

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.


track is a bit like an automatic memoization, isn’t it?


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


and just always returns the result it computed, once


Hello All - anyone got a good recommendation for a calendar component in Reagent?


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