Fixing nested Suspense boundaries in Simple Suspense Renderer #334
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.
While I was working on a real-life application using lazy components (using
lazy
andSuspense
) when I noticed that the rendered HTML sometimes contains[object Promise]
instead of properly resolved component markup.I did some debugging and I found out that this issue happens only when there are nested lazy components in the app (App renders ComponentA lazily, ComponentA renders ComponentB lazily), in this case ComponentB is rendered as
[object Promise]
.If I get it right, there is a test case for validating nested Suspense boundaries (
Async renderToString > should render JSX with nested suspense boundary
), but that test case does not contain nested Suspense boundaries, only a single Suspense boundary with multiple nested suspended components.I think both use-cases are valid (having one Suspense boundary per suspended component, or only having one "top-level" Suspense boundary), so I kept the original test with a bit more explicit name, and added a new one for testing nested Suspense boundaries which replicates my original issue:
As a solution I opted into a
while
loop instead of implementing a recursive Promise.all, but I don't have strong opinions on this.