Annuaire d'articles
Le contexte de l'émergence de TypeScript
Problèmes JavaScript
L'émergence de toute nouvelle technologie consiste à résoudre un certain point douloureux de la technologie d'origine .
JavaScript est-il un bon langage de programmation ?
Tout le monde n'a peut-être pas le même avis, mais à bien des égards, JavaScript est un très bon langage de programmation ;
De plus, on peut dire que ce langage ne sera pas remplacé avant longtemps, et sera largement utilisé dans plus de domaines ;
La fameuse loi d'Atwood :
Jeff Atwood, l'un des fondateurs de Stack Overflow, a proposé la fameuse loi d'Atwood en 2007.
Toute application pouvant être implémentée en JavaScript sera éventuellement implémentée en JavaScript.
En fait, nous avons vu que cette phrase s'accomplit pas à pas :
Nous avons toujours utilisé JavaScript pour le développement Web ;
Pour le développement mobile, le développement multiplateforme peut être réalisé à l'aide de frameworks tels que ReactNative, Weex et Uniapp, et la technologie multiplateforme utilise également JavaScript ;
Le développement de petits programmes est également indissociable de JavaScript ;
Nous pouvons développer des applications de bureau avec l'aide d'Electron ;
Le développement côté serveur peut être effectué en utilisant JavaScript à l'aide de l'environnement Node.
Et avec le développement rapide du domaine frontal ces dernières années, JavaScript a été rapidement popularisé et apprécié par la majorité des développeurs.Avec l'aide de la puissance de JavaScript lui-même, de plus en plus de personnes utilisent JavaScript pour développer .
Un bon JavaScript n'a-t-il aucun inconvénient ?
En fait, en raison de divers facteurs historiques, le langage JavaScript lui-même présente de nombreuses lacunes ;
Par exemple, ES5 et l'utilisation précédente du mot-clé var à propos de la portée ;
Par exemple, le type tableau conçu à l'origine par JavaScript n'est pas un espace mémoire contigu ;
Par exemple, jusqu'à aujourd'hui JavaScript n'a pas ajouté le mécanisme de détection de type ;
JavaScript s'améliore lentement
Il est indéniable que JavaScript s'améliore lentement, tant au niveau de la conception de bas niveau qu'au niveau de l'application.
L'introduction d'ES6, 7, 8, etc., a rendu le langage plus moderne, plus sûr et plus pratique à chaque fois.
Mais sachez qu'aujourd'hui, JavaScript n'a toujours pas progressé dans la vérification de type (pourquoi la vérification de type est si importante, j'en parlerai plus tard).
type de problème
Tout d'abord, vous devez savoir que nous avons un consensus dans le développement de la programmation : plus tôt les erreurs apparaissent, mieux c'est
Si vous pouvez trouver des erreurs lors de l'écriture du code, ne les trouvez pas lorsque le code est compilé (l'avantage de l'IDE est de nous aider à trouver les erreurs pendant le processus d'écriture du code).
Si vous pouvez trouver des erreurs lors de la compilation du code, ne les trouvez pas lorsque le code s'exécute (la vérification de type peut très bien nous aider à le faire).
Si vous pouvez trouver des bogues pendant le développement, ne trouvez pas de bogues pendant les tests, et si vous pouvez trouver des bogues pendant les tests, ne trouvez pas de bogues après le lancement.
Maintenant, ce que nous voulons explorer, c'est comment trouver des erreurs dans le code lors de la compilation du code :
JavaScript peut-il le faire ? Non, examinons les problèmes de code suivants qui peuvent se produire fréquemment.
// 当前foo函数, 在被其他地方调用时, 没有对参数做任何的校验
// 1> 没有对类型进行校验(字符串或数字都可以传入)
// 2> 没有对是否传入参数进行校验
function foo(message) {
if (message) {
console.log(message.length);
}
}
foo("Hello World");
foo("你好啊TS");
foo() // 错误的调用代码会报错(IDE不会报错), 报错后续代码不会执行
Voici une erreur très courante que nous commettons :
La principale raison de cette erreur est que JavaScript n'impose aucune restriction sur les paramètres que nous passons dans , et cette erreur ne peut être trouvée que pendant l'exécution ;
Et lorsque cette erreur se produit, cela affectera la poursuite de l'exécution ultérieure du code, c'est-à-dire que l'ensemble du projet plantera profondément à cause d'une petite erreur ;
Vous vous dites peut-être : comment ai-je pu faire une erreur aussi mineure ?
Lorsque nous écrivons des démos simples comme la nôtre ci-dessus, des erreurs comme celle-ci sont faciles à éviter, et quand elles le font, elles sont faciles à vérifier ;
Mais qu'en est-il lorsque nous développons un grand projet ? Pouvez-vous garantir que vous n'aurez pas un tel problème ? Et si nous appelons la bibliothèque de classes de quelqu'un d'autre, comment savons-nous quel type de paramètres les autres nous laissent passer ? En d'autres termes, si vous encapsulez une fonction pour que d'autres puissent l'utiliser, comment les autres sauront-ils quels paramètres votre fonction doit transmettre ?
Cependant, si nous pouvons ajouter beaucoup de restrictions à JavaScript, nous pouvons éviter de tels problèmes de développement :
Par exemple, le message dans la fonction que nous venons de passer est un type qui doit être passé, si l'appelant ne le passe pas, une erreur sera signalée lors de la compilation ;
Par exemple, nous exigeons qu'il s'agisse d'un type String, et si d'autres types sont passés, une erreur sera signalée directement ;
Vous pouvez alors savoir que de nombreuses erreurs sont détectées lors de la compilation, au lieu d'attendre d'être découvertes et modifiées lors de l'exécution ;
Nous avons déjà brièvement réalisé certains des problèmes causés par l'absence de vérification de type.Comme JavaScript n'a pas pris en compte les contraintes de type dès le début de sa conception, cela a amené les développeurs front-end à manquer de réflexion sur les types :
Les développeurs front-end ne se soucient généralement pas du type de variables ou de paramètres.Si le type doit être déterminé, nous devons souvent utiliser divers jugements pour vérifier ;
Les personnes qui vont au front-end depuis d'autres directions craindront toujours que leur code ne soit pas suffisamment sûr et robuste car il n'y a pas de contrainte de type ;
Par conséquent, nous disons souvent que JavaScript n'est pas adapté au développement de projets à grande échelle, car une fois que le projet est énorme, cette contrainte de type lâche apportera beaucoup de risques de sécurité, et il n'y a pas de bon contrat de type entre plusieurs personnes qui les développent .
Par exemple, lorsque nous implémentons une bibliothèque de classes de base, s'il n'y a pas de contraintes de type, nous devons effectuer diverses vérifications sur les paramètres passés par d'autres pour assurer la robustesse de notre code ;
Par exemple, lorsque nous appelons la fonction de quelqu'un d'autre, l'autre partie ne commente pas la fonction. Nous ne pouvons que regarder la logique à l'intérieur pour comprendre quels paramètres cette fonction doit transmettre et quel type de valeur de retour est requis ;
Afin de pallier les lacunes des contraintes de type JavaScript et d'augmenter les contraintes de type, de nombreuses entreprises ont lancé leurs propres solutions :
En 2014, Facebook a lancé un flux pour vérifier le type de JavaScript ;
La même année, Microsoft a également lancé TypeScript 1.0 ;
Ils travaillent tous les deux à fournir une vérification de type pour JavaScript ;
Et voilà, nul doute que TypeScript a totalement gagné :
Dans Vue2.x, le flux est utilisé pour la vérification de type ;
Vue3.x est passé à TypeScript à tous les niveaux et 98,3 % ont été refactorisés à l'aide de TypeScript ;
Angular a utilisé TypeScript pour la refactorisation du projet à un stade très précoce et doit utiliser TypeScript pour le développement ;
Et même certains des propres produits de Facebook utilisent TypeScript ;
Apprendre TypeScript peut non seulement ajouter des contraintes de type à notre code, mais aussi cultiver nos programmeurs frontaux avec la pensée de type .