Interpolated expressions cannot contain }}

[shahata]

This is not a big deal, since mostly you can easily work around it, but I bet many ppl are wasting a lot of time understanding why it is failing. For example: $interpolate('{{{}}}') needs to be changed to $interpolate('{{ {} }}') and (more realistic example) $interpolate('{{names | filter:{first:search}}}') needs to be changed to $interpolate('{{ names | filter:{first:search} }}').

The only solutions for this I could come up with either involved really hackish use of try/catch or really big changes to $parse (letting it parse a long string and tell you where the expression ended). Does anyone have an idea for an elegant solution for this?

[shahata]

@caitp my second example shows a pretty common use case where literal
expressions are used: object arguments passed to filters. For me, it was
angular-translate that caused this issue.
On Aug 17, 2014 2:17 AM, "Caitlin Potter" notifications@github.com wrote:

honestly who even uses literal expressions in interpolation anyway? i'm
failing to see the use case

—
Reply to this email directly or view it on GitHub
#8642 (comment).

[stephenbunch]

Also, if you do $interpolate("{{ '{{ }}' }}")(), angular throws an error Lexer Error: Unterminated quote at columns 0-3 ['{{] in expression ['{{]. instead of returning {{ }}.

[caitp]

@stephenbunch that's a more legitimate problem, we should fix that :c

[shahata]

@caitp do you have an idea how this can be fixed? The best I could come up with is a pretty big change of how $parse works. Instead of giving $parse the expression we want to interpolate, we can give it the whole thing and let it say where the interpolated expression ends. This is doable, but it seems a bit of an overkill if all it does is solve this one bug...

[lgalfaso]

There are two ways to fix this, a simple way would be
lgalfaso@2c64dc4
A more complex way would be to add some extra logic at $interpolate so it is able to understand some limited expressions

[caitp]

to do it right, you'd need to keep track of whether the end marker is found during a string (for the string literal issue), and keep track of the stack of open braces / square brackets, for the other issue. Both of these would probably add more code than we really want to add though ._.

[lgalfaso]

@caitp agree, that is why I think that if we want to fix this, then the PR is the approach to follow (even when in odd cases it can be less performant)

[pkozlowski-opensource]

Oh, @caitp thnx for saying this - I didn't have time look into the impl but it felt like we simply need brackets matching algorithm here. IMO this needs to be solved on the $interpolate level and should "leak" to the $parse and $interpolate shouldn't know much about expression - it should be enough for it to know interpolate start / end pattern.

I can't spend time on this during this weekend but I was doing similar algs for other projects and shouldn't be too big in terms of LOC. Of course if we can find another, mid-term approach that it easier / faster to implement that might be the way to go, but I don't feel to good about the approach proposed in #8744 as - if I understand it correctly (I might very well miss important details) it will try to get part of the string and "test" if this part is an expression, catch an eventual error and continue... I don't know, if feels a bit " brute-force"...

[shahata]

Yeah, as I mentioned in the original post, the try/catch option seems a bit hackish, but it is a valid solution imo. Should we be worried about the performance hit caused by the try/catch?

[lgalfaso]

@pkozlowski-opensource Updated #8744 with a version that keeps track of ()[]{} and string. It does use some extra bytes, but it removes the try..catch

[gkalpak]

So, this is a known issue 😉