Fork me on GitHub

@mbossenbroek this is expected behaviour. I reported this a long time ago and this were the answers I got:


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


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


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


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


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


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


How big is the list?


Are you using a React key on each list item?


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


Feel free to post some code


How long is the lag?


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


Are the list items doing calculations?


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)


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


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


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.


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


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


here is an example


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.


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


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


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


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


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


that could be your lag right there


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


I like your idea with component-did-update


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


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)


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


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


thank you ajs


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


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