-
Notifications
You must be signed in to change notification settings - Fork 26.9k
feat(ivy): generate ɵɵproperty instructions #29946
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
Conversation
ae91d21 to
a78163b
Compare
|
Current integration_test failures seem to be related to an issue with incorrect version numbers in Angular CLI. 🤔 |
mhevery
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain whey all of the try-finally blocks are needed?
packages/compiler-cli/test/compliance/r3_compiler_compliance_spec.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mapping logic (lines 757-766) is already in mapBindingToInstruction. Reuse here?
instruction = mapBindingToInstruction(inputType)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mapBindingToInstruction was removed. The way it was being used didn't make sense. For example, it was mapping for BindingType.Animation, but for no reason, because what it was mapping to wasn't even used inside the block for if (inputType === BindingType.Animation) { right below it.
Looking into your comment did reveal a funny bug though, it was still doing else if (instruction) which was always true because instruction is a function declared elsewhere in the module. :)
At the end of the day, the mapBindingToInstruction function was unnecessary indirection that wasn't even universally useful for every BindingType. I axed it in favor of simple conditionals. These are likely to change in upcoming PRs to update generated code for inrepolation too, to be even more like the check above where you see inputType === BindingType.Property && !(value instanceof Interpolation)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for fixing the logic. I would argue that we should still move it to a separate function for readability. This function is incredibly long already, so I think inlining it actually makes the code less readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the BindingType does not always map 1:1 with an instruction anymore, and that's actually liable to get more complicated. I agree that the mega function sucks, but perhaps we can refactor it in another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I see why it's hard to copy-paste that code out into a different function?
@mhevery There are several situations where updating a property causes child views to synchronously render. For example when you update an |
|
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that 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 here in the pull request. Note to project maintainer: This is a terminal state, meaning the ℹ️ Googlers: Go here for more info. |
1 similar comment
|
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that 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 here in the pull request. Note to project maintainer: This is a terminal state, meaning the ℹ️ Googlers: Go here for more info. |
1e727e0 to
e49058a
Compare
|
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
mhevery
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, please resolve comments from other.
kara
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, a few more nits and should be good
|
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. |
ɵɵpropertyinstructions to compilerRelated #29881