search

complate / complate-stream

complate's core library for rendering HTML via JSX
https://complate.org
6 stars 7 forks source link

Rendering non-blocking elements does not work #9

Open mkhl opened 6 years ago

mkhl commented 6 years ago

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 cc106c1a 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

     <div><p>…</p><p><i>lorem ipsum</i></p><p>…</p></div>

when instead it renders (note the different nesting):

     <div><p>…</p><p><p>…</p><i>lorem ipsum</i></p></div>

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.

mkhl commented 6 years ago

I added a fix that passes all tests but I’m not certain I’m happy with it yet.

mkhl commented 6 years ago

Correction: It doesn’t pass the tests, but the lingering eslint errors hide the failures.

FND commented 6 years ago

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. cc106c1aa14d2b5119ab86d891f3451744e968e6), which is what I was afraid of with this approach. 😞

FND commented 6 years ago

FYI: I've now cherry-picked your performance tweak into master (53a936520cc47f91bdf19776fb1e82ec9a2a90dd) and updated complate:async accordingly. Still pondering what all this means though... 🤕