Rendering non-blocking elements does not work#9
Open
mkhl wants to merge 3 commits into
Open
Conversation
Add a test that renders a non-blocking element including an actual asynchronous child element. We should ensure that elements of this kind are ordered and nested properly.
Contributor
Author
|
I added a fix that passes all tests but I’m not certain I’m happy with it yet. |
Contributor
Author
|
Correction: It doesn’t pass the tests, but the lingering eslint errors hide the failures. |
Contributor
|
Thank you. I've attempted to build on your efforts in complate:async (note that this expands the corresponding non-renderer test in order to reproduce the issue at a lower level) - mostly hacking aimlessly in post-holiday stupor, which did yield some success though: The async tests are green now, but we're back to recursion errors (cf. cc106c1), which is what I was afraid of with this approach. 😞 |
Element generators can have acynchronous children in non-blocking mode, in which case the their _siblings_ should only be processed _after_ the current child has executed its callback. This is only relevant in non-blocking mode because in blocking mode we are certain that the children have run their callbacks once they have returned.
Contributor
|
FYI: I've now cherry-picked your performance tweak into master (53a9365) and updated complate:async accordingly. Still pondering what all this means though... 🤕 |
FND
force-pushed
the
master
branch
4 times, most recently
from
31e6354 to
a4b755e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note: This is a bug report with a test case attached.
We don't currently seem to have a test case that ensures that basic rendering
of async elements (in async mode) works correctly,
and the attached test fails on master, and not just since cc106c1
but at least back at v0.12.0.
(Earlier versions had too different API for me to test easily.)
I may be misunderstanding the macro, but I expect it to render
when instead it renders (note the different nesting):
Note the incorrect nesting: I believe this is due to sibling elements
being rendered before a child with asynchronous children
has had a chance to finish rendering.