IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

TypeScript 2.3 disponible en Release Candidate
Avec le support des générateurs et itérateurs asynchrones

Le , par yahiko

70PARTAGES

9  0 
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 :
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 : Sélectionner tout
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 : Sélectionner tout
1
2
3
for await (let item of items) {
    /*...*/
}
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 :

Code : Sélectionner tout
1
2
3
async function* asyncGenName() {
    /*...*/
}
Voici un exemple combinant les différentes constructions :

Code : Sélectionner tout
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(" "));
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 :

Code : Sélectionner tout
(Symbol as any).asyncIterator = Symbol.asyncIterator || Symbol.from("Symbol.asyncIterator");
ou encore

Code : Sélectionner tout
(Symbol as any).asyncIterator = Symbol.asyncIterator || "__@@asyncIterator__";
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de benjamin_musique
Membre habitué https://www.developpez.com
Le 15/05/2017 à 10:11
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!
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 21/05/2017 à 1:09
Silverlight, 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.
0  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 22/05/2017 à 10:57
Citation Envoyé par benjamin_musique Voir le message
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!
Les choix de design de TypeScript en font une technologie pérenne. Vos mauvaises surprises viendront d'Angular.

Citation Envoyé par yahiko Voir le message
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.
Sur quelle discussion ?
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 29/05/2017 à 14:40
Je 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 :
Citation Envoyé par RyanCavanaugh
TL;DR: This isn't happening. If you're down here at comment number 189 and want to register your disapproval with that, please do read the entire thread first, because the very good reasons for not adding this have been extensively covered above.

Our interpretation of this situation is as follows:

* TypeScript already has too many TS-specific class features (constructor property declarations, member initializers, non-finalized decorators, access modifiers, implements, etc.) for something that was really intended to just be "ES6 + Types". Part of that is our fault (our original design direction was generally too OOP) and part of that is ES6's fault (the class proposal moved around a lot five years ago and we ended up having features that didn't make it). Adding yet another TS-specific class feature is another straw on the camel's back that we should avoid if we can.

* Unambiguously, the future of JavaScript is modules. Partial classes only make sense and operate well in the "global soup" model. Allowing partial classes spanning multiple modules is a recipe for disaster as the loading order is not predictable. Adding a feature that only works well in a global-only universe isn't a good use of time.

* C# has it but we're not here to reinvent C#. Seriously!

* The "generated code" scenario isn't compelling on the merits. Any plausible emit for partial classes would restrict property initializers and constructor code to exactly one declaration, and this would be a dealbreaker for .Designer.cs-style setups as both the user code and the generated code would likely need initializers or constructor logic.

* There are many, many other compositional mechanisms available in JS - mixins, Object.assign, etc.. The scenario that led to this feature in C# was driven by constraints that simply aren't present in JS.

* The current workaround of interface + prototype.method = ... does enable the generated-code scenario just as well as partial class would. It's weird to write that code by hand but there's no problem for generating code differently, so if you really think a split-file generated code setup is the only way to solve your problem (I'm skeptical) then that method is available to you.

* We consider ES6 to be the arbiter of "must have" for classes. There's nothing special about TypeScript (other than its appeal to C# programmers) that make it need partial classes any more than non-typed JavaScript would. So if there's some scenario that really knocks it out of the park for adding partial classes, then that scenario ought to be able to justify itself through the TC39 process. If that gains traction we'd be happy to weigh in with input on it, but this doesn't even seem to be on anybody's radar.
0  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 30/05/2017 à 8:19
Merci. J'avais effectivement raté cette discussion.
0  0