This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-11-14
Channels
- # beginners (33)
- # boot (38)
- # clara (21)
- # cljs-dev (1)
- # cljsjs (2)
- # cljsrn (12)
- # clojure (230)
- # clojure-argentina (1)
- # clojure-brasil (3)
- # clojure-dusseldorf (4)
- # clojure-france (9)
- # clojure-italy (1)
- # clojure-russia (123)
- # clojure-spec (46)
- # clojure-turkiye (1)
- # clojure-uk (60)
- # clojurescript (83)
- # core-async (6)
- # cursive (10)
- # datascript (19)
- # datomic (28)
- # defnpodcast (1)
- # emacs (7)
- # figwheel (7)
- # fulcro (29)
- # leiningen (29)
- # lumo (9)
- # off-topic (14)
- # om (1)
- # onyx (25)
- # pedestal (1)
- # protorepl (3)
- # re-frame (10)
- # reagent (41)
- # ring-swagger (11)
- # shadow-cljs (10)
- # testing (5)
- # unrepl (3)
- # vim (3)
@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
is Reagent making multiple instances of the same Form 3 component (and maybe other forms) as actually separate classes as well?
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
I just did a test with 500 h1 elements updating a new random number 60 times per second, with no lag
Hm, I can't imagine a lag from just 100 items unless each list item is a complex component as well
until the moment the list is repainted, in that moment buttons classes using the same atom update also
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
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?
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
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
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