In ActionScript, the above example would look like so:

package acme {
public class Label extends Component {
  public static const xtype: String = "acme.label";

  private var _text: String = "";

  public function Label(config: Label = null) {
    super(config);
  }

  [Bindable]
  public function get text(): String {
    return _text;
  }

  [Bindable]
  public function set text(value: String): void {
    _text = typeof value === "string" ? value : value ? String(value) : "";
    // if rendered, update my DOM node with 'value'
  }
}
}

// ActionScript code using this component:

var label = new acme.Label(acme.Label({ text: "Hi!"}));
label.text = null; // <= !!! translated to JS: label.setText(null) !!!
console.log(button.text); // <= !!! translated to JS: label.getText() !!!
          

The [Bindable] annotation is the hint for Jangaroo to convert ActionScript accessors not to JavaScript accessor, but to Ext get/set methods. So in ActionScript, the Config access looks like a property, but really calls the get/set methods. To be more precise, this decision is made at run-time, by rewriting such code to use the utility methods getBindable(obj, config) or setBindable(obj, config, value).

To know when to replace what looks like a property access by a "bindable" access, the Jangaroo compiler resolves the declaration of the property and looks for a [Bindable] annotation. Unfortunately, in TypeScript, this is no longer possible, so we had to find a way to represent "bindable" Configs in TypeScript which a) looks like meaningful TypeScript code and b) can be translated to the Ext semantics.

Long story short, we found a way to add "real" accessors for all Configs defined by ActionScript code at runtime! So in TypeScript, when we write label.text, it actually resolves to an accessor that delegates to the getText or setText method. We even introduced this change for the "normal" JavaScript output mode in Jangaroo 4.1, and it seems to work fine!

One more complication is that in real-world Studio ActionScript code, we used several same-same-but-different patterns to declare [Bindable] Configs. The code above is probably the most clean way to do it, but unfortunately another field _text is created in addition to the "internal" Config field text, which is less efficient and can even lead to confusion. We tried to capture all patterns we identified and automatically translate them to a single TypeScript pattern for bindable Configs, which is presented in the next section.

As you can see in the constructor of the example class, in ActionScript, we use the same type for the class and for the Config type. This is actually cheating. The class has far more properties (methods!) than the Config type, and in Ext, some class properties even have a different type than their Config property counterpart (for example, Container#items is an Array in the Config type, but a MixedCollection in the class).

The reason we do not declare two separate types (as we did in Jangaroo 2) is that ActionScript only allows one exported declaration per file. So to declare the Config type separately, every class would need two files, and both would still have to be consistent (extend the same superclass, use the same mixins). We did not want developers to deal with that.