LGTM. I guess it's worth mentioning in the docs

LGTM

pure regex based approach is a somewhat incomplete fix. For example it would fail for this:

abc | filter {a:1} {b:2}

It would match {a:1} {b:2} as a single argument.

Additionally, if we support spaces inside object braces, they should probably work for arrays too:

abc | filter [1, { a: 2 }]

So we either support the full syntax, or not support it at all. A more proper parsing logic would have to do something similar to what the directive parser is doing: keeping track of braces/brackets/quotes state and only delimit an argument if we are not in any pairs.

Fortunately in 2.0 we don't have this issue :o

So maybe we should just drop it and recommend to pass a computed property instead?

@yyx990803 I agree. This isn't proper fix then. I'll see what I can do about it :)

@yyx990803 I was playing around a bit more and come up with new syntax when filter has multiple arguments. If there are more filters they need to be wrapped in [] as you can see in spec. I'm not sure if this is the way we want to do it...especially with eval used 😊 .

This also forces us to document this behavior and update the docs/guide. I can do it, if this is the way we want to handle this, otherwise I think it's better we just document you should extract filters to functions or use no spaces like @posva already mentioned :)

We forgot about this. I'll rather keep it the way it is and add some documentation that adding a new syntax to filters which already use a special (non-js) syntax

Can this be closed now? I haven't followed well enough @zigomir

Yeah, for sure, it was just a silly attempt of mine :)