Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

fix($parse): allow for new lines in expr when promise unwrapping is on #4718

Closed
wants to merge 1 commit into from

Conversation

rodyhaddad
Copy link
Contributor

Previously, when unwrapping promises was set to true, (via $parseProvider.unwrapPromises(true);)
an error would occur if a parsed expression had a new line in it.

This was because when generating the evaledFnGetter code,
a new line in an parsed expression would create a new line in a JS string in that code, which is illegal.

That is:

pw("A+
B")

Plunk with 1.2.0-rc.3: http://plnkr.co/edit/QHJHkQOViLYQYNveMnVL?p=preview
Plunk with this PR: http://plnkr.co/edit/sI1e4vCSw4HBZnjitojG?p=preview

@petebacondarwin
Copy link
Contributor

@rodyhaddad - can you add a unit test to this?

Previously, when unwrapping promises was set to `true`,
an error would occur if a parsed expression had a
new line in it.
This was because when generating the `evaledFnGetter` code,
a new line in an parsed expression would create a new line
in a JS string in that code, which is illegal. That is:
```js
pw("A+
B")
```
@rodyhaddad
Copy link
Contributor Author

How does this look? I added a test to make sure that expressions with line terminators worked, and I made that all evaluation tests run with csp and unwrapPromises turned on and off.

Rational behind last decision: The only two things that modified $parse's inner workings were whether csp or unwrapPromises were turned on. We already ran all evaluation tests with csp on/off, so it would make sense to do the same with unwrapPromises. Also, once unwrapping promises is removed completely, its fairly easy to revert this, while my test on line terminators would live on for future versions.

@@ -199,16 +199,20 @@ describe('parser', function() {
}]));


forEach([true, false], function(cspEnabled) {
forEach([[true, true],[!0, !1],[!1, !0],[false, false]], function(options /* [csp, unwrapPromises] */) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this is super hard to read. using two nested forEach loops would make the code much more readable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I went for the nested forEach approach at first, but I reverted to this because the nested approach would create a huge unnecessary diff (cz of the added indentation) that I wanted to avoid. Didn't want to be blamed for all of the tests, too late now :p

@IgorMinar IgorMinar closed this in 40647b1 Nov 22, 2013
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this pull request Jan 27, 2014
Previously, when unwrapping promises was set to `true`,
an error would occur if a parsed expression had a
new line in it.
This was because when generating the `evaledFnGetter` code,
a new line in an parsed expression would create a new line
in a JS string in that code, which is illegal. That is:
```js
pw("A+
B")
```

Closes angular#4718
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this pull request Jan 27, 2014
Previously, when unwrapping promises was set to `true`,
an error would occur if a parsed expression had a
new line in it.
This was because when generating the `evaledFnGetter` code,
a new line in an parsed expression would create a new line
in a JS string in that code, which is illegal. That is:
```js
pw("A+
B")
```

Closes angular#4718
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants