Fork me on GitHub
#reagent
<
2017-11-14
>
thheller06:11:11

@mbossenbroek this is expected behaviour. I reported this a long time ago and this were the answers I got: https://github.com/facebook/react/issues/2763

ajs09:11:07

is Reagent making multiple instances of the same Form 3 component (and maybe other forms) as actually separate classes as well?

ajs09:11:22

that would seem to be the case in my logging, but i'm a little surprised by that

tomaas10:11:02

Hi, there are 4 button components (only one can be active at a time) as a list of items. Buttons and list depend/use the same reagent atom. Now when it changes, the final dom updates once, so I see the lag on buttons' state changes due to the more work needed to render the list's html. What would be the correct way to solve this? Creating two separate atoms, setting the buttons' first and then, after a timeout(0), dispatch a reset! for a list's atom seems a pretty ugly and bad idea. Thanks in advance

ajs11:11:23

@tomaas a lag on updating just 4 buttons? I find that surprising

ajs11:11:01

I just did a test with 500 h1 elements updating a new random number 60 times per second, with no lag

tomaas11:11:03

it's because the updated list and updated buttons show all at the same time

ajs11:11:21

How big is the list?

ajs11:11:11

Are you using a React key on each list item?

ajs11:11:29

Hm, I can't imagine a lag from just 100 items unless each list item is a complex component as well

ajs11:11:40

Feel free to post some code

ajs11:11:16

How long is the lag?

tomaas11:11:52

until the moment the list is repainted, in that moment buttons classes using the same atom update also

ajs11:11:07

Are the list items doing calculations?

tomaas11:11:19

so I want to know if this is a logical problem. In this case i'd like the user to see the buttons updated immediately and then the list, the time it takes (because the list updates fast knowing it's a list with complex components, having to be reordered etc)

tomaas11:11:22

So the only solution I see is to duplicate that atom, use one to update buttons, and then setTiemout(0) to reset! the other (the one the list uses). This way the dom is updated in two steps

tomaas11:11:27

it does, not complex computations but just retrieving data by key, formating, etc

ajs11:11:39

Without seeing code, I don't know. I've never seen a bottleneck like you describe unless there is expensive operations separate from the React workflow. Just updating some buttons and a small list should be fast.

ajs11:11:08

But if the components are also doing heavy computation during rendering, that can produce lag.

p-himik11:11:13

@tomaas Is it possible to move these buttons to their own component and pass the same atom to it?

tomaas11:11:23

here is an example

tomaas11:11:50

so, when on-click is triggered and active-btn is reseted, the changed,final, visible html updates the buttons and list at the same time.

tomaas11:11:22

which is something i'd like to separate. I want to user to see updated button state immediately and the changed list ~0.7 secs later (which is what it takes to render 100 item-view-comp component items

ajs11:11:07

one way to do that would be to have the buttons respond to a different part of the app state, and then have your button component update the list state after button rendering with component-did-update, which would then trigger the list update

ajs11:11:18

in other words, the buttons render, and when they are done, they change the rest of the app state to trigger the list render

ajs11:11:48

incidentally in your a-list where is the react key?

ajs11:11:57

also the first expression in a cond pair should be a predicate. you have a sort-by there, which I don’t understand; it will do that sorting on every single element in your list, i don’t think that’s what you mean

ajs11:11:05

that could be your lag right there

tomaas11:11:05

yeah, sorry I forgot map-indexed params as well as predicate making this example

tomaas11:11:24

I like your idea with component-did-update

ajs11:11:30

i still suspect that a rendering workaround is probably not as useful an effort as optimizing whatever work is being done to recreate your list. in my experience, it is usually better to solve an algorithm problem than a rendering problem

tomaas12:11:19

the work is a simple sort-by of the list data, and then list item component is a box with some flex css, painting inside list item attributes (~10), and an image (32x32)

tomaas12:11:37

I can't optimize anything there, already tried..unless I put there the a div with static texts ~0.7 secs is taken to update the dom with 100 items

tomaas12:11:22

but yeah I never even thought to begin manipulate render orders, etc

tomaas12:11:28

thank you ajs

ajs12:11:36

the lifecycle methods do indeed exist for a reason so sometimes there is no other way

ajs12:11:17

unfortunately in Reagent when you decide to add a lifecycle method, you have to rearrange the whole component function, since you can’t just tack it on like in Rum or Om