Pourquoi devriez-vous apprendre TypeScript et abandonner JavaScript ? TypeScript contre JavaScript

Vous n'êtes pas marié à JavaScript, peu importe à quel point vous l'aimez, vous devez essayer TypeScript. Peut-être que vous n'avez aucune raison de déménager, mais je vais vous emmener dans un voyage, où vous aimeriez goûter un peu à TypeScript. Je peux vous donner plus de 13 raisons pour lesquelles vous devriez passer à TypeScript, mais pour l'instant, je vais essayer de vous convaincre de passer à TypeScript en 5 points où je vous expliquerai pourquoi TypeScript est bien meilleur que JavaScript pour le développement, et pourquoi vous devriez choisir TypeScript pour votre prochain projet.

JavaScript strictement typé

TypeScript n'est rien d'autre qu'un javascript strictement typé. L'une des raisons pour lesquelles je déteste JavaScript (oui, je le déteste) est qu'il y a tellement de flexibilité dans le langage qu'il n'y a pas de règles ni de réglementations, vous pouvez écrire n'importe quoi et cela ne vous donnera pas d'erreur (il y a des exceptions) , par exemple, si vous avez créé une variable et lui avez donné un numéro comme valeur, disons 6, plus tard vous pourrez attribuer une fonction à la même variable, et même appeler cette variable, cela me semble un peu drôle, de toute façon, voyons quoi TypeScript a à voir avec ça.

En dactylographié, lors de la définition d'une variable, vous devez écrire son type, comme si la variable stockerait un nombre, un tableau, une chaîne ou toute autre chose. Une fois que vous l'avez fait, vous ne pouvez plus y stocker quoi que ce soit d'autre, sinon TypeScript ne vous laissera pas continuer, et TypeScript est strict à ce sujet.

let age: number;
age = 25;

Même si vous ne mentionnez pas le type de la variable et ne lui attribuez pas une valeur, elle est trop intelligente, car elle découvre automatiquement le type à partir de la valeur donnée et s'en souvient.

let age = 10;

age = "Donald Trump"
~~~
// Type '"Donald Trump"' is not assignable to type 'number'.(2322)

Si vous connaissez les langages comme C/C , là, le type est défini comme int age ; de même, dans TypeScript, nous définissons le type après le nom de la variable après un signe deux-points, comme ceci let age: number;. De cette façon, nous avons simplement bourré TypeScript sans modifier la syntaxe JavaScript. C'est ce que je vous ai dit au début, TypeScript n'est pas seulement du JavaScript, avec juste des types. Je ne me concentrerai pas sur la syntaxe du TypeScript, cela n'entre pas dans le cadre de cet article.

Maintenant, si c'était JS, vous pourriez faire n'importe quoi avec l'âge, en lui attribuant votre nom, ou un tableau, ou même une fonction, mais dans TS, une fois qu'il est né sous forme de nombre, il restera un nombre , rien d'autre. Si vous le faites, cela vous donnera immédiatement une erreur, mais en JS, il la tolérera tant que vous ne faites pas quelque chose d'illégal, comme appeler age sans lui attribuer de fonction ou accéder à la propriété .length quand c'est le cas. une fonction.

Au début, cela peut vous sembler inutile de passer de JS à TS, mais une fois que vous l'avez bien compris, vous n'avez jamais voulu coder en JS à cause de cette fonctionnalité uniquement.

Parce qu'il faut des erreurs.

Quand je dis que vous avez besoin d'erreurs, cela ne veut pas dire que je veux que vous écriviez des codes erronés, mais le code que vous avez écrit doit être sans erreur, et pour cela, c'est le travail de votre environnement de développement de vous donner erreurs. Et en JS, cela ne le fait tout simplement pas, c'est l'une des raisons pour lesquelles les gens l'aiment, et en même temps le détestent aussi. Quand je dis erreurs, je parle de tout sauf des erreurs de syntaxe. JS ne donne pas d'erreur lorsque vous écrivez quelque chose de mal, mais il vous donne une erreur lorsque quelque chose de mal se produit. Donc, si une partie de votre code n'est pas exécutée au moment du test, préparez-vous à des difficultés lors de la production. :)
Voyons un exemple

J'écris un code pour multiplier deux nombres, je le ferai à la fois en JS et en TS, et vous verrez à quel point JS est si peu fiable et peut casser votre application de plusieurs manières.

let age: number;
age = 25;

Vous pouvez littéralement appeler multiplier de n'importe quelle manière, il n'y a aucune restriction, et cela vous donne toujours des résultats inattendus, c'est la pire chose à propos de JS, supposons que maintenant vous deviez utiliser ces valeurs renvoyées quelque part, combien d'incohérences et de résultats inattendus cela provoque dans votre candidature.

Mais grâce à TypeScript, c'est très strict, il ne vous laissera pas continuer si vous ne suivez pas les règles si la fonction attend le, alors vous devez passer le nombre, et il dit que les deux doivent être des nombres, alors vous doit passer deux arguments et les deux doivent être des nombres. Voyons le même code dans TypeScript. Si vous ne connaissez pas la syntaxe TS, ne vous inquiétez pas, elle est similaire à JS, sauf que le type de retour précède l'accolade ouvrante et les types d'arguments avec leurs noms.

let age = 10;

age = "Donald Trump"
~~~
// Type '"Donald Trump"' is not assignable to type 'number'.(2322)

Donc ici dans TS, il n'y a jamais de résultats imprévisibles, vous ne pouvez continuer que lorsque vous supprimez toutes les erreurs, c'est ce qui me fait tomber amoureux de TS <3

TS n'est pas seulement tenu d'indiquer les erreurs dans votre code que vous avez écrit, mais il vous indique également la possibilité d'où une erreur peut survenir. Voyons un exemple rapide de cela.

function multiply (num1, num2 ) {
    return num1 * num2;
}

console.log(multiply(3, 4));
// returns 12

console.log(multiply(3));
// return NaN

console.log(multiply(3, null));
// returns 0

console.log(multiply());
// returns NaN

Maintenant, comme vous pouvez le voir, la propriété sociale est facultative, ce qui signifie qu'il peut y avoir des cas où le social n'est pas défini, TS le sait, et il ne vous laissera pas continuer tant que vous ne l'aurez pas géré.

function multiply (num1:number, num2:number) :number{
    return num1 * num2;
}

console.log(multiply(3, 4));
// returns 12

console.log(multiply(3));
//          ~~~~~~~~~~~
// Expected 2 arguments, but got 1.(2554)
// input.tsx(1, 33): An argument for 'num2' was not provided.

console.log(multiply(3, null));
//                      ~~~~
// Argument of type 'null' is not assignable to parameter of type 'number'.


console.log(multiply());
//          ~~~~~~~~~~~
// Expected 2 arguments, but got 0.(2554)
// input.tsx(1, 20): An argument for 'num1' was not provided.

Donc, ceci est ignoré en silence par JS, et cela provoque des erreurs au cas par cas, ce qui est une autre raison pour laquelle TS est considéré comme plus fiable.

Testé automatiquement et documenté.

Supposons que vous utilisiez une fonction d'une bibliothèque écrite en JS, comment sauriez-vous quels paramètres vous devez transmettre ? Vous irez à la documentation, vous vérifierez quels paramètres cela prendra, lesquels sont facultatifs, puis vous appellerez la fonction. Mais dans TS, il n'est pas nécessaire de documenter cela, tout s'explique par les types eux-mêmes. Même cela garantit également que vous utilisez la fonction de la bonne manière et que vous ne transmettez aucun paramètre aléatoire.

Par exemple, vous pouvez vous référer à la deuxième section ci-dessus.

Un autre cas que vous pouvez prendre est, supposons que vous utilisez une bibliothèque qui vous donne un objet JS, avec des propriétés imbriquées, donc vérifier quels sont exactement les noms des propriétés, et lesquelles d'entre elles peuvent être indéfinies, est un gros problème. douleur. Vous devez fouiller dans la documentation, ou parfois enregistrer votre objet dans la console pour voir ce qu'il contient. C'est vraiment ce que je déteste, je souhaite d'une manière ou d'une autre, où l'objet lui-même vous indique quelles propriétés il contient et si une propriété n'est pas définie, ou si une propriété a une chaîne de valeur, un nombre ou un tableau ou quoi. Eh bien, le souhait est exaucé, grâce encore une fois à TypeScript. Si les codes sont écrits en TS, vous obtiendrez le comportement exact. Voyons avec un exemple.

let age: number;
age = 25;

Maintenant, pour vérifier quelles propriétés l'utilisateur aura, pas besoin de le connecter à la console, ni d'aller à la définition de la fonction lorsque vous ajoutez un . après l'utilisateur, il vous donne automatiquement la liste des propriétés dont il dispose et vous indique également lesquelles d'entre elles ne sont pas définies. Voir l'image ci-dessous.

Il teste également automatiquement vos codes en vérifiant toutes les possibilités et vous indique si l'une des possibilités échoue. Cela semble incroyable, eh bien oui, ça l'est. Cette fonctionnalité évite un grand nombre de bugs au moment du développement, vous n'avez pas besoin d'écrire un test pour votre fonction ni de la tester manuellement à différentes valeurs, TS le fait pour vous et vous indique si vous avez manqué quelque chose. cela pourrait poser un problème plus tard.

Dans le code ci-dessous, j'ai écrit une fonction qui prend deux arguments et renvoie un tableau de chaînes en ajoutant chaque paramètre au tableau s'ils ne sont pas indéfinis. Le premier argument est obligatoire tandis que le second est facultatif.

let age = 10;

age = "Donald Trump"
~~~
// Type '"Donald Trump"' is not assignable to type 'number'.(2322)

Le code ci-dessus est un scénario très courant dans lequel je fais une erreur. Array.push ne renvoie pas le tableau mis à jour, mais renvoie la nouvelle longueur du tableau. Donc, si le code ci-dessus est écrit dans le JS, il n'y aura aucune erreur, et mon code s'exécute simplement et donne les résultats attendus, que je dois déboguer et trouver l'erreur ici, et ma fonction renvoie 2 si je passe le deuxième argument aussi. Mais ici, dans TS, vous pouvez clairement voir que TypeScript exécute automatiquement le cas et vous indique que dans ce cas particulier, votre fonction ne parviendra pas à renvoyer un tableau de chaînes.

Il y a une autre erreur, disons que si vous ne transmettez pas le deuxième paramètre, vous ne renvoyez toujours rien (indéfini), ce qui viole également le comportement de votre fonction car elle doit renvoyer un tableau de chaînes. Donc, ici, j'ai apporté quelques modifications à la fonction et TS vous donne un drapeau vert, ce qui signifie que la fonction ne vous donnera jamais de résultat inattendu. Voir ci-dessous.

let age: number;
age = 25;

Toujours quelques longueurs d'avance sur JavaScript

Typescript a toujours quelques longueurs d'avance sur Javascript. Si une nouvelle fonctionnalité est annoncée en JavaScript et qu'elle est censée être publiée dans la prochaine version d'ECMA, TS la publie avant la version officielle et vous pouvez l'utiliser sans aucun souci de compatibilité dans les navigateurs car vous pouvez compiler TS vers n'importe quelle version précédente. de JavaScript (comme ES5). TypeScript possède de nombreuses fonctionnalités que JavaScript n'a pas.

Nous pouvons donc dire que TypeScript est également un surensemble de JavaScript, ECMA5, ECMA6, ECMA7 et ECMAnext, et de certaines fonctionnalités qui n'existent même pas en JavaScript.

Conclusion

Oui, tôt ou tard, vous devrez accepter TypeScript. Vous ne pouvez tout simplement pas y échapper. Chaque package npm écrit en JavaScript doit également fournir ses types, ou un autre package prenant en charge TypeScript est préféré. Désormais, la plupart des grandes bibliothèques, packages et frameworks sont écrits en TypeScript.

Au début, les packages étaient également en JavaScript avec le support TypeScript, mais maintenant la situation s'est inversée, et les packages sont en TypeScript et prennent en charge JavaScript. Tout le monde reconnaît la puissance et la nécessité de TypeScript sur JavaScript et l'accepte.

Vous ne pourrez jamais apprendre Angular, car cela vous oblige à écrire uniquement du code TS, même cas avec le bouclage 4. Le langage principal de NestJS est TypeScritpt et ils prennent également en charge JavaScript. Voici les mots de NestJs

Nous sommes amoureux de TypeScript, mais par-dessus tout, nous aimons Node.js. C'est pourquoi Nest est compatible à la fois avec TypeScript et JavaScript pur. Nest profite des dernières fonctionnalités du langage. Pour l'utiliser avec JavaScript Vanilla, nous avons besoin d'un compilateur Babel.

Si vous n'êtes toujours pas satisfait des raisons que je vous ai données et que vous avez des contre-questions, vous pouvez nous contacter à tout moment, et croyez-moi, cela vaut la peine d'essayer, vous ne le regretterez pas.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!