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.
let foo: string = null; // Erreur !!
Si vous souhaitez une variable nullifiable, il faudra l'expliciter à l'aide d'une union de types.
let foo: string | null = null; // Correct
Cette option --strictNullChecks génère une erreur si on essaie de rendre null ou undefined une variable non nullifiable, mais génère également une erreur à la compilation, et non durant l'exécution, si on tente par exemple d'accéder à une propriété d'un objet nullifiable.
1
2
3
| declare let str: string | undefined; // variable instanciée ailleurs
let upperCased = str.toUpperCase(); // Erreur ! La variable 'str' peut être indéfinie. |
Pour une variable initialement déclarée comme nullifiable, comme dans l'exemple ci-dessus, le langage offre la possibilité de préciser ponctuellement qu'à un instant donné il est garanti qu'elle n'est pas null ou undefined afin de ne pas générer d'erreur via l'option --strictNullChecks. Cela se fait avec l'opérateur postfixe !.
let upperCased = str!.toUpperCase(); // Correct. La variable 'str' est postfixée par l'opérateur !.
Cette nouvelle signification pour l'opérateur ! est syntaxiquement valide sans préciser l'option --strictNullChecks, même si en l'absence de ce dernier, il n'a aucun effet.
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.
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) {
// ...
}
} |
À noter qu'après l'affectation à l'intérieur du bloc if, TypeScript comprend qu'il a affaire à un tableau de chaînes de caractères. Ceci peut permettre de détecter des erreurs tôt dans le processus de développement et gagner du temps sur le débogage.
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.
1
2
3
4
| declare module "foo" {
var x: any;
export = x;
} |
Dans le cas où on ne connait pas encore bien un module, ce qui est souvent le cas lors de la première utilisation, il est désormais possible de court-circuiter les déclarations de variables en type any pour simplement écrire ceci en TypeScript 2.0 :
1
2
| declare module "foo";
declare module "bar"; |
Il sera toujours possible de revenir dessus ultérieurement pour affiner ces déclarations avec des types plus précis.
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 :
Tous les modules dans le répertoire foo seront importés par TypeScript.
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 ?
TypeScript 2.0 disponible
Répondre avec citation
Envoyé par frfancha
Partager