Ensure FastBoot rendered content is cleared even if the server rendered application contains malformed HTML. #699
Conversation
This file contains 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
rwjblue
approved these changes
Jun 3, 2019
|
Thank you @noslouch! |
rwjblue
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When rendering dynamic markup pulled from a database, we don't have a guarantee things will end up in the DOM where we want them to be.
Ember enforces good markup during the build, but there's no way to know if the following template will have valid markup:
The browser is a tolerant place, and it will do whatever it needs to do to create a valid DOM tree, even if that means swallowing up elements. A certain type of bad markup can wreak havoc on desired trees.
For example, let's say your fastboot returns the following HTML document to your browser:
When a browser parses that (at least when Chrome does), here's the DOM tree you wind up with:
Yikes.
When the
clear-double-bootinitializer runs, it assumes that the start and end markers have the same parent, which is sometimes not the case, as seen above.Does this proposed solution work for you all? I know it might open a can of worms as far as working around DOM quirks, but this seems like a particularly nasty case that we can fix to ensure that the app finishes booting.