Hacker News Reader

Comment by danabramov | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com