5 ms·
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
by jbaudanza 7y ago
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.
- chacham15 7y agoThe 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.
- jbaudanza 7y agoOK 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.
- joe_hoyle 7y agoThe "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.
- danabramov 7y agoThe 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.
- jbaudanza 7y agoWhen 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?
- danabramov 7y agoNo. 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.
- erikpukinskis 7y agoRender 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.
- jbaudanza 7y agoThe new suspense API works by throwing Promises when the data isn't ready yet.
- erikpukinskis 7y agoI’m not sure what you mean by “throwing promises”... You mean returning unresolved promises? Or returning rejected promises? Or just throwing an error?
- acemarke 7y agoLiterally, _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.