This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-12
Channels
- # beginners (102)
- # boot (5)
- # cider (1)
- # cljs-dev (15)
- # cljsjs (1)
- # cljsrn (20)
- # clojure (104)
- # clojure-austin (1)
- # clojure-europe (8)
- # clojure-italy (39)
- # clojure-nl (17)
- # clojure-spec (38)
- # clojure-uk (23)
- # clojurescript (34)
- # cursive (31)
- # data-science (5)
- # datomic (3)
- # emacs (28)
- # joker (1)
- # kaocha (5)
- # klipse (1)
- # leiningen (1)
- # off-topic (66)
- # quil (4)
- # reagent (35)
- # ring-swagger (1)
- # rum (1)
- # shadow-cljs (121)
- # test-check (1)
- # tools-deps (33)
- # uncomplicate (2)
- # vim (15)
- # yada (1)
is there a big trade off on initial rendering on complex page with reagent, comparing to vanilla React.
I have a page which render a lot divs, I think it's a bit slow, but I don't know where is the problem. I also using (cljs generating css), maybe that's the problem.
do u have a lot of state? is it locally or on production too? are u using vanila reagent?
@lepistane I'm using reagent with re-frame, it has states but I care about the initial rendering. the state will only have small changes, so after the first time, it's pretty fast. It's slow on old mobile phone but fast on well performance devices.
the only problem i've had with reagent and re-frame and slowness was when i had table with around 100 cells
when i say vanila - i mean re-frame/reagent custom table implementation without Antizer
i think that version of Antizer didn't know to change state of only 1 cell but it updated all cells even if only 1 changed i know a lot of people have landing pages done in cljs and initial load should be on pair with React
I wondering will nested components cost a lot? will these two usage have big difference?
(defn foo [child]
[:div child])
(defn bar [child]
[:div child])
(defn baz []
[:div])
[foo [bar [baz]]]
and
[:div [:div [:div]]]
in my head, I'm thinking if each layer is a component, it have to compare the state when state changes at its parent.
but some friend told me, not each component, each vdom need compare the state which passed. I'm confused now.
it depends how u structured the code. I suggest u have a look at re-frame docs (on github) they do very good job at explaining what is going on also https://reagent-project.github.io this should explain the referencing of the state (subscribes)
some things from React don't translate to reagent/re-frame directly (and they shouldn't)
@doglooksgood if you’re worried about performance, I would use something like Chrome’s performance analyzer to look at what might be taking up a lot of time
you could also try using the beta React DevTools profiler. I haven’t tried it with Reagent, but it might be able to illuminate what is React vs. what is Reagent vs. what is your code
IME, the initial rendering can take a little longer while developing because you load each namespace as an individual js file
https://github.com/roman01la/uix/blob/master/README.md#hiccup-interpretation uix is 1.5x slower than vanilla react, but easily 2x faster than reagent. That would place reagent at 3x slower than vanilla react.
you’d want to profile your application to see if that’s actually what might be causing a performance issue
hiccup interpretation happens frequently and is slower than using raw react, but is still incredibly fast and should be assessed along with the rest of your application code
I’m not exactly making excuses for hiccup interpretation slowness, as it is an unavoidable cost to using reagent and therefore should be made better. but most projects will benefit from profiling and optimizing their application before they will find reagent hiccup interpretation the direct cause of slowness
saying that reagent is “slower” is also not exactly right; it’s render might be slower, but in some cases helps lead to architectures that are inherently faster than vanilla React