Fork me on GitHub
#reagent
<
2017-11-13
>
ajs13:11:53

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

pesterhazy13:11:37

@ajs, your assumption is correct

pesterhazy13:11:52

but personally I don't bother until I see performance issues

pesterhazy13:11:39

then it's pretty easy to clean up unnecessary re-renders

pesterhazy13:11:57

remember that rendering performance in JS land is usually not the main bottleneck

pesterhazy13:11:32

and react makes sure that if the element trees stay the same, the DOM doesn't need to be updated

pesterhazy13:11:15

the first principle then is to make sure the element trees are stable, i.e. essentially add keys where necessary

pesterhazy13:11:37

but that is the same in reagent and in other ways of using react

ajs14:11:30

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

ajs14:11:17

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

mikerod14:11:10

@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

ajs14:11:38

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

kasuko19:11:45

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.

ajs19:11:42

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

kasuko19:11:07

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.

ajs20:11:55

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

ajs20:11:08

and just always returns the result it computed, once

maleghast16:11:53

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

worlds-endless17:11:35

For calendar display, or for a datepicker?

mbossenbroek23:11:46

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.

mbossenbroek23:11:14

fwiw, I do see this nesting behavior with the *-mount methods, just not the *-update ones