Main thread is locked up during bootup
See original GitHub issueHeya!
So I’ve got a sample app which sort of resembles a news article with user comments. When I have – say – 500 comments (<Comment/>
), each with up-vote and down-vote buttons (<VoteButtons/>
) I see the boot up on a Nexus 5X take somewhere in the region of 500ms:
What I’d like to do instead is make use of requestIdleCallback
to spread the load out a bit. I’m fine with the SSR code making the buttons and so on inert (as in, I can handle that separately) but I’m mostly concerned that there doesn’t seem to be any way to spread out the initial diff and so on into smaller chunks. On an older phone that’s likely to be a few seconds of main thread lock-out where someone wouldn’t be able to scroll or interact in any way.
I had a quick look over the source, and I see there’s an ASYNC_RENDER flag (which looks stellar because I can hook in rIC there via options.debounceRendering
), but it seems like that only applies for updates rather than the initial create-this-from-the-DOM boot that I get with SSR… well, I imagine it applies to all initial renders it’s just that the diff’ing done from the SSR’d version looks to be causing some slowdown.
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (4 by maintainers)
Top GitHub Comments
Heads up to others: the crazy trace here was actually an SSR hydration bug. It has been fixed in
7.0.3
!Here’s a contrived example showing the difference between
7.0.2
and7.0.3
, where I’ve added call count tracking todocument.createElement
to verify that SSR was broken for certain component types at the root, and that it has been fixed (0createElement()
calls):7.0.2: http://jsfiddle.net/developit/sbdjevmh/
7.0.3: http://jsfiddle.net/developit/1wh26gy5/
The spirit of this bug was in the fact that updates were atomic and blocking, meaning that they were not interruptible or prioritizable by the browser processes. While I welcome Preact X’s hydration over render, it is nonetheless problematic for any virtual DOM implementation if it can not be parallelized or prioritized by the browser. I appreciate, however, that that’s a significant departure from the current world and approaches, but I also didn’t feel that what you described met the original intent of the bug I raised.