-
Notifications
You must be signed in to change notification settings - Fork 26.2k
fix(compiler): handle strings inside bindings that contain binding characters #39826
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
1e58121
to
13f72e3
Compare
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 change looks good, I've just left a few comments.
I think it'd be great if @petebacondarwin can have a look as well, since he did some work in expression parser recently.
Thank you.
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.
Nice little fix @crisbeto - I agree with @AndrewKushnir's test addition suggestion. I made some suggestions of my own for the tests and the algorithm. Feel free to consider them :-)
13f72e3
to
1512e3b
Compare
Thank you for the reviews everybody, all of the should be addressed now. |
96801fb
to
674d300
Compare
@crisbeto just a quick update:
Will keep this thread updated. |
83c70bd
to
1a96c5e
Compare
Thank you for looking into it @AndrewKushnir. I've added logic to handle the two use cases that you mentioned and included some more unit tests. Can we run it through again? |
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've added logic to handle the two use cases that you mentioned and included some more unit tests. Can we run it through again?
Thanks @crisbeto! I've just added a quick comment on the //
case to see if we can add more tests (and whether the way we handle that is correct). Could you please have a look when you get a chance?
FYI, presubmits went well 👍 |
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!
…aracters (#39826) Currently the compiler treats something like `{{ '{{a}}' }}` as a nested binding and throws an error, because it doesn't account for quotes when it looks for binding characters. These changes add a bit of logic to skip over text inside quotes when parsing. Fixes #39601. PR Close #39826
…aracters (angular#39826) Currently the compiler treats something like `{{ '{{a}}' }}` as a nested binding and throws an error, because it doesn't account for quotes when it looks for binding characters. These changes add a bit of logic to skip over text inside quotes when parsing. Fixes angular#39601. PR Close angular#39826
it('should parse interpolation with escaped backslashes', () => { | ||
checkInterpolation(`{{foo.split('\\\\')}}`, `{{ foo.split("\\") }}`); | ||
checkInterpolation(`{{foo.split('\\\\\\\\')}}`, `{{ foo.split("\\\\") }}`); | ||
checkInterpolation(`{{foo.split('\\\\\\\\\\\\')}}`, `{{ foo.split("\\\\\\") }}`); |
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.
A tip: this code would greatly benefit from String.raw`\no \escaping \here`
. See MDN for details.
…ng in property binding Currently we check whether a property binding contains an interpolation using a regex so that we can throw an error. The problem is that the regex doesn't account for quotes which means that something like `[prop]="'{{ foo }}'"` will be considered an error, even though it's not actually an interpolation. These changes build on top of the logic from angular#39826 to account for interpolation characters inside quotes. Fixes angular#39601.
…ng in property binding (#40267) Currently we check whether a property binding contains an interpolation using a regex so that we can throw an error. The problem is that the regex doesn't account for quotes which means that something like `[prop]="'{{ foo }}'"` will be considered an error, even though it's not actually an interpolation. These changes build on top of the logic from #39826 to account for interpolation characters inside quotes. Fixes #39601. PR Close #40267
…ng in property binding (#40267) Currently we check whether a property binding contains an interpolation using a regex so that we can throw an error. The problem is that the regex doesn't account for quotes which means that something like `[prop]="'{{ foo }}'"` will be considered an error, even though it's not actually an interpolation. These changes build on top of the logic from #39826 to account for interpolation characters inside quotes. Fixes #39601. PR Close #40267
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. |
Currently the compiler treats something like
{{ '{{a}}' }}
as a nested binding and throws an error, because it doesn't account for quotes when it looks for binding characters. These changes add a bit of logic to skip over text inside quotes when parsing.