babel transform-ui5

A community-driven Babel transformer plugin for SAPUI5/OpenUI5.

It allows you to develop SAPUI5 applications by using the latest ECMAScript, including classes and modules, or even TypeScript.

Install

This repo contains both a preset and a plugin. It is recommended to use the preset since the plugin may get split into two in the future.

1npm install babel-preset-transform-ui5 --save-dev

or

1yarn add babel-preset-transform-ui5 --dev

Configure

.babelrc

At a minimum, add transform-ui5 to the presets.

1{
2    "presets": ["transform-ui5"]
3}

Or if you want to supply plugin options, use the array syntax.

1{
2    "presets": [
3        ["transform-ui5", {
4            ...pluginOpts
5        }]
6    ]
7}

At the time of writing the babel version is 7.3, which does not natively support class property syntax. To use that syntax also add the plugin @babel/plugin-syntax-class-properties.

It is also recommended to use @babel/preset-env to control which ES version the final code is transformed to.

The order of presets is important and @babel/preset-env should be higher in the array than this one. Babel applies them in reverse order for legacy reasons, so this preset will be applied first.

1{
2    "presets": [
3        ["@babel/preset-env", { // applied 3rd
4            ...presetEnvOpts
5        }],
6        ["transform-ui5", { // applied 2nd
7            ...pluginOpts
8        }],
9        "@babel/preset-typescript", // applied 1st
10    ]
11}

Features

There are 2 main features of the plugin, and you can use both or one without the other:

1. Converting ES modules (import/export) into sap.ui.define(...) or sap.ui.require(...).
2. Converting ES classes into Control.extend(...) syntax.

NOTE: The class transform might be split into its own plugin in the future.

This only transforms the UI5 relevant things. It does not transform everything to ES5 (for example it does not transform const/let to var). This makes it easier to use @babel/preset-env to transform things correctly.

A more detailed feature list includes:

• ES2015 Imports (default, named, and dynamic)
• ES2015 Exports (default and named)
• Classes, using inheritance and super keyword
  • Static methods and fields
  • Class properties
  • Class property arrow functions are bound correctly in the constructor.
• Existing sap.ui.define calls don't get wrapped but classes within can still be converted.
  • Fixes constructor shorthand method, if used.
• Various options to control the class name string used.
  • JSDoc (name, namespace, alias)
  • Decorators (name, namespace, alias)
  • File path based namespace, including setting a prefix.

Converting ES modules (import/export) into sap.ui.define or sap.ui.require

The plugin will wrap any code having import/export statements in sap.ui.define. If there is no import/export, it won't be wrapped.

Static Import

The plugin supports all of the ES import statements, and will convert them into sap.ui.define arguments.

1import Default from "module";
2import Default, { Named } from "module";
3import { Named1, Named2 } from "module";
4import * as Namespace from "module";

The plugin uses a temporary name (as needed) for the initial imported variable, and then extracts the properties from it. This allows importing ES Modules which have a 'default' value, and also non-ES modules which do not. The plugin also merges imports statements from the same source path into a single require and then deconstructs it accordingly.

This:

1import Default, { Name1, Name2 } from "app/File";
2import * as File from "app/File";

Becomes:

1sap.ui.define(['app/File'], function(__File) {
2  "use strict";
3
4  function _interopRequireDefault(obj) {
5      return (obj && obj.__esModule && (typeof obj.default !== "undefined")) ? obj.default : obj;
6  }
7  const Default = _interopRequireDefault(__File);
8  const Name1 = __File["Name1"];
9  const Name2 = __File["Name2"];
10  const File = __File;
11}

Also refer to the noImportInteropPrefixes and neverUseStrict option below.

Dynamic Import

ECMAScript allows for dynamic imports calls like import(path) that return a Promise which resolves with an ES Module.

This plugin will convert that to an async sap.ui.require wrapped in a Promise. The resolved object will be a ES module or pseudo ES module having a 'default' property on it to reference the module by, to match the format used by import(). If the module is not a real ES module and already has a default property, the promise will be rejected with an error.

For JavaScript projects, this syntax doesn't provide much advantage over a small utility function and has the downside of not working if your module has a 'default' property. The main advantage of this syntax is with TypeScript projects, where the TypeScript compiler will know the type of the imported module, so there is no need to define a separate interface for it.

Also note that while the ES dynamic import specification requires a relative path, sap.ui.require works with absolute paths using a module prefix.

Export

The plugin also supports (most of) the ES modules export syntax.

1export function f() {};
2export const c = 'c';
3export { a, b };
4export { a as b };
5export default {};
6export default X;
7export { X as default };
8export let v; v = 'v'; // NOTE that the value here is currently not a live binding (http://2ality.com/2015/07/es6-module-exports.html)

Export is a bit trickier if you want your exported module to be imported by code that does not include an import inter-op. If the importing code has an inter-op logic inserted by this plugin, then you don't need to worry and can disable the export inter-op features if desired.

Imagine a file like this:

1export function two() {
2  return 2;
3}
4export default {
5  one() {
6    return 1;
7  },
8};

Which might export a module that looks like:

1{
2    __esModule: true,
3    default: {
4        one() {
5            return 1;
6        }
7    },
8    two() {
9        return 2;
10    }
11}

But in order to be usable in a standard sap.ui.require file, what we want is actually:

1{
2    one() {
3        return 1;
4    }
5    two() {
6        return 2;
7    }
8}

This plugin's terminology for that is 'collapsing'.

Export Collapsing to default export

The export inter-op features do their best to only return the default export rather than returning an ES module. To do this, it determines if all the named exports already exist on the default export (with the same value reference), or whether they can be added to it if there is not a naming conflict.

If there is a naming conflict or other reason why the named export cannot be added to the default export, the plugin will throw an error by default.

In order to determine which properties the default export already has, the plugin checks a few locations, if applicable.

• In an object literal.

1export default {
2  prop: val,
3};
4// plugin knows about 'prop'

• In a variable declaration literal or assigned afterwards.

1const Module = {
2  prop1: val,
3};
4Module.prop2 = val2;
5export default Module;
6// plugin knows about 'prop1' and 'prop2'

• In an Object.assign(..) or _extends(..)
  • _extends is the named used by babel and typescript when compiling object spread.
  • This includes a recursive search for any additional objects used in the assign/extend which are defined in the upper block scope.

1const object1 = {
2  prop1: val,
3};
4const object2 = Object.assign({}, object1, {
5  prop2: val,
6});
7export default object2;
8// plugin knows about 'prop1' and 'prop2'

CAUTION: The plugin cannot check the properties on imported modules. So if they are used in Object.assign() or _extends(), the plugin will not be aware of its properties and may override them with a named export.

Example non-solvable issues

The following are not solvable by the plugin, and result in an error by default.

1export function one() {
2  return 1;
3}
4
5export function two() {
6  return 2;
7}
8
9function one_string() {
10  return "one";
11}
12
13const MyUtil = {
14  // The plugin can't assign 'one' or 'two' to `exports` since there is a collision with a different definition.
15  one: one_string,
16  two: () => "two",
17};
18export default MyUtil;

sap.ui.define global export flag

If you need the global export flag on sap.ui.define, add @global to the JSDoc on the export default statement.

1const X = {};
2
3/**
4 * @global
5 */
6export default X;

Outputs:

1sap.ui.define(
2  [],
3  function() {
4    const X = {};
5    return X;
6  },
7  true
8);

Also refer to the option exportAllGlobal below.

Minimal Wrapping

By default, the plugin will wrap everything in the file into the sap.ui.define factory function, if there is an import or an export.

However sometimes you may want to have some code run prior to the generated sap.ui.define call. In that case, set the property noWrapBeforeImport to true and the plugin will not wrap anything before the first import. If there are no imports, everything will still be wrapped.

There may be a future property to minimize wrapping in the case that there are no imports (i.e. only wrap the export).

Example:

1const X = 1;
2import A from "./a";
3export default {
4  A,
5  X,
6};

Outputs:

1"use strict";
2
3const X = 1;
4sap.ui.define(["./a"], A => {
5  return {
6    A,
7    X,
8  };
9});

Also refer to the neverUseStrict option below.

Top-Level Scripts (e.g. QUnit Testsuites)

By default, modules are converted to UI5 AMD-like modules using sap.ui.define. In some cases, it is necessary to include modules via script tags, such as for QUnit testsuites. Therefore, this Babel plugin supports converting modules into scripts using sap.ui.require instead of AMD-like modules using sap.ui.define. These modules can then be used as top-level scripts, which can be included via <script> tags in HTML pages. To mark a module as being converted into a sap.ui.require script, you need to add the comment /* @sapUiRequire */ at the top of the file.

Example:

1/* @sapUiRequire */
2
3// https://api.qunitjs.com/config/autostart/
4QUnit.config.autostart = false;
5
6// import all your QUnit tests here
7void Promise.all([import("unit/controller/App.qunit")]).then(() => {
8  QUnit.start();
9});

will be converted to:

1"use strict";
2
3QUnit.config.autostart = false;
4"sap.ui.require([], function () {
5  function __ui5_require_async(path) { /* ... */ }
6  void Promise.all([__ui5_require_async("unit/controller/App.qunit")]).then(() => {
7    QUnit.start();
8  });
9});

:warning: Although sap.ui.define and sap.ui.require may appear similar from an API perspective, they have different behaviors. To understand these differences, please read the section titled "Using sap.ui.require instead of sap.ui.define on the top level" in the Troubleshooting for Loading Modules.

:bulb: The plugin detects the global usage of QUnit.config.autostart and moves this out of the sap.ui.require or sap.ui.define block automatically to ensure that the config is applied sychronously when loading the module. The move can be supressed with the configuration option noWrapQUnitConfigAutostart. If QUnit is imported, e.g. import QUnit from "qunit"; then this is detected and the autostart config is not moved as it must apply locally.

Converting ES classes into Control.extend(..) syntax

By default, the plugin converts ES classes to Control.extend(..) syntax if the class extends from a class which has been imported. So a class without a parent will not be converted to .extend() syntax.

There are a few options or some metadata you can use to control this.

Configuring Name or Namespace

The plugin provides a few ways to set the class name or namespace used in the SAPClass.extend(...) call.

File based namespace (default)

The default behaviour if no JSDoc or Decorator overrides are given is to use the file path to determine the namespace to prefix the class name with.

This is based on the relative path from either the babelrc sourceRoot property or the current working directory.

The plugin also supports supplying a namespace prefix in this mode, in case the desired namespace root is not a directory in the filesystem.

In order to pass the namespace prefix, pass it as a plugin option, and not a top-level babel option. Passing plugin options requires the array format for the plugin itself (within the outer plugins array).

1{
2    "sourceRoot" "src/",
3    "plugins": [
4        ["transform-modules-ui5", {
5            "namespacePrefix": "my.app"
6        }],
7        "other-plugins"
8    ]
9}

If the default file-based namespace does not work for you (perhaps the app name is not in the file hierarchy), there are a few way to override.

JSDoc

The simplest way to override the names is to use JSDoc. This approach will also work well with classes output from TypeScript if you configure TypeScript to generate ES6 or higher, and don't enable `removeComments``.

You can set the @name/@alias directly or just the @namespace and have the name derived from the ES class name.

@name and @alias behave the same; @name was used originally but the @alias JSDoc property is used in UI5 source code, so support for that was added.

1/**
2 * @alias my.app.AController
3 */
4class AController extends SAPController {
5    ...
6}
7
8/**
9 * @name my.app.AController
10 */
11class AController extends SAPController {
12    ...
13}
14
15/**
16 * @namespace my.app
17 */
18class AController extends SAPController {
19    ...
20}
21
22Will all output:
23
24const AController = SAPController.extend("my.app.AController", {
25    ...
26});

Decorators

Alternatively, you can use decorators to override the namespace or name used. The same properties as JSDoc will work, but instead of a space, pass the string literal to the decorator function.

NOTE that using a variable is currently not supported.

1@alias('my.app.AController')
2class AController extends SAPController {
3    ...
4}
5
6@name('my.app.AController')
7class AController extends SAPController {
8    ...
9}
10
11@namespace('my.app')
12class AController extends SAPController {
13    ...
14}
15
16const AController = SAPController.extend("my.app.AController", {
17    ...
18});

Don't convert class

If you have a class which extends from an import that you don't want to convert to .extend(..) syntax, you can add the @nonui5 (case insensitive) jsdoc or decorator to it. Also see Options below for overriding the default behaviour.

Class Properties

The plugin supports converting class properties, and there are a few scenarios.

• proposal-class-public-fields
• proposal-class-fields

Static Class Props

Static class props are always added to the extend object. It's recommended to always use static if you want the property as part of the extend object. Some examples of this are metadata, renderer and any formatters or factories you need in views.

1class MyControl extends SAPControl {
2  static metadata = {...};
3  static renderer = {...};
4}
5
6class Controller extends SAPController {
7  static ThingFactory = ThingFactory;
8  static ThingFormatter = ThingFormatter;
9}

Instance Class Props

Instance props either get added to the constructor or to the onInit function (for controllers).

Before version 7.x, they could also get added directly to the SomeClass.extend(..) config object, but not anymore now. So if you still want a prop in the extend object, it's best to use a static prop. However, there are some exception where it is known that UI5 expects certain properties in the extend object, like renderer, metadata and overrides and some configurable cases related to controller extensions (see below).

Refer to the next section to see the logic for determining if constructor or onInit is used as the init function for class properties.

The logic for determining if the prop going into the controller/onInit or the extend object is whether it uses 'this' or needs 'this' context (i.e. arrow function).

In the bind method (either constructor or onInit), the properties get added after the super call (if applicable) and before any other statements, so that it's safe to use those properties.

1class Controller extends SAPController {
2  A = 1; // added to constructor or onInit (to extend object in v6 and lower)
3  B = Imported.B; // added to constructor or onInit (to extend object in v6 and lower)
4  C = () => true; // added to constructor or onInit
5  D = this.B.C; // added to constructor or onInit
6  E = func(this); // added to constructor or onInit
7  F = func(this.A); // added to constructor or onInit
8
9  onInit() {
10    super.onInit();
11    // --- Props get added here ---
12    doThing(this.A, this.D);
13  }
14}

1const Controller = SAPController.extend("...", {
2  A: 1,
3  B: Imported.B,
4  onInit: function onInit() {
5    if (typeof SAPController.prototype.onInit === "function") {
6      SAPController.prototype.onInit.apply(this);
7    }
8    this.C = () => true;
9    this.D = this.B.C;
10    this.E = func(this);
11    this.F = func(this.A);
12    doThing(this.A, this.D);
13  },
14});

Special Class Property Handling for Controllers

The default class property behaviour of babel is to move the property into the constructor. This plugin has a moveControllerPropsToOnInit option that moves them to the onInit function rather than the constructor. This is useful since the onInit method is called after the view's controls have been created (but not yet rendered).

When that property is enabled, any class with 'Controller' in the name or namespace, or having the JSDoc @controller will be treated as a controller.

This is mostly beneficial for TypeScript projects that want easy access to controls without always casting them. In typescript, the byId(..) method of a controller returns a Control instance. Rather than continually casting that to the controller type such as sap.m.Input, it can be useful to use a class property.

1/**
2 * @name app.MyController
3 * @controller
4 */
5class MyController extends Controller {
6  input: SAPInput = this.byId("input") as SAPInput;
7
8  constructor() {
9    super();
10  }
11
12  onInit(evt: sap.ui.base.Event) {}
13}

Results in:

1const MyController = Controller.extend("app.MyController", {
2  onInit(evt) {
3    this.input = this.byId("input");
4  },
5});

Of course, the alternative would be to define and instantiate the property separately. Or to cast the control whenever it's used.

1/**
2 * @name app.MyController
3 * @controller
4 */
5class MyController extends Controller {
6  input: SAPInput;
7
8  onInit(evt: sap.ui.base.Event) {
9    this.input = this.byId("input") as SAPInput;
10  }
11}

Handling metadata and renderer

Because ES classes are not plain objects, you can't have an object property like 'metadata'.

This plugin allows you to configure metadata and renderer as class properties (static or not) and the plugin will convert it to object properties for the extend call.

1class MyControl extends SAPClass {
2    static renderer = MyControlRenderer;
3    static metadata = {
4        ...
5    }
6}

is converted to

1const MyControl = SAPClass.extend('MyControl', {
2    renderer: MyControlRenderer,
3    metadata: {
4        ...
5    }
6});

Properties related to Controller Extensions

The overrides class property (added in UI5 version 1.112) required for implementing a ControllerExtension will also be added to the extend object. (For backward compatibility with older UI5 runtimes, you can use overridesToOverride: true.)

1/**
2 * @namespace my.sample
3 */
4class MyExtension extends ControllerExtension {
5
6  static overrides = {
7    onPageReady: function () { }
8  }
9}

is converted to

1const MyExtension = ControllerExtension.extend("my.sample.MyExtension", {
2  overrides: {
3    onPageReady: function () {}
4  }
5});
6return MyExtension;

When a controller implemented by you uses pre-defined controller extensions, in JavaScript the respective extension class needs to be assigned to the extend object under an arbitrary property name like someExtension. Whenever the controller is instantiated, the UI5 runtime will instatiate the extension and this instance of the extension will then be available as this.someExtension inside your controller code.

While in the JavaScript code a controller class must be assigned in the extend object, the TypeScript compiler needs to see that the class property contains an extension instance. To support this, a dummy method ControllerExtension.use(...) was introduced in the UI5 type definitions in version 1.127. It is being downported to patches of older releases and should be available in the following (and higher) versions of OpenUI5, SAPUI5, @openui5/types and @sapui5/types:

• 1.127.0
• 1.126.1
• 1.124.3
• 1.120.18

The other releases in between are no longer maintained and will not get a downport. Neither will older releases.

For @types/openui5, versioning is different and downports are tbd with at least 1.120.4 being a likely target.

This method takes an extension class as argument and claims to return an instance, so TypeScript will allow you to work with an instance in your controller. However, behind the scenes, the method call is simply removed by this transformer plugin, so the UI5 runtime gets the extension class it needs to create a new instance of the extension for each controller instance. For these assignments, the transformer plugin also takes care that they remain inside the extend object in the resulting JavaScript code.

Example:

1import Routing from "sap/fe/core/controllerextensions/Routing";
2import ControllerExtension from "sap/ui/core/mvc/ControllerExtension";
3
4/**
5 * @namespace my.sample
6 */
7class MyController extends Controller {
8
9  routing = ControllerExtension.use(Routing); // use the "Routing" extension provided by sap.fe
10
11  someMethod() {
12    this.routing.navigate(...);
13  }
14}

is converted to the proper Controller.extend(...) code as expected by the UI5 runtime:

1// ...
2
3const MyController = Controller.extend("my.sample.MyController", {
4  routing: Routing, // now the Routing *class* is assigned as value, while above it appeared to be an instance
5  
6  someMethod: function() {
7    this.routing.doSomething();
8  }
9});
10return MyController;

NOTE: In order to have this transformer plugin recognize and remove the dummy method call, you MUST a) call it on the ControllerExtension base class (the module imported from sap/ui/core/mvc/ControllerExtension), not on a class deriving from it (even though it is inherited) and b) assign the extension right in the class definition as shown in the examples on this page (an "equal" sign is used, not a colon like in JavaScript, as this is now ES class syntax and not a configuration object). Any variation may cause the call not to be recognized and removed and lead to a runtime error. Calling ControllerExtension.use(...) with more or less than one argument will not only cause a TypeScript error, but will also make this transformer throw an error.
The removal only takes place when the class definition overall is recognized and transformed by this transformer. So when the class still is an ES6 class in the output, first fix this, then check again whether the ControllerExtension.use(...) call has been removed.

Some controller extensions allow implementing hooks or overriding their behavior. This can be done equally:

1import Routing from "sap/fe/core/controllerextensions/Routing";
2import ControllerExtension from "sap/ui/core/mvc/ControllerExtension";
3
4/**
5 * @namespace my.sample
6 */
7class MyController extends Controller {
8
9  routing = ControllerExtension.use(Routing.override({
10    someHook: function(...) { ... }
11  })); // adapt the "Routing" extension provided by sap.fe
12
13  someMethod() {
14    this.routing.navigate(...);
15  }
16}

Static Properties

Since class properties are an early ES proposal, TypeScript's compiler (like babel's class properties transform) moves static properties outside the class definition, and moves instance properties inside the constructor (even if TypeScript is configured to output ESNext).

To support this, the plugin will also search for static properties outside the class definition. It does not currently search in the constructor (but will in the future) so be sure to define renderer and metadata as static props if TypeScript is used.

1/** TypeScript **/
2class MyControl extends SAPClass {
3    static renderer: any = MyControlRenderer;
4    static metadata: any = {
5        ...
6    };
7}
8
9/** TypeScript Output **/
10class MyControl extends SAPClass {}
11MyControl.renderer = MyControlRenderer;
12MyControl.metadata = {
13    ...
14};
15
16/** Final Output **/
17const MyControl = SAPClass.extend('MyControl', {
18    renderer: MyControlRenderer,
19    metadata: {
20        ...
21    }
22});

CAUTION The plugin does not currently search for 'metadata' or 'renderer' properties inside the constructor. So don't apply Babel's class property transform plugin before this one if you have metadata/renderer as instance properties (static properties are safe).

Comments

In case of defining a copyright comment in your source code (detected by a leading !) at the first place, the plugin ensures to include it also as leading comment in the generated file at the first place, e.g.:

1/*!
2 * ${copyright}
3 */
4import Control from "sap/ui/core/Control";

will be converted to:

1/*!
2 * ${copyright}
3 */
4sap.ui.define(["sap/ui/core/Control"], function(Control) { /* ... */ });

In general, comments are preserved, but for each class property/method whose position is changed, only the leading comment(s) are actively moved along with the member. Others may disappear.

Options

Imports

• noImportInteropPrefixes (Default ['sap/']) A list of import path prefixes which never need an import inter-opt.
• modulesMap (Default {}) Mapping for an import's path. Accepts object or function.

Exports

• allowUnsafeMixedExports (Default: false) No errors for unsafe mixed exports (mix of named and default export where named cannot be collapsed*)
• noExportCollapse (Default: false) Skip collapsing* named exports to the default export.
• noExportExtend (Default: false) Skips assigning named exports to the default export.
• exportAllGlobal (Default: false) Adds the export flag to all sap.ui.define files.

Wrapping

• noWrapBeforeImport (Default: false) Does not wrap code before the first import (if there are imports).
• noWrapQUnitConfigAutostart (Default: true) Does not wrap the QUnit.config.autostart in the sap.ui.require or sap.ui.define block.

Class Conversion

• namespacePrefix (Default: '') Prefix to apply to namespace derived from directory.
• autoConvertAllExtendClasses (Default false). Converts all classes by default, provided they extend from an imported class. Version 6 default behaviour.
• autoConvertControllerClass (Default true). Converts the classes in a .controller.js (or .ts) file by default, if it extends from an imported class. Use @nonui5 if there are multiple classes in a controller file which extend from an import.
• neverConvertClass (Default: false) Never convert classes to SAPClass.extend() syntax.
• moveControllerPropsToOnInit (Default: false) Moves class props in a controller to the onInit method instead of constructor.
• moveControllerConstructorToOnInit (Default: false) Moves existing constructor code in a controller to the onInit method. Enabling will auto-enable moveControllerPropsToOnInit.
• addControllerStaticPropsToExtend (Default: false) Moves static props of a controller to the extends call. Useful for formatters.
• onlyMoveClassPropsUsingThis (Default: false) Set to use old behavior where only instance class props referencing this would be moved to the constructor or onInit. New default is to always move instance props.
• overridesToOverride (Default: false) Changes the name of the static overrides to override when being added to ControllerExtension.extend() allowing to use the new overrides keyword with older UI5 versions
• neverUseStrict (Default: false) Disables the addition of the "use strict"; directive to the program or sap.ui.define callback function.

* 'collapsing' named exports is a combination of simply ignoring them if their definition is the same as a property on the default export, and also assigning them to the default export.

** This plugin also makes use of babel's standard sourceRoot option.

TODO: more options and better description.

Other Similar Plugins

sergiirocks babel-plugin-transform-ui5 is a great choice if you use webpack. It allows you to configure which import paths to convert to sap.ui.define syntax and leaves the rest as ES2015 import statements, which allows webpack to load them in. This plugin will have that functionality soon. Otherwise this plugin handles more edge cases with named exports, class conversion, and typescript output support.

Example

openui5-master-detail-app-ts, which is a fork of SAP's openui5-master-detail-app converted to TypeScript.

Building with Webpack

Take a look at ui5-loader (we have not tried this).

Modularization / Preload

UI5 supports Modularization through a mechanism called preload, which can compile many JavaScript and xml files into just one preload file.

Some preload plugins:

• Module/CLI: openui5-preload (also created by Ryan Murphy)
• Gulp: gulp-ui5-lib (MagicCube)
• Grunt: grunt-openui5 (Official SAP)

Credits

• Thanks to MagicCube for the upstream initial work and to Ryan Murphy for continuing development and handing over the project to the UI5 community.

TODO

• libs support, like sergiirocks'
• See if we can export a live binding (getter?)
• Configuration options
  • Export interop control
  • Others..

Contribute

Please do! Open an issue, or file a PR. Issues also welcome for feature requests.

License

MIT © 2019-2024 Ryan Murphy, UI5 community and contributors