fix(ivy): wrap "inputs" and "outputs" keys if they contain unsafe chars

[AndrewKushnir]

Prior to this change, keys in "inputs" and "outputs" objects generated by compiler were not checked against unsafe characters. As a result, in some cases the generated code was throwing JS error. Now we check whether a given key contains any unsafe chars and wrap it in quotes if needed.

This PR resolves ticket FW-1096.

PR Type

What kind of change does this PR introduce?

• Bugfix

Does this PR introduce a breaking change?

• Yes
• No

[alfaproject]

Why not just quote all of them and let the minifier do its job?

[alxhub]

Help me understand the impact of this more.

The unquoted keys are unquoted so the optimizer will rename them (just as it renames the actual input field on the class). What impact does quoting here have on this renaming? Is the assertion that any property which has special characters will not be renamed by the optimizer?

Should we consider forbidding input names that are not valid JS identifiers?

[trotyl]

Why - only? I can have whatever text value as property name like inputs: ['...foo:foo', ',,,bar:bar'].

[alxhub]

Currently we're having problems with - in input names.

This is a temporary solution while we discuss what to do about this particular issue. Options include:

1. adding some heuristic to decide whether a property will likely be accessed via minified (this.bar) or unminified (this.other-bar) references, and quoting the property mapping for Ivy accordingly.

2. prohibiting the use of input names that aren't valid JS identifiers in the first place (which would be a breaking change).

[trotyl]

Should we consider forbidding input names that are not valid JS identifiers?

@alxhub A class property can indeed be whatever* string or symbol:

class Foo {
  'a$b*c' = 42
  ['d@e!f'] = 84
  [mySymbol] = 21
}

*: Here only means any character, not special names like constructor.

As a top-goal of Ivy is to reduce compiler restriction and support any JavaScript usage when possible, I don't think this is a viable approach.

[trotyl]

@alxhub Please also note that a property named in valid identifier may also be quoted:

class Foo {
    prop0 = 42;
    'prop1' = 42;
    ['prop2'] = 42;
}

In above case the quotes will be preserved in compilation result and thus not being minified by closure compiler.

The true fix should be dropping inputs/outputs in Component metadata (as originally designed for ES5 DSL which has been removed) and only supports @Input()/@Output() property decorators. Otherwise there's no way to understand whether or not the property is quoted (possibly defined in a non-Angular base class).

[AndrewKushnir]

Thanks @trotyl and @alxhub for the input. I've added a TODO to indicate that this solution is a temporary one to avoid confusion. Thank you.

[AndrewKushnir]

Presubmit

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}