Introducing TypeScript support for Ignite UI

We are pleased to annouce complete TypeScript support for all Ignite UI widgets and non-visual components, such as the DataSource. 

TypeScript has been recently introduced by Microsoft as a language and a set of tools around it, such as the TypeScript compiler which compiles TypeScript to JavaScript. TypeScript can be thought of as an "augmentation" of JavaScript which adds strong typing, class-based inheritance and many other features that make JavaScript development a lot less error prone and more maintainable, especially for large projects. More info can be found here:

http://www.typescriptlang.org

We have completely automated the process of generating the TypeScript definitions, and this is not done manually. So whenever we change something in the code or add a new feature, we are going to instantly update our TypeScript definitions as well. We have written code generators, based on an ANTLR JavaScript grammar and we are emitting TypeScript interfaces, classes, and new types based on our comment metadata which we use in order to document  parameter types, return types, methods, options, the inheritance tree, and so on. All non-visual classes (such as the $.ig.DataSource) are also fully supported. The benefit you get - complete intellisense support, as well as static type checking - directly in Visual Studio 2012. so if you set a widget option to a bool, when it's defined as a string ,you will get a compile time error in your project.

You can have a look at the screenshots below, to get an idea of how powerful this is. I have also attached the combined TypeScript definitions file for Ignite UI. 

Keep in mind that the definitions are auto-generated based on type metadata that we put in the javascript code, as we develop it,  in the block comments. So some of the types may not be entirely correct, if the comments in the code list incorrect types – such as a number instead of a string – even though ,those are going to be very rare cases, and the same issues would also be visible in the API docs. That's because it isn't possible to automagically infer JavaScript types without any extra metadata.

In order to get full intellisense and compile time type checking,  you have to reference the TypeScript definitions file for Ignite UI like this:

///<reference path="igniteui.d.ts" />

Usually you would do something like that, in order to also have the jQuery interfaces also defined:

///<reference path="jquery.d.ts" />

///<reference path="jqueryui.d.ts" />

///<reference path="igniteui.d.ts" />

As you may have noticed, the DataSource, for example, is not used like $.ig.DataSource. The only thing that needs to be done in your code, is to alias the $.ig to point to Infragistics. So “Infragistics” is the TypeScript module (you can think of this as a namespace) where the DataSource class lives.

Events are also generated following TypeScript/jQuery conventions, but their generated “param” classes are currently empty, because we use a free-text metadata format to describe event arguments – as compared to describing options & complex options, where there is strict format for the typing, etc. You can expect us to add this extra support for documenting event param classes very soon. 

Please note that all complex types (arrays, objects, arrays of complex options, etc. ) are generated recursively and have new unique types assigned to them. So if you have a columns option of type [], we are generating a type called GridColumn (notice the singular form of the type). Then the columns TypeScript type becomes GridColumn[].  That’s all done automatically as well, and there are some heuristics behind it. We also keep a list of special plurals such as Axes and Series. Ideally, we would specify the dedicated type directly in the comment metadata - at the moment the approach seems to work just fine after going through the generated code, but we can make it stricter in the future.

Also, all non-widgets, such as the DataSource, are generated as classes and there is TypeScript inheritance involved -  So the JSONPDataSource, for instance, extends the DataSource. And for such non-visual classes, public methods are also generated. They aren’t generated for widgets, because the jQuery UI style of invoking methods is different – you can refer to some widget type definition in igniteui.d.ts so see what I mean. For example you invoke a widget method like this:

$("#grid1").igGrid("dataBind", "extra params");

Last but not least, I would like to point out that you can’t rely on all of this TypeScript support in HTML or CSHML, or ASPX files directly. That’s not supported by VS 2012 &TypeScript right now. You need to have your code in a .js or a .ts file, and then add the references which I've mentioned on top of your source code file. That’s currently a limitation that we are sure Microsoft will fix in the future. 

I hope you will enjoy working with this! Any feedback is greatly appreciated. Thanks,

Angel