Conversation
crisbeto
force-pushed
the
39556/vcr-root-insert
branch
from
November 7, 2020 15:17
fbffcd5 to
60273a3
Compare
crisbeto
marked this pull request as ready for review
November 7, 2020 15:47
crisbeto
commented
Nov 7, 2020
Member
Author
There was a problem hiding this comment.
These changes aren't required for the fix, I just noticed that the tNode and parentTNode are always the same here.
mhevery
approved these changes
Nov 10, 2020
mhevery
left a comment
Contributor
There was a problem hiding this comment.
LGTM, but please take care of @AndrewKushnir 's comments
… component When a `ViewContainerRef` is injected, we dynamically create a comment node next to the host so that it can be used as an anchor point for inserting views. The comment node is inserted through the `appendChild` helper from `node_manipulation.ts` in most cases. The problem with using `appendChild` here is that it has some extra logic which doesn't return a parent `RNode` if an element is at the root of a component. I __think__ that this is a performance optimization which is used to avoid inserting an element in one place in the DOM and then moving it a bit later when it is projected. This can break down in some cases when creating a `ViewContainerRef` for a non-component node at the root of another component like the following: ``` <root> <div #viewContainerRef></div> </root> ``` In this case the `#viewContainerRef` node is at the root of a component so we intentionally don't insert it, but since its anchor element was created manually, it'll never be projected. This will prevent any views added through the `ViewContainerRef` from being inserted into the DOM. These changes resolve the issue by not going through `appendChild` at all when creating a comment node for `ViewContainerRef`. This should work identically since `appendChild` doesn't really do anything with the T structures anyway, it only uses them to reach the relevant DOM nodes. Fixes angular#39556.
…ot of a component
crisbeto
force-pushed
the
39556/vcr-root-insert
branch
from
November 10, 2020 17:06
60273a3 to
88a9ca3
Compare
Member
Author
|
@AndrewKushnir the feedback has been addressed. |
Contributor
Contributor
|
@crisbeto FYI presubmit is successful for the changes in this PR. The missing piece is the "target" label, could you please set one when you get a chance? Thank you. |
atscott
pushed a commit
that referenced
this pull request
Nov 12, 2020
… component (#39599) When a `ViewContainerRef` is injected, we dynamically create a comment node next to the host so that it can be used as an anchor point for inserting views. The comment node is inserted through the `appendChild` helper from `node_manipulation.ts` in most cases. The problem with using `appendChild` here is that it has some extra logic which doesn't return a parent `RNode` if an element is at the root of a component. I __think__ that this is a performance optimization which is used to avoid inserting an element in one place in the DOM and then moving it a bit later when it is projected. This can break down in some cases when creating a `ViewContainerRef` for a non-component node at the root of another component like the following: ``` <root> <div #viewContainerRef></div> </root> ``` In this case the `#viewContainerRef` node is at the root of a component so we intentionally don't insert it, but since its anchor element was created manually, it'll never be projected. This will prevent any views added through the `ViewContainerRef` from being inserted into the DOM. These changes resolve the issue by not going through `appendChild` at all when creating a comment node for `ViewContainerRef`. This should work identically since `appendChild` doesn't really do anything with the T structures anyway, it only uses them to reach the relevant DOM nodes. Fixes #39556. PR Close #39599
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 a
ViewContainerRefis injected, we dynamically create a comment node next to the host so that it can be used as an anchor point for inserting views. The comment node is inserted through theappendChildhelper fromnode_manipulation.tsin most cases.The problem with using
appendChildhere is that it has some extra logic which doesn't return a parentRNodeif an element is at the root of a component. I think that this is a performance optimization which is used to avoid inserting an element in one place in the DOM and then moving it a bit later when it is projected. This can break down in some cases when creating aViewContainerReffor a non-component node at the root of another component like the following:In this case the
#viewContainerRefnode is at the root of a component so we intentionally don't insert it, but since its anchor element was created manually, it'll never be projected. This will prevent any views added through theViewContainerReffrom being inserted into the DOM.These changes resolve the issue by not going through
appendChildat all when creating a comment node forViewContainerRef. This should work identically sinceappendChilddoesn't really do anything with the T structures anyway, it only uses them to reach the relevant DOM nodes.Fixes #39556.