PR Checklist

• The PR title follows our guidelines: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/CONTRIBUTING.md#commit-messages.
• There is an issue for the bug/feature this PR is for. To avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it.
• You have signed the CLA.
• All existing tests are passing: https://github.com/NativeScript/NativeScript/blob/master/tools/notes/DevelopmentWorkflow.md#running-unit-tests-application.
• Tests for the changes are included - https://github.com/NativeScript/NativeScript/blob/master/tools/notes/WritingUnitTests.md.

What is the current behavior?

For years now, vanilla NativeScript has been providing us with its own data-binding system that can also be used inside XML which has been really helpful.

However, in additional to popular frameworks, one has very limited options for composing an expression in NativeScript Core.
For example, one cannot call any functions that are not direct properties of binding context or let's say use features from newest ECMA versions.

To parse expressions, NativeScript is using a certain package's sources inside repo: https://www.npmjs.com/package/polymer-expressions.
The polymer-expressions package has been abandoned for 5 years now, and Polymer library itself is in maintainance mode.
It's using version 2.0.0-dev of esprima parser which is also quite old, to manage an AST Expression schema and all in all it has very limited features.

Here is a very small sample of what is the current state of expression parsing:

<Page actionBarHidden="true" xmlns="http://www.nativescript.org/tns.xsd">
	<StackLayout>
		<Label text="{{ funcOfContext() }}"/> <!-- Possible -->
		<Label text="{{ propertyOfContext.func() }}"/> <!-- Not possible -->
                <Label text="{{ funcOfContext(...prop) }}"/> <!-- Not Possible -->

		<Label text="{{ prop.test }}"/> <!-- Possible -->
		<Label text="{{ prop?.test }}"/> <!-- Not possible -->

		<Label text="{{ prop || prop2 }}"/> <!-- Possible -->
		<Label text="{{ prop ?? prop2 }}"/> <!-- Not possible -->

		<Label text="in Operator" textWrap="{{ prop in obj ? true : false }}"/> <!-- Not possible -->
		<Label text="typeof Operator" textWrap="{{ typeof prop == 'object' ? true : false }}"/> <!-- Not possible -->
	</StackLayout>
</Page>

What is the new behavior?

This began as an experiment at holidays and I ended up composing a new AST parser that keeps existing behaviour and adds more features.
On top of that, it makes possible what is impossible in the XML example below.

There is a dozen of methods to parse AST schemas out there, with browserify's static-eval being a good option but none of them had an out-of-the-box proper support for NativeScript features and contained few bugs.

Just like before, expression parsing is done using AST pattern and parsed expression results are stored in custom parser's cache to avoid parsing over and over.

Features

I have made sure to support lots of additional features like constructor calls, spread operator for both arrays and objects which can also be used as a function arguments, null coalescing operator, optional chaining, in & typeof operators, and even untagged template literal syntax!

The old approach did not support function and arrow lambda expressions and so does the new one. Adding support for such expressions will make things too complicated as there will be the need of statements support like variable declarations, assign operators and more.

Old mechanism used esprima. I started creating this patch using the same parser but I eventually switched to acorn since it's already used in NativeScript for webpack functionality and supports latest ecma features.

I have also made sure function calls and converters have their appropriate call context.

Converters

https://v7.docs.nativescript.org/core-concepts/data-binding#using-converters-in-bindings

Regarding NativeScript converters, there is a small detail that makes new behaviour differ from the old:
This reference is deprecated as converter usage has become identical to old one.

Error Reporting

Regarding expression parsing errors, the old approach enclosed all logic inside a try catch which would print a not-so-specific message about a binding error. The new approach uses a separate try catch for acorn parse, in order to print parser errors regarding expression syntax and other stuff during parsing.

Conclusion

This will have positive results for vanilla NS developers. There have been many times I have personally attempted to make something work in XML without much effort but failed. On top of that, this will add missing new ecma features in the XML part of NativeScript.