This section presents different types of (type) errors that may occur during and after conversion to TypeScript and gives guidance on how to fix them. The cases have been collected from our own experience with converted CoreMedia Studio code.

Property does not exist/Type incompatible: Maybe Config type was meant

In many cases where the TypeScript compiler complains about an undefined property or that the actual type is not compatible to the required type, the reason is that the instance type was used as the ActionScript surrogate of the 'Config' type.

In ActionScript/Jangaroo 4, an Ext component's Config type and its actual (instance) type is, while inaccurate, represented by the same type/class (for details, see Section 7.3.1.6, “Using the Ext Config System”). For Ext in TypeScript, the distinction has been restored. However, the Jangaroo ActionScript-to-TypeScript converter cannot always determine whether the ActionScript type is supposed to refer to the class or its Config type. When in doubt, it chooses the class. If this choice was wrong, the resulting JavaScript code still works, but you end up with type errors like the ones described above.

One case is, that the class type that is supposed to be a Config type is handed in to a function that requires a Config type, like a component constructor. The other case is, that the variable or expression of that type is used to access Config properties that do not exist on the class, or only as private members.

The typical fix is to change type Foo to Config<Foo> in such cases. Maybe you must add an import directive for Config (from "@jangaroo/runtime/Config), if it is not already there. The Config type is computed based on the class by the utility type Config. When using a class as well as its Config type, this saves you from having to use two separate imports. For details, see Section 7.3.1.6, “Using the Ext Config System”.

Callback function parameter is incompatible

Many methods, most often for event listener registration, take a callback function as a parameter. In ActionScript, such parameters have the general type Function, and it is impossible to express the function signature. In TypeScript, however, the function signature can be expressed, and for example the Ext JS documentation actually documents most callback function signatures, so they have been included in Ext TS.

Having callback signature leads to improved IDE assistance and also reveals (subtle) type errors in ActionScript code after conversion to TypeScript. In most cases, the signature match failure is quite trivial and easy to fix. Read the TypeScript error message carefully, and it tells you which parameter must have a different type or is altogether obsolete.

In rare cases, callback type errors may also be the result of an error in Ext TS, which again usually results from an API documentation error in Ext JS. If you think you found such an error, please report it to CoreMedia Support. One shortcoming we are aware of is, that Ext event listeners receive the "options" object (eOpts) that was used when attaching the listener as an additional last argument. Ext TS callback signatures currently lack this parameter, because it is rarely used and only complicates declaring event signatures. In most cases, using the options in the event callback is not necessary. The event callback function is typically a method of the class that attaches it as event listener, so a private class field can be used to store additional information the listener needs.

Some Jangaroo utilities are no longer supported in TypeScript

Jangaroo 4's runtime library contains some remains of Jangaroo 2, which were not properly deprecated, but in the context of CoreMedia Studio, there was no real need to use them. If, however, you still used certain parts of this API, you will end up with compiler errors already when trying to convert to TypeScript. These errors are, in contrast to TypeScript type errors, "fatal" in the sense that they cannot be ignored. This section lists removed Jangaroo API and explains how to replace certain usages.

joo.JavaScriptObject

Inheriting from this class used to signal Jangaroo 2 that instances of your class are considered primitive JSON objects. Jangaroo 2 supported limited ActionScript language features for such subclasses. Jangaroo 4 only kept the class for (partial) compatibility, but did not implement these semantics. Thus, in Jangaroo 4, classes extending JavaScriptObject were no different than classes extending nothing, Object or ext.Base.

The solution is to just remove the extends clause from your class, or, to keep it even more compatible in some edge cases, use Ext.Base as the superclass. The only feature of JavaScriptObject your class might use is its convenient constructor, which copies all enumerable properties from the parameter object to this. This can be implemented in TypeScript simply by

for (let key in config) this[key] = config[key];

or, if you know the config value does not use the prototype chain, even simpler by

Object.assign(this, config);

joo.DynamicClassLoader

If at all, this Jangaroo 2 utility class is used to dynamically load classes (because there are no compile-time usages that trigger their loading). With Jangaroo 4, all class loading and script loading was delegated to Ext, but the API still existed for compatibility. This mechanism is used internally by the CoreMedia Studio plugin implementation, but should usually not occur in your plugin code.

If you used it anyway, you probably mimicked the pattern used by Studio core code, namely import several classes using DynamicClassLoader.INSTANCE.import_("...");, then adding a callback for when these classes have been loaded using DynamicClassLoader.INSTANCE.complete(callback);.

This pattern can be replaced by using Ext's API directly:

Ext.require("...");
Ext.onReady(callback);

joo.getOrCreatePackage()

This utility method returns or creates the JavaScript object representing an ActionScript package at runtime. In Jangaroo 4, an ActionScript package is implemented as an Ext "namespace". In clean code, you should never need to access an ActionScript package at runtime, but it sometimes was used as a trick to initialize "global" (package-scope) variables by privileged code and let it appear read-only (const) for all other code.

If you used getOrCreatePackage() for this trick: It no longer works in TypeScript. To compensate for that, there is a new utility function lazyConst, which is used like so:

import { lazyConst } from "@jangaroo/runtime";
import MyServiceInterface from "...";
import MyServiceImpl from "...";

const myService: { readonly _: MyServiceInterface } = lazyConst(() => new MyServiceImpl());
export default myService;

For all other usages of getOrCreatePackage("..."), try replacing it by the corresponding Ext API, namely Ext.namespace("...") (or its alias Ext.ns("...")).