Now, we have strictly typed Config objects, but they lack xclass / alias / xtype properties, which Ext uses to determine the target class when instantiating a Config object later (see Section 7.3.1.6.2.2, “Creating Ext Config Objects in ActionScript”). So we need a counterpart of the special type cast semantics we introduced in ActionScript.

To this end, the generic Config function supports an overloaded signature which takes as first argument the target class which must define a Config type and as second (optional) argument a Config object of the corresponding Config type, and returns that Config object complemented by xclass / alias / xtype properties taken from the class.

With this new usage of the Config function, you can now create Ext Config objects like so:

import Config from "@jangaroo/runtime/Config";
import MyClass from "./MyClass";

...
    const myClassConfig: Config<MyClass> = Config(MyClass, { // use Config function with target class + config object
      id: "4711",  // inherited from Component._
      configOption1: "bar",  // MyClass Config property
      untyped: new Date(),  // an undeclared property now *does* lead to a type error!
      configOption2: "42"  // type error: '"42" is not assignable to type number[]'
    });
...

As you can see, the syntax is very similar to using Config for a strict type-check. The crucial difference is that MyClass is not a type parameter (which is just a compiler hint and only relevant for type checking), but an argument of the function call. The class reference is needed at runtime to determine the xclass etc. and add it to the config object. Although this Config signature still has a type parameter, is should never be necessary to specify it explicitly, just leave it to the type inference.

If you use a class as first argument, but leave out the second one, the Config function returns an empty Config object with just the target class marker (xclass, xtype, ...). This comes in handy for simple components like Config(Separator). TypeScript automatically distinguishes the two one-argument usages of Config by overloaded signatures, one with a Config object, the other with a class that declares a Config type.

As TypeScript can type object literals, it is no longer recommended to populate a Config object property-by-property (see Section 7.3.1.6.2.2, “Creating Ext Config Objects in ActionScript”). "Not recommended" means, this is of course still possible, and still results in strictly typed code. Note that the AS→TS conversion compiler does not (yet?) rewrite such code to use object literals.

In the rare case you need to instantiate the "real" object from a given Config object, you have different options:

import { cast } from "@jangaroo/runtime";
import Ext from "@jangaroo/ext-ts";

    const myClassInstance: MyClass = new MyClass(myClassConfig); // xclass of Config object is ignored
    // OR
    const myClassInstance: MyClass = Ext.create(MyClass, myClassConfig); // xclass of Config object is ignored
    // OR
    const myClassInstance: MyClass = Ext.create(myClassConfig); // must repeat target class, but incompatible class and Config type would be reported
    // OR
    const myClassInstance = Ext.create<MyClass>(myClassConfig)); // must repeat target class, but incompatible class and Config type would be reported 

The first two usages are when you know which target class to create, anyway, so you would construct myClassConfig without any xclass , but just use the strict Config type function.

The latter two usages are when the Config object might have its own xclass of some MyClass subclass. Ext.create() uses the xclass to instantiate the corresponding class, and the resulting object is type-compatible with MyClass. This is the kind of mechanism used by Ext.Container to instantiate its items .

But the best thing is, that if you want to create an instance directly, you can now do so in a strongly typed fashion with full IDE support using an inline, ad-hoc Config object, which does not need any Config usage:

 const myClassInstance: MyClass = new MyClass({
  id: "4711",
  configOption1: "bar",
  configOption2: [42, 24]
});

In other words, the difference between creating a Config object and creating an instance is just using Config(MyClass, ...) versus using new MyClass(...).