fix(core): not inserting ViewContainerRef nodes when inside root of a component #39599
+60
−45
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
crisbeto
force-pushed
the
39556/vcr-root-insert
branch
from
fbffcd5
to
60273a3
Compare
crisbeto
added
action: review
crisbeto
commented
Nov 7, 2020
| const tNode = tData[parentTNode.index] as TNode; | ||
| const encapsulation = (tData[tNode.directiveStart] as ComponentDef<any>).encapsulation; | ||
| const encapsulation = | ||
| (tView.data[parentTNode.directiveStart] as ComponentDef<unknown>).encapsulation; |
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
added
the
action: cleanup
… 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
60273a3
to
88a9ca3
Compare
crisbeto
removed
the
action: cleanup
|
@AndrewKushnir the feedback has been addressed. |
petebacondarwin
added
the
action: presubmit
crisbeto
added
action: merge
AndrewKushnir
removed
the
action: presubmit
|
@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
basherr
pushed a commit
to basherr/angular
that referenced
this pull request
Nov 14, 2020
… component (angular#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 angular#39556. PR Close angular#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. |
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.