Support for UI5-converted classes with class decorators

[Elberet]

I'm working on a concise, easily readable API for class mixins, such as this:

import Controller from "sap/ui/core/mvc/Controller"
import { mixin } from "../lib/decorators"
import RoutingSupport from "../lib/RoutingSupport"

@namespace("example.controller")
@mixin(RoutingSupport)
export default class AppController extends Controller { /* ... */ }

mixin is a simple wrapper that returns a decorator function; the decorator function should eventually be called by Babel's decorators API and receives a descriptor which it uses to register a finisher. The finisher function then gets called with the class' constructor function as its argument and... well, this part is still very much WIP. 😊

Unfortunately, babel-plugin-transform-classes-ui5 doesn't support the very first step: while it respects the @namespace decorator and triggers UI5-transformation for the class, the @mixin decorators are ignored and Babel's decorators API is not invoked.

Any chance to get this working?

---

FWIW, Babel desugars a decorated class into something like this:

var TheClass = _decorate([mixin], function(_initialize, _BaseClass) {
  var TheClass = function(_BaseClass2) {
    /* CONSTRUCTOR FACTORY BODY */
  }(_BaseClass);

  return {
    F: TheClass,
    d: [ /* PROPERTY/METHOD DESCRIPTORS */ ]
  };
}, BaseClass);

The first commented-out section is basically the usual class constructor factory, with the big difference being that method and property definitions are moved into the second commented-out section, each wrapped into a descriptor object so that the decorators API can process them further.

This indicates to me that if support for method/property decorators is omitted until some future version, supporting just class decorators should™ be fairly straight forward - just pull in Babel's decorators machinery and feed it the constructor function returned by UI5's extend...

[lucasheim]

@Elberet I know this is old, but are you using @babel/plugin-proposal-decorators in your babel pipeline? In my project, we have custom decorators too and things worked out when adding this step.

[Elberet]

Well, sometime during the past half year, I've migrated away from this plugin towards a custom set of Babel plugins... but form what I can recall:

Yes, @babel/plugin-proposal-decorators was present in my Babel config, but from what I gleaned from its code, babel-plugin-transform-modules-ui5 would completely replace the ClassDeclaration node with the UI5 class creation logic long before the standard Babel plugin handling classes would get a chance to visit the node and decide, based on feature flags enabled by proposal-decorators, to create the class using the decorators API.

And, since babel-plugin-transform-modules-ui5 does all this in a Program enter visitor, plugin ordering seemed largely irrelevant because that node is always visited before any ClassDeclarations the file might contain, so I gave up trying to get things to work, opened this issue and later decided to just learn the Babel API and roll my own.

That also allowed me to do a few other things right in my build pipeline, such as allowing imports of NPM modules that get automatically webpacked into a vendor-bundle, and building a runtime-bundle from latest core-js and regenerator-runtime instead of using the deprecated @babel/polyfill library... so I have no regrets. 😉

[lucasheim]

Thanks for the insights @Elberet! Do you have any available examples of your final build pipeline? I'm currently looking into alternatives to work with TS + UI5.

[Elberet]

I wrote the thing on company time, so I'll have to check if I can put it under some OS license and put it on GitHub, but the chances of that happening are unfortunately slim to none. 😞

If you would like to follow in my footsteps, I can give some pointers tho, but it pretty much boils down to: be frugal, let other plugins do as much as possible, and keep in mind that you can always use path.traverse to walk through the syntax tree without other plugins messing things up; in fact, nesting traverse calls is almost always a better idea than to attempt storing and consuming state information in node handlers within the same visitor.

[ArnaudBuchholz]

Hello, I see the issue is still open and I need decorators to achieve some special logic with a JSONModel.

I observe that my decorators are not being converted to JavaScript. Since I am not familiar with babel, I searched and found that I needed to add @babel/plugin-proposal-decorators, @babel/plugin-proposal-class-properties
and @babel/plugin-transform-flow-strip-types which I did but... unsuccessfully.

It is supposed to work ?

[Elberet]

No, transform-modules-ui5 (this plugin) interferes with Babel's handling of decorators. Changing this would require a complete redesign of this plugin.

As mentioned above, by the time @babel/plugin-proposal-decorators runs, transform-modules-ui5 has already stripped the source tree of all classes, methods and properties and their associated decorators, and has replaced them with UI5-style class declarations. Other plugins - such as @babel/plugin-proposal-decorators - will only see a function call declaration for BaseClass.extend() and an inline object declaration. Thus, the bulk of Babel's code responsible for emitting transpiled classes and runtime decorator-calls is never executed.