Description
I want to clarify motivation behind current implementation of updates in components.
As I understand getting template result is done in RAF for batching then next RAF is scheduled for commit or DOM updates, then next RAF for effect hooks.
There are few things that I think might cause problems, but may be that I am not seeing the whole picture:
- read and commit could happen in the same phase, since we already got the results in previous RAF but haven't painted anything. Is it for splitting up the work, aren't microtasks better for batching?
- in commit phase which is scheduled in second spin of render loop, DOM is updated and so do props of components that will start their own update schedule, so for each nesting 2 frames are needed to render one change.For example, passing down the prop from top component that has 30 levels of nested components, that also change as a result of property changes it means we get 60 frames to render whole tree which might take 1 second at best:)
In my imagination all the prop updates need to be batched and then single run to read whole tree and only after one RAF to update whole tree, pretty much how I imagined React to work before fiber.
And I would prefer webcomponents to be rendering syncronously without scheduling since they are leaf nodes, unless there are some exceptional needs.
And virtual components, ones that wrap many of those leafs, need to have these scheduling mechanism, but they have to work in sync, don't schedule another RAF if you already scheduled one.
From docs about effects in React page, seems like RAF is the closes place to run them, after commit. So no questions about that:)