1 pièce(s) jointe(s)
TypeScript 4.3 est disponible et apporte le mot-clé override
Microsoft annonce TypeScript 4.3 RC, elle apporte un support de l'éditeur pour les balises @link,
et améliore le temps de compilation pour les modes --incremental et --watch
Dans un article publié sur son blog le 12 mai, Microsoft a annoncé la Release Candidate (RC) de TypeScript 4.3, extension de JavaScript qui ajoute des types statiques et la vérification de type. Elle apporte un support de l'éditeur pour les balises @link et améliore le temps de compilation pour les modes --incremental et --watch. « Aujourd'hui, nous sommes heureux d'annoncer la disponibilité de la Release Candidate (RC) de TypeScript 4.3 ! nous ne prévoyons pas d'autres changements, à part des corrections de bogues critiques avant la sortie de la version stable de TypeScript 4.3. Pour commencer à utiliser la RC, vous pouvez l'obtenir via NuGet, ou utiliser npm avec la commande suivante : npm install typescript@rc », a déclaré Daniel Rosenwasser, le responsable TypeScript chez Microsoft.
TypeScript est un langage de programmation libre et open source développé par Microsoft qui a pour but d'améliorer et de sécuriser la production de code JavaScript. Il s'agit d'un surensemble du JavaScript qui apporte un typage statique et optionnel des variables. Il permet de détecter certaines erreurs en amont et se compile en JavaScript pour une utilisation côté navigateur ou côté serveur à l'aide de NodeJS. Notons qu’avec l’utilitaire npm les développeurs JavaScript peuvent partager et réutiliser facilement leur code. Il facilite la mise à jour du code et est distribué avec Node.js. TypeScript présente plusieurs avantages :
- la prévention des bogues et la maintenabilité du code ;
- la prise en charge des interfaces, des sous-interfaces, des classes, des sous-classes ;
- la capacité de programmer en orienté objet avec l’héritage des membres privés et des interfaces.
En début d’année, plus précisément en février, Microsoft a annoncé la disponibilité de TypeScript 4.2, avec la prise en charge d'Abstract Constructor Types et des contrôles plus stricts pour l'opérateur in. Voici, ci-dessous, les nouveautés apportées par la Release Candidate de TypeScript 4.3 :
Amélioration du temps de compilation pour les modes --incremental et --watch
Un des problèmes avec les modes --incremental et --watch est que, bien qu'ils accélèrent les compilations ultérieures, la compilation initiale peut être un peu plus lente, voir assez lente dans certains cas. Cela est dû au fait que ces modes doivent effectuer un certain nombre d'opérations comptables, en calculant des informations sur le projet en cours, et parfois en enregistrant ces données dans un fichier.tsbuildinfo pour les compilations ultérieures.
C'est pourquoi, en plus des améliorations de la taille de .tsbuildinfo, TypeScript 4.3 apporte également des modifications aux modes --incremental et --watch qui rendent la première construction d'un projet avec ces paramètres aussi rapide qu'une construction ordinaire. Pour ce faire, la plupart des informations qui seraient normalement évaluées à l'avance sont plutôt effectuées à la demande pour les constructions ultérieures.
Bien que cela puisse ajouter une certaine surcharge à une construction ultérieure, les fonctions --incremental et --watch de TypeScript fonctionneront toujours sur un ensemble de fichiers beaucoup plus petit, et toute information nécessaire sera sauvegardée par la suite. Les constructions --incremental et --watch deviendront plus rapides lors de la compilation une fois que les fichiers auraient été mis à jour.
Déclarations de complétion
L'un des principaux problèmes que rencontrent les utilisateurs avec les instructions d'importation et d'exportation en JavaScript est l'ordre. Les importations sont écrites comme suit :
Code:
import { func } from "./module.js";
au lieu de
Code:
from "./module.js" import { func };
Cela cause quelques problèmes lors de l'écriture d'une déclaration d'importation complète à partir de zéro étant donné que la complétion automatique n'était pas capable de fonctionner correctement. Par exemple, si on commence à écrire quelque chose comme import « { », TypeScript n'a aucune idée du module à partir duquel le programmeur prévoit d'importer, de sorte qu'il ne peut pas fournir de compléments descendants.
Pour pallier ce problème, Microsoft a tiré parti de la puissance des auto-importations. Les auto-importations traitent déjà le problème de ne pas être en mesure de réduire les compléments d'un module spécifique. Leur but est de fournir toutes les exportations possibles et d'insérer automatiquement une déclaration d'importation en haut du fichier.
Ainsi, lorsqu'on commence à écrire une déclaration d'importation qui n'a pas de chemin, Microsoft fournit une liste d'importations possibles. Lorsqu’on effectue une complétion, nous remplissons la déclaration d'importation complète, y compris le chemin qui sera écrit.
Types d'écriture séparés sur les propriétés
En JavaScript, il est assez courant que les API convertissent les valeurs qui leur sont transmises avant de les stocker. Cela se produit aussi souvent avec les getters et setters. Par exemple, imaginons que nous ayons une classe avec un setter qui convertit toujours une valeur en un nombre avant de l'enregistrer dans un champ privé.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class Thing {
#size = 0;
get size() {
return this.#size;
}
set size(value) {
let num = Number(value);
// Don't allow NaN and stuff.
if (!Number.isFinite(num)) {
this.#size = 0;
return;
}
this.#size = num;
}
} |
Dans l’exemple ci-dessus, TypeScript peut faire abstraction des types explicites et considérer que size est un nombre. Le problème est que size permet de lui affecter plus que des nombres. Nous pourrions contourner ce problème en indiquant que size a le type unknown ou any comme dans cet extrait de code :
Code:
1
2
3
4
5
6
| class Thing {
// ...
get size(): unknown {
return this.#size;
}
} |
Cependant, ce n’est pas une solution louable. Unknown oblige les personnes qui lisent la taille à faire une assertion de type. Selon Microsoft, les versions précédentes de TypeScript nous ont obligés à choisir entre être précis (ce qui facilite la lecture des valeurs et rend l'écriture plus difficile) et être permissif (ce qui facilite l'écriture des valeurs et rend la lecture plus difficile) si on veut vraiment modéliser des API qui convertissent des valeurs.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| class Thing {
#size = 0;
get size(): number {
return this.#size;
}
set size(value: string | number | boolean) {
let num = Number(value);
// Don't allow NaN and stuff.
if (!Number.isFinite(num)) {
this.#size = 0;
return;
}
this.#size = num;
}
} |
Dans l'exemple ci-dessus, l’accesseur set prend un ensemble plus large de types (strings, booleans, et numbers), mais l’accesseur get garantit toujours que ce sera un nombre. Avec TypeScript 4.3 RC, il est enfin possible d’affecter d'autres types à ces propriétés sans aucune erreur.
Support de l'éditeur pour les balises @link
Avec cette RC, TypeScript peut maintenant comprendre les balises @link, et essaiera de résoudre les déclarations auxquelles elles sont liées. Cela signifie qu’il est possible de survoler les noms dans les balises @link et obtenir plus rapidement des informations, ou utiliser des commandes comme go-to-definition ou find-all-references.
Définition des chemins d'accès aux fichiers non-JavaScript
De nombreux chargeurs permettent aux utilisateurs d'inclure des ressources dans leurs applications à l'aide d'importations JavaScript. Ils sont généralement écrits sous la forme d'un fichier comme import ./styles.css. Jusqu'à présent, la fonctionnalité d'édition de TypeScript n'essayait même pas de lire ce fichier, de sorte que la définition de base échouait généralement. Au mieux, go-to-definition sautait à une déclaration telle que déclare module *.css s'il pouvait trouver quelque chose de ce genre.
TypeScript essaie maintenant de sauter au fichier correct lorsqu’on effectue un go-to-definition sur des chemins de fichiers relatifs, même s'il ne s'agit pas de fichiers JavaScript ou TypeScript. Il est désormais possible avec des importations de CSS, SVG, PNG, fichiers de police, fichiers Vue, et plus encore.
Source : Microsoft
Et vous ?
:fleche: Avez-vous une expérience avec TypeScript ?
:fleche: Que pensez-vous de TypeScript ?
:fleche: Quelle amélioration vous intéresse le plus sur cette version ?
Voir aussi :
:fleche: La version bêta de TypeScript 4.2 est disponible avec le type tuple plus amélioré et une préservation plus intelligente des alias de type
:fleche: Microsoft publie TypeScript 4.2 avec la prise en charge de Abstract Constructor Types et des contrôles plus stricts pour l'opérateur in
:fleche: Prisma : un ORM de nouvelle génération pour Node.js et TypeScript, pour concurrencer TypeORM et Sequelize et devenir la norme de l'industrie
:fleche: Comment un développeur JavaScript anti-TypeScript est devenu un fan de TypeScript ? Voici les raisons de Chirag Swadia, un développeur JavaScript reconverti en développeur TypeScript
1 pièce(s) jointe(s)
TypeScript 4.3 est disponible et apporte le mot-clé override
TypeScript 4.3 est disponible et apporte le mot-clé override pour qu'un utilisateur puisse indiquer clairement
s'il avait l'intention d'ajouter une nouvelle méthode ou de remplacer une méthode existante
Si vous n'êtes pas encore familiarisé avec TypeScript, c'est un langage qui s'appuie sur JavaScript en ajoutant une syntaxe pour les types statiques. Des outils comme le compilateur TypeScript peuvent simplement effacer la syntaxe TypeScript, vous laissant avec un JavaScript propre et lisible qui fonctionne n'importe où. Alors, qu'est-ce que cette syntaxe ajoute si elle est simplement effacée ? Eh bien, lorsque vous ajoutez des types dans tout votre code, vous rendez vos intentions explicites, et TypeScript peut vérifier le type de votre code pour détecter les erreurs telles que les fautes de frappe, les erreurs de logique, etc. TypeScript utilise également ces types pour alimenter les outils de l'éditeur, vous offrant des fonctionnalités intéressantes telles que la complétion précise de code, le changement de nom et la possibilité de vous rendre directement à une définition.
Types d'écriture séparés sur les propriétés
En JavaScript, il est assez courant pour les API de convertir les valeurs transmises avant de les stocker. Cela arrive souvent aussi avec les getters et les setters. Par exemple, imaginons que nous ayons une classe avec un setter qui convertit toujours une valeur en number avant de l'enregistrer dans un champ privé.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class Thing {
#size = 0;
get size() {
return this.#size;
}
set size(value) {
let num = Number(value);
// Don't allow NaN and stuff.
if (!Number.isFinite(num)) {
this.#size = 0;
return;
}
this.#size = num;
}
} |
Comment taper ce code JavaScript dans TypeScript ? Eh bien, techniquement, nous n'avons rien à faire de spécial ici - TypeScript peut regarder cela sans types explicites et peut comprendre que la size est un nombre.
Le problème est que la size vous permet de lui attribuer plus que de simples number. Nous pourrions contourner ce problème en disant que la size a le type unknown ou any comme dans cet extrait de code:
Code:
1
2
3
4
5
6
| class Thing {
// ...
get size(): unknown {
return this.#size;
}
} |
Mais ce n’est pas bon - unknown oblige les personnes qui lisent size à faire une assertion de type, et any ne détecte d’erreur. Microsoft explique alors « si nous voulons vraiment modéliser des API qui convertissent des valeurs, les versions précédentes de TypeScript nous ont obligés à choisir entre être précis (ce qui facilite la lecture des valeurs et écrire plus dur) et être permissif (ce qui facilite l'écriture des valeurs et la lecture plus difficile) ».
C’est pourquoi TypeScript 4.3 vous permet de spécifier des types de lecture et d’écriture dans les propriétés.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| class Thing {
#size = 0;
get size(): number {
return this.#size;
}
set size(value: string | number | boolean) {
let num = Number(value);
// Don't allow NaN and stuff.
if (!Number.isFinite(num)) {
this.#size = 0;
return;
}
this.#size = num;
}
} |
Dans l'exemple ci-dessus, notre accesseur set prend un ensemble plus large de types (chaînes, booléens et nombres), mais notre accesseur get garantit toujours qu'il s'agira d'un nombre. Maintenant, nous pouvons enfin attribuer d'autres types à ces propriétés sans erreur!
Code:
1
2
3
4
5
6
7
8
9
| let thing = new Thing();
// Assigning other types to `thing.size` works!
thing.size = "hello";
thing.size = true;
thing.size = 42;
// Reading `thing.size` always produces a number!
let mySize: number = thing.size; |
Lorsque l'on considère la relation entre deux propriétés portant le même nom, TypeScript n'utilisera que le type « lecture » (par exemple, le type sur l'accesseur get ci-dessus). Les types « écriture » ne sont pris en compte que lors de l'écriture directe dans une propriété.
Gardez à l'esprit qu'il ne s'agit pas d'un modèle limité aux classes. Vous pouvez écrire des getters et des setters avec différents types dans les littéraux d'objet.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| function makeThing(): Thing {
let size = 0;
return {
get size(): number {
return size;
},
set size(value: string | number | boolean) {
let num = Number(value);
// Don't allow NaN and stuff.
if (!Number.isFinite(num)) {
size = 0;
return;
}
size = num;
}
}
} |
En fait, Microsoft a ajouté une syntaxe aux interfaces / types d'objets pour prendre en charge différents types de lecture / écriture sur les propriétés.
Code:
1
2
3
4
5
| // Now valid!
interface Thing {
get size(): number
set size(value: number | string | boolean);
} |
L’une des limites de l’utilisation de différents types pour la lecture et l’écriture de propriétés est que le type de lecture d’une propriété doit être attribuable au type que vous écrivez. En d'autres termes, le type getter doit être assignable au setter. Cela garantit un certain niveau de cohérence, de sorte qu'une propriété est toujours attribuable à elle-même.
override et --noImplicitOverride
Lorsque vous étendez des classes en JavaScript, le langage rend très facile le remplacement des méthodes - mais malheureusement, vous pouvez rencontrer des erreurs. Il manque un grand nombre de noms. Par exemple, prenez les classes suivantes:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| class SomeComponent {
show() {
// ...
}
hide() {
// ...
}
}
class SpecializedComponent extends SomeComponent {
show() {
// ...
}
hide() {
// ...
}
} |
SpecializedComponent sous-classe SomeComponent et remplace les méthodes show et hide. Que se passe-t-il si quelqu'un décide de supprimer show et hide et de les remplacer par une seule méthode?
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| class SomeComponent {
- show() {
- // ...
- }
- hide() {
- // ...
- }
+ setVisible(value: boolean) {
+ // ...
+ }
}
class SpecializedComponent extends SomeComponent {
show() {
// ...
}
hide() {
// ...
}
} |
Notre SpecializedComponent n'a pas été mis à jour. Une partie du problème ici est qu'un utilisateur ne peut pas indiquer clairement s'il avait l'intention d'ajouter une nouvelle méthode ou de remplacer une méthode existante. C’est pourquoi TypeScript 4.3 ajoute le mot-clé override.
Code:
1
2
3
4
5
6
7
8
| class SpecializedComponent extends SomeComponent {
override show() {
// ...
}
override hide() {
// ...
}
} |
Lorsqu'une méthode est marquée par override, TypeScript s'assurera toujours qu'une méthode portant le même nom existe dans une classe de base.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| class SomeComponent {
setVisible(value: boolean) {
// ...
}
}
class SpecializedComponent extends SomeComponent {
override show() {
// ~~~~~~~~
// Error! This method can't be marked with 'override' because it's not declared in 'SomeComponent'.
// ...
}
// ...
} |
Il s’agit d’une grande amélioration, mais cela n’aide pas si vous oubliez d’écrire un override sur une méthode - et c’est également une grave erreur que les utilisateurs peuvent rencontrer.
Par exemple, vous pourriez accidentellement « piétiner » une méthode qui existe dans une classe de base sans vous en rendre compte.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| class Base {
someHelperMethod() {
// ...
}
}
class Derived extends Base {
// Oops! We weren't trying to override here,
// we just needed to write a local helper method.
someHelperMethod() {
// ...
}
} |
C’est pourquoi TypeScript 4.3 fournit également un nouvel indicateur --noImplicitOverride. Lorsque cette option est activée, il devient une erreur de remplacer toute méthode d'une superclasse à moins que vous n'utilisiez explicitement un mot-clé override. Dans ce dernier exemple, TypeScript ferait une erreur sous --noImplicitOverride, et donnerait un indice indiquant qu'il faut probablement renommer notre méthode à l'intérieur de Derived.
Source : Microsoft
