Concurrent Renders

[rmorshea]

_{By submitting this pull request you agree that all contributions to this project are made under the MIT license.}

Issues

Currently ReactPy renders components sequentially. This means that larger renders can block smaller updates from taking place which impacts responsiveness of the page. Sequential renders are also problematic for async effects since effects which are slow to start and stop can similarly impact the responsiveness of a page.

Solution

This change now allow renders to take place concurrently. To keep things simple, no effort is made to deduplicate renders. For example, if parent and child components are scheduled to render at the same time, both scheduled renders will take place even though a single render of the parent component would be sufficient to update the view.

Concurrent renders are achieved by "asyncifying" the internals of the Layout class. Additionally all scheduled renders immediately result in a "render task" being started. To avoid rendering the same component at the same time, we introduce a semaphore inside LifeCycleHooks that must be acquired before a component is rendered.

Note: this contains a subset of the changes originally created in #1093

Checklist

• Tests have been included for all bug fixes or added functionality.
• The changelog.rst has been updated with any significant changes.

[Archmonger]

Here's a couple of side comments that aren't related to specific LOCs.

1. Should we start considering allowing async components? I think they'd lead to some fairly clever design patterns. But, those are completely new design patterns that break ReactPy out of the "ReactJS mold".
2. Should we use this PR to add Allow threading for sync use_effect calls #1136?
3. After merging, we will need a new issue for an deduplication algorithm.
   • If a parent is already in the render queue, don't append a new child render.
   • If a child is already in the render queue, remove it from the queue.
4. I set this PR to close Improve ReactPy Performance #557 since JSON patch is the only thing remaining. We've discussed that is a separate can of worms. Patch might not even be worth the computation time, or at the very least it should be toggleable.
5. We will need to create an issue to remind ourselves to change this default from False to True in v2. Or at least evaluate whether we should do that,

[rmorshea]

I'll be able to finish this off over the weekend.

[Archmonger]

There's still a couple of comments on my original review that need discussion.