Hacker News Reader

Comment by jbaudanza | Hacker News Reader

As I understand it, the principal behind the VDOM is that renders are cheap and the cost is is negligible compared to real DOM updates. If this is the case, why do you need to keep concurrent VDOMs in memory at once? Why can't you just render the VDOM you need when you need it? I think this is where I'm getting lost on this new feature.

View on HN

The thing that’s slow is arbitrary JS code people write in components. VDOM is not the point there. We want to make arbitrary JS code people write non-blocking, by using components as the “units of work” where we can yield.

Really though, you’re over focusing on the CPU part. The IO part is much more interesting.

When you say "yield", you're talking about render functions throwing a Promise, right? Is there another kind of yield that arbitrary JS code people write in components can do that I'm missing?

No. I mean that we yield between calling different components. We can’t pause a giant blocking call in a render but we can amortise “death by a thousand cuts” across many components.

Render functions, to my knowledge, can’t return a promise.

(And you don’t throw a promise, you return and reject it)

The issue at hand is fully synchronous render functions that, e.g., go through a giant list of objects and call a bunch of other render functions on each one synchronously.

This change allows that one function to finish, and interaction to continue before all the children render.

The new suspense API works by throwing Promises when the data isn't ready yet.

I’m not sure what you mean by “throwing promises”...

You mean returning unresolved promises? Or returning rejected promises? Or just throwing an error?

Literally, _throwing_ a Promise.

React will catch promises thrown during rendering, and treat that as a request to "suspend" the component and come back to it later once the promise has resolved.

The problem is that you want to be able to abandon work (e.g. due to new data coming in that invalidated the previous data). So, what you need is to go back to the last complete render and start applying your changes from there. If there were partial changes applied from before, you cant just skip the middle update.

OK I've spent all morning reading about this. I think that when you say "work", you're talking about the work of doing DOM updates. Rendering a VDOM is still considered cheap.

The "work" is the arbitrary JavaScript in the `render()` function. In Concurrent mode, a `render()` function that renders 1000 children can now be interrupted "between" renders of all those children.

It's akin to doing `Header( LoginLink( GetLoginName() ) )` versus

``` Header(); check_for_interrupt(); LoginLink(); check_for_interrupt(); ... ```

The interrupt between rendering components (pieces of work) can now cancel the whole render operation (because say, the parent component has now been updated / wants to be re-rendered), or can pause the render tree while something like a high-priority animation frame is rendered.

Reply on news.ycombinator.com