feat: include titanium-es api

[garymathews]

WIP: DO NOT MERGE

• Proof-of-concept of implementing a modern Titanium API with latest ECMAScript standards including async await support
• Titanium-ES will be rolled up as part of our common extensions, this means it will be included in the V8 snapshot on Android

TEST CASE

import { UI } from 'Titanium';
// OR
import UI from 'Titanium/UI';

const { Window, Label, View, Animation, Matrix2D } = UI;

const window = new Window({
    title: 'Titanium-ES',
    layout: 'vertical',
    backgroundColor: 'gray'
});
const label = new Label({
    color: 'white',
    font: {
        fontSize: '32'
    },
    text: 'Titanium-ES!'
});
const view = new View({
    backgroundColor: 'red',
    width: 100,
    height: 100
});
const matrix = new Matrix2D({
    rotate: 90
});
const animation = new Animation({
    transform: matrix,
    duration: 3000
});

window.addEventListener('open', async _ => {
    try {
        await view.animate(animation);

        view.backgroundColor = 'orange';
        alert('DONE ANIMATION!');
    } catch (e) {
        console.error(e);
    }
});

window.add([ label, view ]);
window.open();

[build]

	Warnings
⚠️	There is no linked JIRA ticket in the PR body. Please include the URL of the relevant JIRA ticket. If you need to, you may file a ticket on JIRA

	Messages
📖	💾 Here's the generated SDK zipfile.
📖	✊ The commits in this PR match our conventions! Feel free to Rebase and Merge this PR when ready.
📖	✅ All tests are passing Nice one! All 6555 tests are passing. (There are 703 skipped tests not included in that total)

New dependencies added: titanium-es.

titanium-es

Author: Axway

Description: Generates a modern ECMAScript wrapper for Titanium API

Homepage: https://github.com/appcelerator/titanium-es#readme

Created	about 1 month ago
Last Updated	12 days ago
License	Apache-2.0
Maintainers	1
Releases	9
Direct Dependencies	@babel/core, @babel/preset-env, ejs and fs-extra
Keywords	titanium, ecmascript, es2020 and javascript

README

titanium-es

Generates a modern ECMAScript wrapper for Titanium API

Generate Wrappers

import TitaniumES from 'titanium-es';

await TitaniumES.generate('api.jsca', 'output');

Example

import UI from 'Titanium/UI';
const { Window, Label, View, Animation, Matrix2D } = UI;

const window = new Window({
    title: 'Titanium-ECMAScript',
    layout: 'vertical',
    backgroundColor: 'gray'
});
const label = new Label({
    color: 'white',
    font: {
        fontSize: '32'
    },
    text: 'Titanium-ECMAScript!'
});
const view = new View({
    backgroundColor: 'red',
    width: 100,
    height: 100
});
const matrix = new Matrix2D({
    rotate: 90
});
const animation = new Animation({
    transform: matrix,
    duration: 3000
});

window.addEventListener('open', async _ => {
    try {
        await view.animate(animation);

        view.backgroundColor = 'orange';
        alert('DONE ANIMATION!');
    } catch (e) {
        console.error(e);
    }
});

window.add([ label, view ]);
window.open();

Generated by 🚫 dangerJS against 7d6a46f

[hansemannn]

As much I like this, please share more insights to the developers on how this affects app size and launch time performance.

[garymathews]

@hansemannn That's something I'm curious about too. There will be some impact, I'll be running some benchmarks soon and report my findings.

[hansemannn]

@garymathews As an idea: Using native V8/JSCore constructors, the whole "create" factory could be replaced easily and without wrappers. Same goes for callbacks (e.g. KrollCallback on iOS), which could return a native Promise to enable async/await. @drauggres made a PoC pull request for the Android promises already (#10554) which could be reused.

And SDK 9 could even log a warning that the create factory may be deprecated in SDK 10? I'd LOVE that change!

[garymathews]

@hansemannn That's the direction I want to go in, but there's parity issues doing so. iOS doesn't offer a Promise type or any APIs to handle promises natively.

Until there's a means of parity natively, wrapping our current Titanium API is the fastest way to achieve a modern interface.

[hansemannn]

@garymathews iOS 13 is our friend, Promise objects in every JSValue :)

If you enjoyed our article about JavaScriptCore, you’d be thrilled to know that JSValue objects now natively support promises.

For the uninitiated: in JavaScript, a Promise is an object that represents the eventual completion (or rejection) of an asynchronous operation and its resulting value. Promises are a mainstay of modern JS development — perhaps most notably within the fetch API.

=> https://nshipster.com/ios-13/
=> https://developer.apple.com/documentation/javascriptcore/jsvalue/3335012-valuewithnewpromiseincontext?language=objc

[drauggres]

BTW, React Native has promises in iOS for a very long time. It's not hard to find their implementation on github.

Why nobody ever talks about RN here?

[hansemannn]

@drauggres Never used it because of performance reasons :) Also, they use a high level implementation with RCTPromiseResolveBlock and RCTPromiseRejectBlock which looks quite overhead compared to a JSCore implementation.

[drauggres]

Never used it because of performance reasons

Same here. But it does not mean that we can't adopt good ideas from other projects (Native Script also looks interesting) or learn on their mistakes.
(It fiels like RN theme is forbidden or something)

Also, they use a high level implementation with RCTPromiseResolveBlock and RCTPromiseRejectBlock which looks quite overhead compared to a JSCore implementation.

Since there is no Promise type before 13, "high level" is the only solution for older iOS versions (either in obj-c or with wrappers in js).

[hansemannn]

Well, a low level JSCore / V8 implementation would be more performant to save bridge calls. But either way, a simple object is a good idea!