TypeScript 2.0 disponible en bêta
La version 2.0 de TypeScript vient d'être publiée en bêta il y a une semaine et est disponible pour Visual Studio ou en mode standalone via NPM en lançant la ligne de commande suivante :
npm install -g typescript@beta
Elle apporte son lot de nouveautés. Même si à première vue, cela peut ne pas être flagrant, l'une de ces nouveautés constitue un tournant majeur dans l'évolution du langage. Il s'agit des types non nulliffiables (non-nullable types).
Types non nullifiables
Les variables null ou undefined sont deux des principales sources de bogues en JavaScript et obligent le développeur à une programmation défensive fastidieuse, diminuant la lisibilité du code. D'autant que ce n'est pas non plus une garantie absolue, dans la mesure où un oubli reste toujours possible. Le concept des types non nullifiables en TypeScript a pour objectif de répondre à ce besoin.
Avant TypeScript 2.0, null et undefined étaient implicitement inclus dans chaque type, y compris ceux définis par le développeur. Ce qui signifiait que si vous aviez une fonction qui prenait une chaîne de caractères en argument, vous ne pouviez pas être sûr à partir du type si vous aviez réellement une chaîne --- vous pouviez avoir null à la place. Cela nécessitait par conséquent l'usage de la programmation défensive comme en JavaScript traditionnel.
Avec TypeScript 2.0, l'option du compilateur --strictNullChecks change ce principe. Le type string est uniquement une chaîne de caractères et le type number est uniquement un nombre, rien d'autre.
| Code : | Sélectionner tout |
let foo: string = null; // Erreur !!
| Code : | Sélectionner tout |
let foo: string | null = null; // Correct
| Code : | Sélectionner tout |
1 2 3 | declare let str: string | undefined; // variable instanciée ailleurs let upperCased = str.toUpperCase(); // Erreur ! La variable 'str' peut être indéfinie. |
| Code : | Sélectionner tout |
let upperCased = str!.toUpperCase(); // Correct. La variable 'str' est postfixée par l'opérateur !.
Les types non nullifiables sont un changement important dans l'histoire encore jeune de TypeScript dans la mesure où c'est, en exagérant un peu, deux langages qui vont devoir cohabiter : d'un côté, la sémantique des types nullifiables comme c'était le cas jusqu'à présent, et de l'autre, la sémantique des types non nullifiables avec --strictNullChecks. Ces deux sémantiques ne sont pas vraiment compatibles entre elles. Autrement dit, une application devra être pensée en totalité (y compris les modules externes) avec cette logique des types non nullifiables pour avoir une chance de compiler correctement ce qui risque de limiter le succès de cette approche dans un premier temps. Certains préféreront la « souplesse » actuelle où on ne sait pas trop si un objet est null ou pas. Cependant, d'un point de vue de la fiabilité, il serait préférable que cette sémantique plus restrictive des types non nullifiables devienne une bonne pratique à l'avenir. Ceci est d'ailleurs plus conforme à l'esprit global de TypeScript et aura sans doute comme vertu de corriger du code existant, TypeScript, voire JavaScript.
Analyse du flux de contrôle pour les types
La gestion des types non nullifiables a été rendue possible grâce au suivi du typage tout au long du déroulement d'un programme. Dans la version 2.0, des améliorations dans l'inférence de type à tel ou tel endroit précis du code ont été réalisées au cours de l'analyse du flux de contrôle.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | /**
* @param recipients Un tableau de destinataires, ou une liste séparée par des virgules de destinataires.
* @param body Contenu brut du message.
*/
function sendMessage(recipients: string | string[], body: string) {
if (typeof recipients === "string") {
recipients = recipients.split(",");
}
// TypeScript sait que 'recipients' est ici un 'string[]'.
recipients = recipients.filter(isValidAddress);
for (let r of recipients) {
// ...
}
} |
| Code : | Sélectionner tout |
1 2 3 4 5 6 | let bestItem: Item;
for (let item of items) {
if (item.id === 42) bestItem = item;
}
let itemName = bestItem.name; // Erreur ! 'bestItem' peut ne pas avoir été initialisé si 'items' est vide. |
Déclarations de modules simplifiées
Un des reproches qui pouvait être adressé à TypeScript concernait la déclaration fastidieuse des modules écrits en JavaScript.
| Code : | Sélectionner tout |
1 2 3 4 | declare module "foo" {
var x: any;
export = x;
} |
| Code : | Sélectionner tout |
1 2 | declare module "foo"; declare module "bar"; |
Dans le cas où vous devez importer beaucoup de modules, il est aussi possible d'utiliser des caractères génériques dans les déclarations :
| Code : | Sélectionner tout |
declare module "foo/*";
En vrac
Il serait trop long de présenter en détail toutes les autres nouveautés de TypeScript. Mentionnons donc simplement :
- union de types discriminée et garde de types basée sur une propriété d'un objet ;
- spécification du type du paramètre this pour les fonctions ;
- propriété d'un objet en lecture seule ;
- spécification de différents répertoires dans la résolution de module ;
- signatures d'index implicites ;
- constructeurs privés (private) et protégés (protected) ;
- propriétés abstraites (abstract) ;
- propriétés optionnelles dans les classes ;
- nouveau type never ;
- option du compilateur --skipLibCheck ;
- répertoire de sortie des déclarations avec l'option --declarationDir ;
- support des noms de fichiers génériques (glob) dans tsconfig.json ;
- amélioration de la modularité de lib.d.ts et support de la nouvelle option --lib ;
- support des définitions de modules UMD ;
- virgule finale dans la liste des paramètres d'une fonction ;
- étiquette jsdoc @typedef pour les fichiers JS ;
- autocomplétion pour les chaînes littérales ;
- support de l'extension .js dans les noms de modules à l'import ;
- compatibilité mutuelle entre --target:es5 et --module:es6 ;
- marquage des déclarations inutilisées avec les options --noUnusedLocals et --noUnusedParameters
À noter que le support des fonctionnalités asynchrones (async / await) pour ES3 et ES5 n'est toujours pas opérationnel avec cette version 2.0, alors que cela avait déjà été annoncé pour la version 1.8. L'équipe TypeScript l'a reporté pour la prochaine version 2.1 du fait des lourds changements apportés dans le module de transformation de l'arbre syntaxique abstrait et des tests intensifs que cela nécessite. Encore un peu de patience donc.
Toujours est-il que le support de ES6 dans TypeScript atteint à présent 60 % (cf. kangax), à comparer aux 25 % d'il y a un peu plus d'un an et des 74 % de Babel qui semble plafonner.
En conclusion cette nouvelle version est une nouvelle étape majeure dans l'histoire de TypeScript, langage véritablement multiparadigme, tant dans les structures de programmation offertes (classes traditionnelles, prototypes, lambda-fonctions...) que dans le système de typage (statique, dynamique, implicite, explicite, permissif, strict) ce qui reste encore à l'heure actuelle une force et une originalité dans le paysage des langages de programmation.
source : Blog officiel de l'équipe TypeScript
Quelles sont les fonctionnalités qui vous intéressent le plus ?
Vous avez lu gratuitement 0 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
