Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fw 1559 - more cases #33493

Conversation

pkozlowski-opensource
Copy link
Member

This is a version of #33457 that has more tests and handles more cases.

@pkozlowski-opensource pkozlowski-opensource added action: review The PR is still awaiting reviews from at least one requested reviewer target: major This PR is targeted for the next major release comp: ivy labels Oct 30, 2019
@ngbot ngbot bot added this to the needsTriage milestone Oct 30, 2019
@pkozlowski-opensource
Copy link
Member Author

core/todo/bundle increased by 126 bytes.

This is mostly due to the fact that we are starting to have code duplication with

function applyToElementOrContainer(
action: WalkTNodeTreeAction, renderer: Renderer3, parent: RElement | null,
lNodeToHandle: RNode | LContainer | LView, beforeNode?: RNode | null) {
// If this slot was allocated for a text node dynamically created by i18n, the text node itself
// won't be created until i18nApply() in the update block, so this node should be skipped.
// For more info, see "ICU expressions should work inside an ngTemplateOutlet inside an ngFor"
// in `i18n_spec.ts`.
if (lNodeToHandle != null) {
let lContainer: LContainer|undefined;
let isComponent = false;
// We are expecting an RNode, but in the case of a component or LContainer the `RNode` is
// wrapped in an array which needs to be unwrapped. We need to know if it is a component and if
// it has LContainer so that we can process all of those cases appropriately.
if (isLContainer(lNodeToHandle)) {
lContainer = lNodeToHandle;
} else if (isLView(lNodeToHandle)) {
isComponent = true;
ngDevMode && assertDefined(lNodeToHandle[HOST], 'HOST must be defined for a component LView');
lNodeToHandle = lNodeToHandle[HOST] !;
}
const rNode: RNode = unwrapRNode(lNodeToHandle);
ngDevMode && !isProceduralRenderer(renderer) && assertDomNode(rNode);
if (action === WalkTNodeTreeAction.Create && parent !== null) {
if (beforeNode == null) {
nativeAppendChild(renderer, parent, rNode);
} else {
nativeInsertBefore(renderer, parent, rNode, beforeNode || null);
}
} else if (action === WalkTNodeTreeAction.Insert && parent !== null) {
nativeInsertBefore(renderer, parent, rNode, beforeNode || null);
} else if (action === WalkTNodeTreeAction.Detach) {
nativeRemoveNode(renderer, rNode, isComponent);
} else if (action === WalkTNodeTreeAction.Destroy) {
ngDevMode && ngDevMode.rendererDestroyNode++;
(renderer as ProceduralRenderer3).destroyNode !(rNode);
}
if (lContainer != null) {
applyContainer(renderer, action, lContainer, parent, beforeNode);
}
}
}

In the essence both code-paths are solving the same problem - give me a set of root native nodes. We just happen to do it for different purposes, but the returned value is the same.

We need to remove this code duplication in a follow-up PR(s)

} else {
// ViewEngine seems to produce very different DOM structure as compared to ivy
// when it comes to ICU containers - this needs more investigation / fix.
expect(rootNodes.length).toBe(7);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AndrewKushnir it seems like VE and ivy are generating very different DOM when it comes to ICU expressions. Not sure if this is intended and if not, are we tracking it anywhere?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be expected for ICU expressions.

@mhevery mhevery added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Oct 30, 2019
@pkozlowski-opensource pkozlowski-opensource marked this pull request as ready for review October 30, 2019 16:05
@pkozlowski-opensource pkozlowski-opensource requested a review from a team as a code owner October 30, 2019 16:05
@mhevery
Copy link
Contributor

mhevery commented Oct 30, 2019

presubmit
ivy presubmit

mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
mohaxspb pushed a commit to mohaxspb/angular that referenced this pull request Nov 7, 2019
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants