Amélioration du comportement des types d'appel d'unionLorsque TypeScript a une union de type A | B, il vous permet d’accéder à toutes les propriétés communes à A et B (c’est-à-dire à l’intersection des membres).
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | interface A { aProp: string; commonProp: string; } interface B { bProp: number; commonProp: number } type Union = A | B; declare let x: Union; x.aProp; // error - 'B' doesn't have the property 'aProp' x.bProp; // error - 'A' doesn't have the property 'bProp' x.commonProp; // okay! Both 'A' and 'B' have a property named `commonProp`. |
Ce comportement doit sembler intuitif: vous ne pouvez extraire une propriété d’un type d’union que si elle est connue pour appartenir à tous les types d’union.
Au lieu d’accéder aux propriétés, qu’en est-il des types d’appel? Eh bien, quand CHAQUE type a exactement une signature avec des paramètres identiques, tout fonctionne et vous pouvez appeler ces types.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 | type CallableA = (x: boolean) => string; type CallableB = (x: boolean) => number; type CallableUnion = CallableA | CallableB; declare let f: CallableUnion; let x = f(true); // Okay! Returns a 'string | number'. |
Cependant, cette restriction était parfois … trop restrictive.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | type Fruit = "apple" | "orange"; type Color = "red" | "orange"; type FruitEater = (fruit: Fruit) => number; // eats and ranks the fruit type ColorConsumer = (color: Color) => string; // consumes and describes the colors declare let f: FruitEater | ColorConsumer; // Cannot invoke an expression whose type lacks a call signature. // Type 'FruitEater | ColorConsumer' has no compatible call signatures.ts(2349) f("orange"); |
Exemple simple et faible message d'erreur mis à part, FruitEaters et ColorConsumers devraient pouvoir prendre la chaîne "orange" et renvoyer un nombre ou une chaîne.
Dans TypeScript 3.3, ce n'est plus une erreur.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | type Fruit = "apple" | "orange"; type Color = "red" | "orange"; type FruitEater = (fruit: Fruit) => number; // eats and ranks the fruit type ColorConsumer = (color: Color) => string; // consumes and describes the colors declare let f: FruitEater | ColorConsumer; f("orange"); // It works! Returns a 'number | string'. f("apple"); // error - Argument of type '"apple"' is not assignable to parameter of type '"orange"'. f("red"); // error - Argument of type '"red"' is not assignable to parameter of type '"orange"'. |
Dans TypeScript 3.3, les paramètres de ces signatures sont intersectés pour créer une nouvelle signature. Dans l'exemple ci-dessus, les paramètres fruit et color sont croisés ensemble pour former un nouveau paramètre de type Fruit & Color. Fruit & Color est vraiment identique à ("apple" | "orange") & ("red" | "orange") , ce qui équivaut à ("apple" & "red") | ("apple" & "orange") | ("orange" & "red") | ("orange" & "orange"). Chacune de ces intersections impossibles s’évapore, et nous nous retrouvons avec "orange" & "orange" , qui est juste "orange".
Il y a toujours quelques restrictions cependant. Ce nouveau comportement ne se déclenche que lorsque au plus un type de l'union comporte plusieurs surcharges et qu'au plus un type de l'union possède une signature générique. Cela signifie des méthodes sur le number[] | string[] comme map (qui est générique) ne sera toujours pas appelable.
D'autre part, des méthodes telles que forEach pourront désormais être appelées, mais sous noImplicitAny, certains problèmes peuvent survenir.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | interface Dog { kind: "pupper" dogProp: any; } interface Cat { kind: "kittyface" catProp: any; } const catOrDogArray: Dog[] | Cat[] = []; catOrDogArray.forEach(animal => { // ~~~~~~ error! // Parameter 'animal' implicitly has an 'any' type. }); |
Bien que Microsoft continue à améliorer l'expérience ici, cela est strictement plus efficace dans TypeScript 3.3, et l'ajout d'une annotation de type explicite fonctionnera.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | interface Dog { kind: "pupper" dogProp: any; } interface Cat { kind: "kittyface" catProp: any; } const catOrDogArray: Dog[] | Cat[] = []; catOrDogArray.forEach((animal: Dog | Cat) => { if (animal.kind === "pupper") { animal.dogProp; // ... } else if (animal.kind === "kittyface") { animal.catProp; // ... } }); |
Surveillance incrémentielle des fichiers pour les projets composites dans --build --watch"]Surveillance incrémentielle des fichiers pour les projets composites dans --build --watch
Dans TypeScript 3.0, Microsoft a introduit une nouvelle fonctionnalité pour structurer les générations appelées «projets composites». Une partie de l'objectif ici était de s'assurer que les utilisateurs puissent diviser des projets volumineux en parties plus petites qui se construisent rapidement et préservent la structure du projet, sans compromettre l'expérience existante de TypeScript. Grâce aux projets composites, TypeScript peut utiliser le mode --build pour ne recompiler que l’ensemble des projets et des dépendances. Vous pouvez considérer cela comme une optimisation des générations entre projets.
Cependant, l’année dernière, l'équipe TypeScript a également fourni des versions optimisées du mode -- watch via une nouvelle API incrémentielle de «constructeur». Dans le même esprit, l'idée est que ce mode ne vérifie et ne réémet que les fichiers modifiés ou les fichiers dont les dépendances peuvent avoir une incidence sur la vérification du type. Vous pouvez considérer cela comme une optimisation des générations intra-projet.
Ironiquement, la construction de projets composites à l’aide de --build --watch n’a pas utilisé cette infrastructure. Une mise à jour dans un projet sous le mode --build --watch forcerait la génération complète de ce projet, plutôt que de déterminer quels fichiers de ce projet étaient affectés.
Dans TypeScript 3.3, l’indicateur --watch du mode de construction tire également parti de la surveillance incrémentielle des fichiers. Cela peut signifier des constructions beaucoup plus rapides sous --build --watch. Lors de nos tests, cette fonctionnalité a entraîné une réduction de 50% à 75% des temps de construction des temps de construction d'origine. Vous pouvez en savoir plus sur la demande d'extraction initiale du changement pour voir des numéros spécifiques, mais Microsoft pense que la plupart des utilisateurs de projets composites verront des gains importants ici.
Édition de JavaScript dans Sublime Text
Envoyé par MicrosoftGrâce au travail de Zhengbo Li, ancien membre de l'équipe TypeScript, et de @idiotWu, contributeur à la communauté, notre plugin TypeScript pour Sublime Text prend désormais en charge la modification de fichiers JavaScript! Cela signifie que les utilisateurs obtiendront des complétions plus précises, renommeront, passeront à la définition, et plus encore, dans du code JavaScript qui utilise JSDoc et interagit avec le code TypeScript.
Source : Microsoft
Voir aussi :
VS Code : Microsoft annonce la disponibilité d'IntelliCode pour le développement TypeScript/JavaScript, et espère améliorer la productivité Google s'oriente vers TypeScript et voici pourquoi, selon Evan Martin, un ingénieur de la firme qui travaille sur le langage Babel : la version 7.0 du transpileur JavaScript est disponible avec le support de TypeScript et bien d'autres nouvelles fonctionnalités TypeScript 2.9 est disponible et intègre plusieurs nouveautés, le langage continue de compléter son système de typage 
