Modéliser l’absence de valeur en TypeScript

Avis sur null et undefined

Toutes ces subtilités font que les opinions sont assez divergentes sur l’usage du null :

• Douglas Crockford pense que null est une mauvaise idée et qu’il vaudrait mieux n’utiliser que undefined. Prudence cependant : ce monsieur a fait progresser le JavaScript en maturité, mais il peut aussi adopter des positions extrémistes.
• L’équipe TypeScript n’utilise pas null et ne recommande pas son usage dans ses guidelines sans toutefois donner d’explications.
• À l’inverse, null est largement utilisé dans Angular pour indiquer l’absence de quelque chose, par exemple :
  • La classe DatePipe du module @angular/common a une méthode transform(value, format) pour formater une date, renvoyant null quand la valeur spécifiée est null ou vide.
  • La classe AbstractControl du module @angular/forms a une méthode get(path) qui renvoie le contrôle enfant de chemin spécifié ou null s’il n’a pas été trouvé.
  • La fonction ValidatorFn du module @angular/forms renvoie soit un objet ValidationErrors indiquant les validations en échec, soit null quand la validation a réussi.
  • Mais nous n’avons aucune mention sur null dans son Style Guide.

Mon avis sur la question a évolué pendant l’écriture de cet article et surtout suite aux retours de relecture. Ces retours m’ont fait beaucoup plus approfondir la question, au point de tripler la taille de cette section !

• J’étais au départ réservé sur l’intérêt d’avoir null en plus de undefined. Je voyais aussi des erreurs d’usage qui n’amélioraient pas sa côte de popularité, en particulier le fait d’initialiser les variables à null comme on fait en Java / C♯ alors que ce n’est pas idiomatique en JavaScript / TypeScript.
• Ayant mieux cerné les différences de null par rapport à undefined, je comprends mieux l’usage de ce premier pour signifier l’absence intentionnelle de valeur en particulier en retour d’une fonction hors du happy path. Je pense même qu’on devrait quasiment ne jamais voir de undefined dans le code mais plutôt des champs optionnels (donc des a?: string). La valeur undefined sera toujours présente au runtime mais de manière implicite.
• Je vous laisse vous faire votre propre opinion. L’important reste à mes yeux l’homogénéité de vos bases de code, que l’emploi du null et/ou undefined soit un choix d’équipe et un choix respecté.

Mode strict null check

Ce mode est apparu avec la version 2.0 de TypeScript. Il s’active avec l’option du compilateur TypeScript --strictNullChecks ou son équivalent dans le fichier tsconfig.json. “null” est à prendre au sens large : ce mode permet au compilateur de détecter une “référence null”, par exemple en émettant une erreur de compilation Object x is possibly 'undefined'. C’est donc un must have à activer sur tout nouveau projet TypeScript.

Revers de la médaille : on ne peut plus ignorer les “nulls”, faire semblant qu’ils ne peuvent pas arriver dans telle ou telle partie du code. On est obligé de les prendre en compte :

• En se protégeant à l’aide de guards “if not null then …”,
• En indiquant les types “nullables”, T devenant T | null | undefined dans le pire des cas.

Cela crée une pollution visuelle : le code devient moins lisible mais, deuxième effet Kiss Cool, explicite, honnête en matière de typage. Tout l’objet de ces articles est d’évoquer des alternatives toujours Type Safe mais également plus élégantes, plus simples à lire.

☝️ A partir d’ici, nous serons implicitement en mode strict null check.

Analysons les impacts de ce mode sur la gestion de la valeur par défaut. Pour de plus amples détails sur ce mode, je vous invite à la lire la release note de la version 2.0 très intéressante.

Valeur par défaut

En activant mode strict null check, null et undefined sont ôtés des valeurs possibles pour un élément d’un type quelconque, car ce type est considéré désormais comme “non-nullable” par défaut. Plusieurs options sont possibles pour que cela compile à nouveau :

1. 👍 Conserver le type “non-nullable” et fournir une valeur non “null” :
   • Cela permet d’avoir toujours une valeur significative et de ne pas avoir à se protéger des “nulls”.
   • On peut généralement s’appuyer sur l’inférence de type à partir de la valeur fournie, ce qui donne un code plus succinct et plus proche du JavaScript : let x: MonType → let x = MaValeurParDefaut.
   • La valeur que l’on fournit peut alors être la valeur “neutre” / “vide” du type en question (cf. § suivant).
2. ✔️ Spécifier que le type est “nullable” :
   • Basculer sur un type union pour rajouter au type existant | null ou | undefined ou | null | undefined (ou | nil avec l’astuce ci-dessous) : let x: string = null → let x: string | null = null.
   • Les champs optionnels et les paramètres optionnels sans valeur par défaut représentent un cas particulier. Ils sont spécifiés en utilisant la syntaxe a?: string. Bien que par nature supportant la valeur undefined, il n’est pas nécessaire d’indiquer T | undefined car c’est implicite. En revanche, pas de changement concernant null, toujours à mentionner dans le type : a?: string | null.
3. 💣 Débrancher le compilateur :
   • Avec l’opérateur d’assertion non null ! – appelé opérateur “bang” 💥 – quand la “non-nullité” est garantie par le contexte que l’on connaît mais qui est inaccessible ou mal interprété par le compilateur. On utilise cet opérateur soit dans les expressions comme a!.b, soit dans les déclarations de champ dans les classes : class C { a!: string; ... }. Nous en reparlerons dans le prochain article sur les classes.
   • Avec l’assertion de type préférée des débutants en TypeScript : as any</codebr><br /> → C’est un aveu d’échec à trouver un type satisfaisant…</li> </ul> </li> </ol> <blockquote> <p>💡 <strong>Astuce</strongbr><br /> On peut utiliser l’alias <code class="language-plaintext">type nil = null | undefined pour une syntaxe plus condensée : a: string | nil. On pourra mettre ce type dans un fichier src/types/utility-types.ts et on référencera le dossier dans le fichier tsconfig.json pour rendre ces types accessibles dans tout le projet sans avoir besoin d’imports :

     
     {
       "compilerOptions": {
         "typeRoots": [
           "node_modules/@types",
           "src/types"
         ]
       }
     }
     

     Valeurs vides

     Afin de garder des types “non-nullables”, on peut modéliser leur absence de valeur par une valeur vide. Voyons en quelques exemples :

     • Pour les types primitifs : chaîne vide '', 0 ou -1 pour les nombres, false pour les booléens.
     • Pour les enums, on peut leur rajouter un membre None ou équivalent si c’est cohérent avec les autres membres.
     • Pour les tableaux, [] ne convient pas tel quel car son type est any[]. Il faut indiquer le type cible : messages: string[] = []. On pourrait également écrire messages = new Array<string>() mais c’est moins idiomatique.
     • Pour les objets, ne convient pas non plus. Son type est <code class="kb-btn"/code> c’est-à-dire un objet litéral sans membre propre. On peut avoir recours à une assertion de type telle que <code class="language-plaintext">address = {} as Address qui est plus laxiste en matière de compatibilité de types. Mais c’est risqué. Un type correct serait Partial<Address> mais c’est reculer pour mieux sauter : chaque membre sera optionnel !

     Au besoin, on peut avoir recours à des patterns comme le Null Object ou le type Maybe que l’on détaillera chacun dans leur article respectif.

     👋 Curiosité en TypeScript

     On peut séparer déclaration et affectation d’une variable, y compris “non-nullable” : let a: string; ... a = '';.
     Entre les deux, a est undefined.

     » Cela ne figure pas sur son type. C’est déroutant ! 😕

     Concrètement, le type indique que l’on ne peut pas assigner la valeur undefined, mais pas que la variable ne vaut jamais undefined, non ? 😅

     » En fait, si ! Pour les développeurs, c’est vrai ! Comment ? 😲

     En pratique, le compilateur nous garantit que la variable que l’on va utiliser ne sera jamais undefined car, si l’on tente de s’en servir pendant cette phase transitoire, on aura l’erreur de compilation Variable 'a' is used before being assigned 😆

     Conclusion

     Nous avons vu que l’absence de valeur était souvent représentée par “null” et que cela rendait le code sensible à une catégorie de bugs pernicieux. C’est le cas aussi en JavaScript, mais avec un “null” double : undefined représente l’absence de valeur implicite et plutôt transitoire, null indique une valeur absente de manière intentionnelle et plutôt définitive.

     Ce qui démarque TypeScript est son mode strict null check qui rend explicite et choisie cette potentielle absence de valeur via les types “nullables”. Cela rend également explicite – car obligatoire – la gestion de la “nullabilité” et le fardeau qui en découle. Mais le code est plus "honnête", il ne cache pas de “nulls”. C’est également une occasion de chercher une modélisation la plus possible dénuée de “nulls”.

     Cela nous a amené à considérer l’emploi de valeurs “vides” dont nous avons quelques exemples. Nous continuerons cette analyse en nous concentrons sur les classes qui tiennent une place importante en TypeScript, pour aborder au final des modélisations alternatives plus élégantes.

     Remerciements

     👏 Un grand merci à Nourdine Falola pour sa relecture pointue et ses suggestions éclairantes.

     © SOAT
     Toute reproduction interdite sans autorisation de l’auteur