DefinitelyTyped has a Dojo solution which uses named modules and may work with legacy Dojo and explicit typing. But these declarations do not facilitate TypeScript import, since there are no anonymous modules. It seems to be a more exhaustive and consistent version of schungx/Dojo-TypeScript, but without the declared modules which make import work.

schungx/Dojo-TypeScript does not allow for 'extends' of an import Dijit but provides both named and anonymous declarations.

Brian Forbes provides a dijit.d.ts definition which is good at consuming dijits from TypeScript. His solution is available here. It works perfectly well with import, since it uses anonymous module declarations, but still does not allow for TypeScript inheritance (even the incompatible type).

The following code allows me to develop TypeScript wijits that extend ContentPane that actually work (despite the inheritance compatibility).

declare module "dijit/layout/ContentPane"
    class w extends dijit._Widget {
        addChild(w: dijit._WidgetBase, index?: number);
    export = w;

It extends the _Widget class defined in schungx/Dojo-TypeScript and tricks tsc into thinking the ContentPane is a TypeScript class.

This is what extends means (d is derived class, b is base class):

var __extends = this.__extends || function (d, b) {
    for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p];
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();

The derived class gets all base properties, including prototype. But I've been warned several times that this is unsafe.

My questions:

  • 3
    Did the folks who advised you that this approach was unsafe explain why they thought so? Feb 24 '16 at 17:18
  • The gist of the concern was keeping it compatible with future version of the framework and making sure the component would work in various scenarios. I got it working and so I used it.
    – Corey Alix
    Feb 25 '16 at 17:23
  • 1
    That's odd reasoning. It is always possible code might not work with future versions...
    – Kat
    Aug 23 at 15:40
  • 1
    It's been chugging along for the past 6 years so it worked out pretty well for me. We are still on 1.11 using the ESRI JSAPI 3.x so there never really was a future version in our future.
    – Corey Alix
    Aug 23 at 15:43

This question is more about if we can make Typescript safe, and the answer is a giant "no".

Typescript may feel safer, but that's because it's enforcing the rules we made for ourselves during development. Those rules don't pertain to execution, since they don't exist after transpilation.

Even deserializing a json string into a typed object is "unsafe". We can build validations and assert the values in the code, but we'll only be as safe as those validations and assertions. In either case, Typescript will happily let us assume whatever assumptions we made during development.

So should this type of technique be shunned? No. The point of typing isn't to ensure safety, it's to constrain development to your definition of success.

If this technique helps you constrain development better towards your definition of success, it's a useful technique.

  • -1 Answer adds no value.
    – Corey Alix
    Nov 16 at 16:58
  • @CoreyAlix The entire question is "is this unsafe", and is there a way to "make it safe". My answer is "no, not that you should worry about it", and "no, you can't". If you have another more specific question, you should ask that.
    – MaxWell
    Nov 17 at 16:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.