path expressions containing 'in' no longer working, 'in' treated as keyword

[reinholdk]

I'm submitting a bug report

• Library Version:
  2.1.7

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  8.12.0

• NPM Version:
  6.4.1

• JSPM OR Webpack AND Version
  JSPM 0.17.0-beta.47

• Browser:
  all

• Language:
  ESNext

Current behavior:

Parser Error: Unexpected token in at column 0 in expression [in.name]
    at ParserImplementation.err (aurelia-binding.js:2914)
    at ParserImplementation.parseLeftHandSide (aurelia-binding.js:2651)
    at ParserImplementation.parseBinary (aurelia-binding.js:2498)
    at ParserImplementation.parseConditional (aurelia-binding.js:2487)
    at ParserImplementation.parseExpression (aurelia-binding.js:2473)
    at ParserImplementation.parseValueConverter (aurelia-binding.js:2455)
    at ParserImplementation.parseBindingBehavior (aurelia-binding.js:2444)
    at Parser.parse (aurelia-binding.js:2406)
    at SyntaxInterpreter.bind (aurelia-templating-binding.js:533)
    at SyntaxInterpreter.interpret (aurelia-templating-binding.js:505)

Expected/desired behavior:

It is shall be possible to use the 'in' keyword in path expressions, e.g.:
value.bind="in.name"

Prevents form upgrading form aurelia-binding version 1.6.0

[reinholdk]

Looks like a regression introduced by #689

[fkleuver]

Hi @reinholdk, in principle we follow a subset of the ECMAScript specification for our expression syntax, with the exception of the operators | and & (for value converters and binding behaviors, respectively). This is specified in the expression syntax documentation

For parts of the ECMAScript specification that we have not implemented in the parser, you are technically able to write invalid JavaScript but this is not supported. In that sense the PR you are linking to is a bugfix rather than a regression.

We did a major version bump to account for the fact that it might break some apps that use invalid JavaScript syntax but technically it is also an oversight on our part to explicitly specify this as a breaking change. Apologies for that.

In any case, I would strongly recommend you to change the variable name since in is (as per the specification) a reserved keyword. You would get the exact same error if you entered in.something in the browser console or a JavaScript REPL.

edit
Alternatively, if you must use the variable name in for one reason or the other, you can make it valid by turning it into a member expression like so: value.bind="$this.in.name". The functionality of the expression stays the same, and since reserved keywords are allowed as property names, it should work again.

We should probably add this to the documentation as a proposed workaround.

[reinholdk]

I see, the proposed workaround is working for me. So adding it to the documentation is probably a good idea.

Thanks for the quick response!