Fork me on GitHub
#fulcro
<
2021-12-04
>
sheluchin15:12:55

I'm finding my RAD report is a little slow to render initially. After adding in some print statements for debugging, I noticed that it tries to render 3 times before current-rows is populated. I've followed the advice here to prevent early routing, but my issue persists https://book.fulcrologic.com/#_setting_the_route_early. I'm guessing it's a bug in my code somewhere, but not totally sure. Does it seem like something on my end? Any advice for diagnosing/fixing?

tony.kay15:12:02

Is this in a prod build or dev? Dev will almost certainly be slow for some reports because of all the dev overhead,

sheluchin15:12:42

It is indeed a dev build. So the multiple renderings isn't a red flag?

tony.kay01:12:08

multiple renderings has to do with the timing of transactions. Any number of renderings could occur. One on trigger of event (txn), one at optimistic side of load, one at end of load. The optimizations of React make that cheap, but there is no getting around the fact that you must render each of those in order to show any state change (e.g. busy flag on/off). The rendering is debounced to 60fps, so mutiple renderings often happen in dev because there’s a lot of lag due to dev tooling. In prod a quick succession of such renderings would collapse (often) to just one.

gratitude-thank-you 1
genekim05:12:17

I noticed this happening for a RAD report that had 3500 items in it — I think it was around 200ms to render a frame. But in production mode, the issue went completely away, with renders below 16ms. Upon some study in Fulcro Inspect, I was ab le to confirm that the time was in the (truly awesome) Guardrails code, presumably checking the type integrity of the big state maps, that was being triggered as I was doing a map some-fn rows.