Voilà maintenant plus de 5 ans que j’arpente les sillages du typage static en Javascript grâce à TypeScript. Étant donné le peu de ‘Style Guide’, je me permet de lancer une série d’articles qui auront pour but de parler des Best Practices pour assurer le plus haut niveau de contrôle des types. On commence tout de suite avec l’option de compilation la plus indispensable : strict.

Option de compilation strict ?

Apparue avec la sortie de TypeScript 2.3, c’est ce qu’on apelle une option ‘maître’. En effet, lorsque cette option est mise à true dans votre tsconfig.json, elle active un certain nombre de sous-options de compilation qui renforce le contrôle des types. Voici la liste des sous-options activées :

• noImplicitAny
• noImplicitThis
• alwaysStrict
• strictNullChecks
• strictFunctionTypes
• strictPropertyInitialization

Si strict n’est pas dans votre tsconfig.json, alors elle est désactivée par défaut. Si vous créez votre tsconfig.json avec l’invite de commande tsc –init, alors le tsconfig.json généré aura par défaut l’option activée.

Un point important à retenir et qu’il est possible d’utiliser l’option strict de façon incrémentale, par exemple :

1
2
3
4
5
6
7
8
9
10
11
12

{
  "compilerOptions": {
    "strict": true,
    "noImplicitThis": false,
    "alwaysStrict": false,
    "strictNullChecks": false,
    "strictFunctionTypes": false,
    "strictPropertyInitialization": false,
  }
}

Ici seul une des sous-options est activée (noImplicitAny). Ceci est très utile lorsque vous activez l’option strict sur un projet qui à un lourd passif et que vous souhaitez corriger les erreurs remonter par les sous-options au fur et à mesure. Vous pouvez donc les activer une à une en retirant la ligne qui la désactive.

Décortiquont maintenant chacune de ces fameuses sous-options afin de mieux comprendre leur utilité.

noImplicitAny (TypeScript 1.0)

Cette option existe depuis la première relase de TypeScript ! Elle lève une erreur lorsqu’un élément (variable, retour de fonction, …) est typé en any de façon implicite. TypeScript met le type any par défaut (donc de façon implicite) si :

• le compilateur ne peut inférer le type
• le type n’est pas explicitment précisé

Exemple :

1
2
3

function fn(someArg) { // ERREUR : Parameter 'someArg' implicitly has an 'any' type.
   //...
}	

1
2
3

function fn(someArg: any) { // Ici pas d'erreur car someArgs est typé en any de façon explicite
   //...
}

1
2
3
4
5
6

{
  "compilerOptions": {
    "strict": true,
    "suppressImplicitAnyIndexErrors": true,
  }
}

1
2
3
4
5

interface IFoo {
    key1:          string;
    key2:          number;
    [key: string]: string|number;
}

1
2
3
4
5
6
7
8
9
10
11
12

interface IFoo {
    key1:          string;
    key2:          number;
}

const foo: IFoo = {
    key1:   'value',
    key2:   42
};

const key: (keyof IFoo) = 'key1';
const val: string = foo[key];

noImplicitThis (TypeScript 2.0)

Le this en Javascript est assez particulier et il est facile de tomber dans des pièges. Cette option ‘catch’ les utilisations de this potentiellement dangereuse. Si TypeScript n’arrive pas à inférer this et qu’il n’est pas explicitement typé alors l’option noImplicitThis lève une erreur.

Exemple :

1
2
3
4
5
6
7
8

let farms = {
   animals: ["chicken", "cow", "rabbit"],
   createGroup: function() {
      return function() {
         return { group: this.animals }; // ERREUR : 'this' implicitly has type 'any' because it does not have a type annotation.
      }
   }
}

Pour corriger l’exemple ci-dessus, on peut transformer la fonction retournée par la méthode createGroup en fonction fléchée :

1
2
3
4
5
6

let farms = {
   animals: ["chicken", "cow", "rabbit"],
   createGroup: function() {
      return () => { group: this.animals }; // TypeScript peux inférer this (type -> this: { animals: string[]; createGroup: () => () => void; })
   }
}

1
2
3

function f(this: void) {
   // 'this' est ici inutilisable
}

strictNullChecks (TypeScript 2.0)

Grosse option mise en l’avant lors de la sortie de TS 2.0, elle est inspirée du fonctionnement de Flow. En TypeScript et sans l’option strictNullChecks activée, null et undefined ne sont pas des types à part entier et peuvent être assignés à tous les types. Par exemple :

1
2
3

let foo: string = ''; // Ici on à en réalité foo: string|null|undefined
foo = null; // Pas d'erreur
foo = undefined; // Pas d'erreur

Donc lorsque vous accédez à une variable, vous ne savez pas si elle est potentiellement null ou undefined. En activant l’option strictNullChecks, null/undefined deviennent des types à part entier et doivent être préciser explicitement :

Image venant de l’article Marius Schulz

Si on reprend l’exemple précédent :

1
2
3
4
5

let foo: string = '';
foo = null; // ERREUR : Type 'null' is not assignable to type 'string'.

let bar: string|null = '';
bar = null;

L’intêret de cette option et de vous certifier que votre variable n’est ni null ni undefined au moment ou vous y accéder. Vous pouvez utiliser les types guards pour tester votre variable :

1
2
3
4
5
6
7
8
9
10

declare function fn(x: string): void;

let bar: string|null = '';
bar = null;

if (bar) {
    fn(bar) 
} else {
    fn(bar) // ERREUR : Argument of type 'null' is not assignable to parameter of type 'string'.
}

1
2
3
4
5
6
7
8

function validateObject(o?: Object) {
    // Ici on check que l'objet n'est ni null ni undefined
}

function foo(o?: Object) {
    validateObject(o);
    const bar = o!.prop;  // Dans la fonction précédente nous avons déjà vérifié que la variable n'est ni null ni undefined
}

alwaysStrict (TypeScript 2.1)

Pour comprendre cette option, il faut connaître la directive “use strict” apparue avec l’implémentation de l’EcmaScript 5. Grosso modo, placer cette directive en haut d’un fichier indique au moteur JS qui l’interprétera, qu’il doit utiliser le strict mode. Dans ce mode, beaucoup d’erreurs qui avant étaient silcencieuse, lèvent ici une exception.

L’option alwaysStrict permet d’inclure cette directive dans tout vos fichiers et être sur que tout votre code sera interpréter en mode strict.

strictFunctionTypes (TypeScript 2.6)

Pour un rappel sur la covariance/contravariance/invariance/bivariance c’est ici. Inspirée du fonctionnement de Flow, cette option permet de checker les paramètres de fonction de façon contravariant. Cela permet de remonter ce genre d’erreur :

1
2
3
4
5
6
7
8
9
10
11
12
13

class Vegetable {}
class Garlic extends Vegetable {
    nbClove: string;
}
class GreenBean extends Vegetable {
    nbBean: string;
}

function cookGarlic(g: Garlic) { };
function cloneVegetable(source: Vegetable, done: (result: Vegetable) => void): void {  };
let b = new Bean();
							
cloneAnimal(b, cookGarlic); // ERREUR, empêche d'utiliser cookGarlic avec un GreenBean

1
2
3
4
5
6

function makeLowerCase(s: string) {
   return s.toLowerCase();
}
							
declare let foo: Promise<string | number>;
foo.then(makeLowerCase); // ERREUR, empêche d'appeler makeLowerCase avec un number

strictPropertyInitialization (TypeScript 2.7)

Cette option comme son nom l’indique, force l’initialisation des champs d’une classe soit dans le constructeur ou directement lors de la déclaration du champs. Exemple :

1
2
3
4
5
6
7
8
9

class C {
   foo: number;
   bar = "hello";
   baz: boolean; // ERROR

   constructor() {
      this.foo = 42;
   }
}

1
2
3
4
5
6
7
8
9

class C {
   foo!: number; // ‹-- definite assignment assertion
                            
   constructor() {}

   onInit() {
      this.foo = 10;
   }
}

Et voilà, j’éspère que cette article vous à donné envie d’utiliser l’option strict sur tout vos projet TypeScript. Elle aporte vraiment une grosse plus value en terme de contrôle des types !

Dernière petite choses avant qu’on se quitte, étant donné que les nouvelles versions de TypeScript vont régulièrement inclure de nouvelles sous-options, n’oubliez pas en premier lieu de :

• désactivez ces sous-options lors de la mise à jour
• bien comprendre ce qu’elle font
• les activer et corriger les errreurs qu’elles remontent :)

A très vite !