Main thread is locked up during bootup

[paullewis]

Heya!

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.

[developit]

This is a case I hadn't thought of (progressively upgrading from inert DOM), and definitely seems like a nice match for the existing async rendering option if it can work.

[developit]

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 and 7.0.3, where I've added call count tracking to document.createElement to verify that SSR was broken for certain component types at the root, and that it has been fixed (0 createElement() calls):

7.0.2: http://jsfiddle.net/developit/sbdjevmh/

7.0.3: http://jsfiddle.net/developit/1wh26gy5/

[thysultan]

you could also do something like

class Comments extends Component {
	constructor () {
		super();
		this.state = {
			comments: [],
			array: ['1', '2', '3']
		}
	}
	componentDidUpdate () {
		// incrementally adds comments
		if (this.state.array.length !== 0) {
			requestIdleCallback(() => { 
				this.state.comments.push(<Comment>{this.state.array.pop()}</Comment>);
				this.forceUpdate();
			});
		}
	}
	render (props, state) {
		// start of with a blank slate
		return (
			<div>{this.state.comments}</div>
		)
	}
}

[marvinhagemeister]

For quicker SSR bootup times we introduced a fast path the user can opt into in Preact X by calling hydrate() instead of render() on SSR'ed content. The hydrate() function will only attach event listeners and won't modify the DOM in any other way. So for it to work the SSR'ed content must match the initial vnode tree.

Closing as the issue is resolved in newer versions of Preact 🎉

[paullewis]

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.

[marvinhagemeister]

I'd love to see some current numbers highlighting the problem. In my personal experience the overhead of hydrate() in Preact X is minimal, leading to a nearly non-blocking experience (technically it's still blocking under the hood).

Nonetheless I can see that there is room for discussion here.

EDIT: Removed most of the labels until we have an actionable task.