TypeScript 2.3 disponible en Release Candidate
Avec le support des générateurs et itérateurs asynchrones
Le 2017-04-14 19:14:29, par yahiko, Rédacteur/Modérateur
TypeScript 2.3 en Release Candidate
Le 10 avril, l'équipe TypeScript a sorti la RC de la version 2.3 de ce langage, surensemble typé de JavaScript.
Elle peut être installée avec NuGet ou npm :
Le plugin TypeScript 2.3 pour Visual Studio 2015 Update 3 est disponible ici.
Pour les autres éditeurs, il convient de veiller à utiliser la dernière version du compilateur : Visual Studio Code, Sublime Text 3.
L'option --strict
Par défaut, le système de typage de TypeScript est très tolérant afin de permettre aux développeurs de typer graduellement.
Il existe cependant des options au niveau du compilateur pour que celui-ci soit plus restrictif sur la façon de typer. Dans l'esprit dans lequel il a été conçu, le langage encourage les réglages les plus stricts, car ce sont eux qui offrent le plus de garanties quant à la qualité du code produit (en contrepartie, d'un nombre de messages d'erreur plus élevé).
Le problème, c'est qu'au fil du temps, le compilateur s'est vu affublé de beaucoup d'options différentes : --noImplicitAny, --strictNullChecks, --noImplicitThis, et --alwaysStrict sont les options les plus courantes. Seulement, cela nécessite de s'en souvenir et rend de fait TypeScript un peu plus difficile à utiliser.
C'est pourquoi la version 2.3 introduit l'option --strict. Cette option active l'ensemble des restrictions sur l'utilisation des types. Il reste possible de désactiver individuellement chaque restriction à l'aide du fichier projet tsconfig.json :
À l'avenir, --strict pourra inclure d'autres vérifications utiles à tous les développeurs, mais qui pourront être désactivées manuellement et explicitement comme dans l'exemple plus haut.
Compatibilité ES3 et ES5 des générateurs & itérateurs
Avant la version 2.3, les générateurs n'étaient pas supportés en ciblant de l'ES3 ou de l'ES5 à cause des boucles for..of qui ne fonctionnaient qu'avec des tableaux en mode ES3/ES5.
Désormais, les générateurs sont disponibles en ES3 et ES5 en utilisant l'option --downlevelIteration, rendant plus simple l'utilisation de bibliothèques comme redux-saga.
Générateurs et itérateurs asynchrones
Cette version 2.3 de TypeScript permet également d'utiliser des générateurs et itérateurs asynchrones (async) conformément à la proposition TC39.
Les itérateurs asynchrones sont une fonctionnalité ECMAScript à venir qui permet aux itérateurs de produire de façon asynchrone des résultats. Ils peuvent être consommés proprement par des fonctions asynchrones avec une construction syntaxique nommée les boucles asynchrones comme ci-dessous :
Les générateurs asynchrones sont des générateurs qui peuvent être mis en pause (await) à n'importe quel endroit. Ils sont déclarés en utilisant la syntaxe suivante :
Voici un exemple combinant les différentes constructions :
Il convient de garder à l'esprit que le support des itérateurs asynchrones repose sur l'existence de Symbol.asyncIterator à l'exécution. Un polyfill pour émuler Symbol.asyncIterator peut être nécessaire, ce qui pour des cas d'utilisation basiques pourrait ressembler à ceci :
ou encore
Pour compiler en ES5 ou antérieur, l'option --downlevelIteration est également nécessaire ainsi que l'option --lib incluant esnext.
source : Blog officiel de Microsoft
Attendiez-vous ces nouvelles fonctionnalités ?
Le 10 avril, l'équipe TypeScript a sorti la RC de la version 2.3 de ce langage, surensemble typé de JavaScript.
Elle peut être installée avec NuGet ou npm :
npm install -g typescript@rc
Le plugin TypeScript 2.3 pour Visual Studio 2015 Update 3 est disponible ici.
Pour les autres éditeurs, il convient de veiller à utiliser la dernière version du compilateur : Visual Studio Code, Sublime Text 3.
L'option --strict
Par défaut, le système de typage de TypeScript est très tolérant afin de permettre aux développeurs de typer graduellement.
Il existe cependant des options au niveau du compilateur pour que celui-ci soit plus restrictif sur la façon de typer. Dans l'esprit dans lequel il a été conçu, le langage encourage les réglages les plus stricts, car ce sont eux qui offrent le plus de garanties quant à la qualité du code produit (en contrepartie, d'un nombre de messages d'erreur plus élevé).
Le problème, c'est qu'au fil du temps, le compilateur s'est vu affublé de beaucoup d'options différentes : --noImplicitAny, --strictNullChecks, --noImplicitThis, et --alwaysStrict sont les options les plus courantes. Seulement, cela nécessite de s'en souvenir et rend de fait TypeScript un peu plus difficile à utiliser.
C'est pourquoi la version 2.3 introduit l'option --strict. Cette option active l'ensemble des restrictions sur l'utilisation des types. Il reste possible de désactiver individuellement chaque restriction à l'aide du fichier projet tsconfig.json :
Code : |
1 2 3 4 5 6 | { "compilerOptions": { "strict": true, "noImplicitThis": false } } |
Fichier tsconfig.json avec toutes les restrictions de typage activées, sauf pour --noImplicitThis.
À l'avenir, --strict pourra inclure d'autres vérifications utiles à tous les développeurs, mais qui pourront être désactivées manuellement et explicitement comme dans l'exemple plus haut.
Compatibilité ES3 et ES5 des générateurs & itérateurs
Avant la version 2.3, les générateurs n'étaient pas supportés en ciblant de l'ES3 ou de l'ES5 à cause des boucles for..of qui ne fonctionnaient qu'avec des tableaux en mode ES3/ES5.
Désormais, les générateurs sont disponibles en ES3 et ES5 en utilisant l'option --downlevelIteration, rendant plus simple l'utilisation de bibliothèques comme redux-saga.
Générateurs et itérateurs asynchrones
Cette version 2.3 de TypeScript permet également d'utiliser des générateurs et itérateurs asynchrones (async) conformément à la proposition TC39.
Les itérateurs asynchrones sont une fonctionnalité ECMAScript à venir qui permet aux itérateurs de produire de façon asynchrone des résultats. Ils peuvent être consommés proprement par des fonctions asynchrones avec une construction syntaxique nommée les boucles asynchrones comme ci-dessous :
Code : |
1 2 3 | for await (let item of items) { /*...*/ } |
Code : |
1 2 3 | async function* asyncGenName() { /*...*/ } |
Code : |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | // Renvoie une Promise qui est résolue après un certain délai. function sleep(milliseconds: number) { return new Promise<void>(resolve => { setTimeout(resolve, milliseconds); }); } // Ceci convertit l'itérable passé en argument en un itérable asynchrone. // Chaque élément est retourné (yield) avec un délai. async function* getItemsReallySlowly<T>(items: Iterable<T>) { for (const item of items) { await sleep(500); yield item; } } async function speakLikeSloth(items: string[]) { // Patiente avant chaque itération jusqu'à ce qu'un résultat soit disponible. for await (const item of getItemsReallySlowly(items)) { console.log(item); } } speakLikeSloth("never gonna give you up never gonna let you down".split(" ")); |
Code : |
(Symbol as any).asyncIterator = Symbol.asyncIterator || Symbol.from("Symbol.asyncIterator");
Code : |
(Symbol as any).asyncIterator = Symbol.asyncIterator || "__@@asyncIterator__";
source : Blog officiel de Microsoft
-
benjamin_musiqueMembre habituéJe l'utilise dans un 1er projet avec Angular (je travaille pour une grande entreprise industrielle).
Le typage étant optionnel pour moi ça n'a que des avantages
Même si on a peur pour sa pérennité, les personnes ayant investi sur Silverlight me comprendront!le 15/05/2017 à 10:11 -
yahikoRédacteur/ModérateurSilverlight, auquel je n'ai jamais cru, était une techno propriétaire.
TypeScript à contrario, est un langage open source qui a un réel souci des standards actuels du Web, au point même dans les réflexions actuelles sur la feuille de route, de limiter au maximum les extensions de la syntaxe du langage sur des aspects "peu JavaScript", comme les classes par exemple.
Personnellement, je trouve cela un peu dommage, mais je peux comprendre la logique de l'équipe TypeScript de coller au maximum à JavaScript et aux prochaines recommandations du comité ECMAScript.le 21/05/2017 à 1:09 -
PaleoMembre éclairéLes choix de design de TypeScript en font une technologie pérenne. Vos mauvaises surprises viendront d'Angular.
Sur quelle discussion ?le 22/05/2017 à 10:57 -
yahikoRédacteur/ModérateurJe faisais implicitement référence à un long débat sur les classes partielles (partial classes) qui a été tranché récemment par l'un des collaborateurs Microsoft de l'équipe TypeScript.
Voici son commentaire censé clore le débat :
Envoyé par RyanCavanaugh le 29/05/2017 à 14:40 -
PaleoMembre éclairéMerci. J'avais effectivement raté cette discussion.le 30/05/2017 à 8:19