Compile core files AoT and remove builder references from core

[edusperoni]

Nativescript's core flavor isn't tree-shakeable due to it being JIT compiled, which requires fully fledged parsers and the UI Builder to be bundled with every Nativescript app as they're used by many plugins and even core functions as well.

Proposal: create a xml loader for Nativescript's core flavor so xml files will be converted into their "code-behind" counterparts.

All Builder references from core could then be removed/changed so the functions now would only require a View or () => View, instead of a ViewEntry.

This goes hand in hand with #4

Possible breaking changes:
it may be possible to analyze for usages of ViewEntry and replace them with the proper imports, but we may need to do something like:

import modalPage from './modal-page.xml';

to use in showing of modals and other dynamically created pages.

[rigor789]

I was going to open a similar issue, but mainly about extracting core flavor into it's own package.

[farfromrefug]

I would love to see that extracted out in a package. Other flavors don't need this

[edusperoni]

That was going to be my suggestion, but as @NathanaelA said in a TSC meeting, many plugins use the core flavor for custom views.

I think it all boils down to how big of a breaking change we want to introduce

If we do want to move forward with removing the core flavor, I think we'll be able to clean up a good chunk of functions from core, like bindingContext, which is very confusing and is even used in things like ListView as a way to select the template (it creates a Label with the template selector function bound to a property and updates the bindingcontext to get the new template key).

[farfromrefug]

When you say plugins depend on core flavor can you elaborate? Not sure I see the issue.
If I take my newly created drawer plugin, it depends on the core Ui in the sense that the drawer extends GridLayout. But it does not depend on the XML/ builder part of it.
Maybe you are talking more the listview kind of plugins where you can have references to the builder to "inflate" cell views?
I think we could easily split in different packages for a major version and have plugins updated to either really "split" the work or at least use the separated plugins.
I think with the efforts that have been put in federating the plugins it would be much easier to quickly have plugins updated to such a major version change

[edusperoni]

No, I mean some plugins actually have a xml file with their layouts and inflate them when needed. This is just something to consider when we introduce this breaking change.

[farfromrefug]

@edusperoni ok ! have not seen that anywhere but you are right, have to be considered

[rigor789]

Would be useful to gather a few plugins that do this - and perhaps we can handle them in an xml-loader without requiring plugins to change. Webpack would compile the xml and it would be passed to the same runtime methods these plugins use, but handled seamlessly. (this definitely needs thorough testing - but should be doable - unless the xml is generated from for eg. string literals)

[NathanWalker]

Here’s a plugin that we use often that uses string literal:
https://github.com/davecoffin/nativescript-filterable-listpicker/blob/34cbf49b13adf2ff831f98330aa4d45fc4d0d7ee/src/filterable-listpicker.ts#L89

[edusperoni]

I believe we can probably do some parsing and try to compile AoT those string literals. Things would probably get hairy with template strings, though.

Regarding bindingContext, I know Angular have no references to it, and searching for it in Vue/React/Svelte yielded no results as well. Most of the references are on core, more especifically:

Binding, which seems to be the "meat" of the binding context implementation, and ViewBase, where it wires up Binding, and some random places like ListView where it uses bindingContext to evaluate a function if it was passed as a string (which shouldn't really happen, as the binding should be able to do this conversion before passing it to the View).

This could be all extracted from core into a "vanilla" flavor which would do this wiring when the view requires it. Yes, it would also be a big breaking change and plugins would likely need to be updated, which is the same that happened with v7.0 when all package names changed. In fact, @NathanWalker's example still isn't compatible with 7.0.

All flavors seem to be able to convert their components' inputs into valid core inputs, it would be really nice if "vanilla" could do the same, even if it were still in the same package as core. I'm working on removing things like zonedCallback because I think flavor specific stuff shouldn't really "leak" into applications that don't need it and make core harder to maintain.

[farfromrefug]

@NathanaelA i think registering only the use components is a subject of another rfc but totally doable today for flavors. They use a template compiler which can thus detect which components are.used.
And just the whole don't add 8mb vs 30k for the code we are talking about. You are talking with source maps which should not be in counted ;)
Finally every little little gain become a big one when you add them up. No stone should be left unturned

[farfromrefug]

@NathanaelA agree on auto registration being more important. But not the same rfc ! So it does not invalidate this one.
Would you like to open a RFC for the auto registration?