Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upTransplant views refactor #33702
Conversation
48256af
to
31c1f2e
myTmpl !: TemplateRef<any>; | ||
name: string = 'world'; | ||
get nameWithLog() { | ||
if (ivyEnabled && !getCheckNoChangesMode()) { |
This comment has been minimized.
This comment has been minimized.
pkozlowski-opensource
Nov 11, 2019
Member
I would personally prefer that we write those tests without being ivy
specific and without digging into ivy internals. Such tests are brittle and we are not sure that we've got 1:1 behaviour with VE.
Couldn't we assert that the both interpolations are updated in the moved embedded view?
This comment has been minimized.
This comment has been minimized.
mhevery
Nov 12, 2019
Author
Member
Good point. I tried to do this, but I have failed. I believe that is because the two actually behave differently. I believe the way VE solves this is that when you project a transplanted view which is not on-push it will force the component to on-push. This is in contrast to this PR which CDs the embedded view twice. Once in Declared
component (always)and once in
Inserted` only when marked dirty. Happy to discuss this more.
const declaredComponentLView = findComponentView(lView); | ||
for (let i = 0; i < movedViews.length; i++) { | ||
const movedLView = movedViews[i] !; | ||
let parentLView = movedLView[PARENT]; |
This comment has been minimized.
This comment has been minimized.
pkozlowski-opensource
Nov 11, 2019
Member
Not sure why we've got the logic of getting a parent and while (isLContainer(parentLView))
here. Shouldn't findComponentView
go up the embedded views?
As the very minimum it would be great to add more comments here as the logic here starts to be non-obvious.
This comment has been minimized.
This comment has been minimized.
mhevery
Nov 12, 2019
Author
Member
I have refactored it to make it more clear. But the short of it is that findComponentView
does not cross LContainer
boundaries.
} | ||
const insertedComponentLView = findComponentView(parentLView !); | ||
const insertionIsOnPush = | ||
(insertedComponentLView[FLAGS] & LViewFlags.CheckAlways) !== LViewFlags.CheckAlways; |
This comment has been minimized.
This comment has been minimized.
pkozlowski-opensource
Nov 11, 2019
Member
We are not really determining insertionIsOnPush
here but rather than it is not CheckAlways, right?
It is not clear to me if this is intentional but I think that we should add comments + tests to explain what happens depending on the insertion view flags (OnPush, OnPush + marked for check, detatched etc.)
This comment has been minimized.
This comment has been minimized.
mhevery
Nov 12, 2019
Author
Member
We are not really determining
insertionIsOnPush
here but rather than it is not CheckAlways, right?
So we don't have on-push flag. The way we mark a view on-push is to set CheckAlways
to false. I have updated the comment.
PS: We do have ManualOnPush
but that is not the same as OnPush
. It is only used for wether a click listener should auto-mark the view dirty.
81f8ebe
to
0e68a2f
This comment has been minimized.
This comment has been minimized.
0e68a2f
to
cf92ede
e46d7a2
to
21ed744
Like the idea of only searching moved views if the flag is set! Some minor things below |
This comment has been minimized.
This comment has been minimized.
googlebot
commented
Nov 13, 2019
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the |
This comment has been minimized.
This comment has been minimized.
googlebot
commented
Nov 13, 2019
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) |
Co-Authored-By: Kara <kara@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
googlebot
commented
Nov 14, 2019
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the |
LGTM |
This comment has been minimized.
This comment has been minimized.
googlebot
commented
Nov 14, 2019
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) |
Co-Authored-By: Kara <kara@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
googlebot
commented
Nov 14, 2019
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the |
This comment has been minimized.
This comment has been minimized.
googlebot
commented
Nov 14, 2019
A Googler has manually verified that the CLAs look good. (Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.) |
PR Close angular#33702
mhevery commentedNov 8, 2019
Based on #33644 (please ignore during review)
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information