[TypeScript] Hintergrundgrund für das Erscheinen

Die Hintergründe der Entstehung von TypeScript

JavaScript-Schmerzpunkte

Das Aufkommen einer neuen Technologie soll einen bestimmten Schwachpunkt der ursprünglichen Technologie lösen .

Ist JavaScript eine gute Programmiersprache?

Jeder mag nicht die gleiche Meinung haben, aber aus vielen Perspektiven ist JavaScript eine sehr gute Programmiersprache ;

Darüber hinaus kann gesagt werden, dass diese Sprache für lange Zeit nicht ersetzt und in mehr Bereichen weit verbreitet sein wird;

Das berühmte Gesetz von Atwood :

Jeff Atwood, einer der Gründer von Stack Overflow, schlug 2007 das berühmte Gesetz von Atwood vor.

Jede Anwendung, die in JavaScript implementiert werden kann, wird schließlich in JavaScript implementiert.

Tatsächlich haben wir gesehen, dass dieser Satz Schritt für Schritt erfüllt wird :

Wir haben schon immer JavaScript für die Webentwicklung verwendet;

Für die mobile Entwicklung kann die plattformübergreifende Entwicklung mit Hilfe von Frameworks wie ReactNative, Weex und Uniapp erreicht werden, und die plattformübergreifende Technologie verwendet auch JavaScript;

Auch die Entwicklung kleiner Programme ist untrennbar mit JavaScript verbunden;

Wir können Desktop-Anwendungen mit Hilfe von Electron entwickeln;

Die serverseitige Entwicklung kann mithilfe von JavaScript mit Hilfe der Node-Umgebung erfolgen.

Und mit der rasanten Entwicklung des Front-End-Bereichs in den letzten Jahren wurde JavaScript schnell populär und von der Mehrheit der Entwickler geliebt.Mit der Leistungsfähigkeit von JavaScript selbst verwenden immer mehr Menschen JavaScript zum Entwickeln von .

Hat gutes JavaScript keine Nachteile?

Tatsächlich hat die JavaScript-Sprache selbst aufgrund verschiedener historischer Faktoren viele Mängel;

Zum Beispiel ES5 und die frühere Verwendung des Schlüsselworts var über den Bereich;

Beispielsweise ist der ursprünglich von JavaScript entworfene Array-Typ kein zusammenhängender Speicherbereich;

Zum Beispiel hat JavaScript bis heute den Mechanismus der Typerkennung nicht hinzugefügt ;

JavaScript wird langsam besser

Es ist unbestreitbar, dass JavaScript langsam immer besser wird, sowohl auf der Low-Level-Design- als auch auf der Anwendungsebene.

Die Einführung von ES6, 7, 8 usw. hat die Sprache jedes Mal moderner, sicherer und bequemer gemacht.

Aber wissen Sie, dass JavaScript heute noch keinen Fortschritt in der Typprüfung hat (warum die Typprüfung so wichtig ist, werde ich später darüber sprechen).

---

Art des Problems

Zunächst einmal müssen Sie wissen, dass wir uns in der Programmierentwicklung einig sind: Je früher Fehler auftreten, desto besser

Wenn Sie beim Schreiben von Code Fehler finden können, finden Sie sie nicht, wenn der Code kompiliert wird (der Vorteil der IDE besteht darin, uns dabei zu helfen, Fehler während des Code-Schreibvorgangs zu finden).

Wenn Sie während der Codekompilierung Fehler finden können, finden Sie sie nicht, wenn der Code ausgeführt wird (Typüberprüfung kann uns dabei sehr gut helfen).

Wenn Sie Fehler während der Entwicklung finden, finden Sie keine Fehler während des Testens, und wenn Sie Fehler während des Testens finden können, finden Sie keine Fehler nach dem Start.

Was wir nun untersuchen wollen, ist, wie man Fehler im Code während der Codekompilierung findet :

Kann JavaScript das? Nein, schauen wir uns die folgenden Codeprobleme an, die häufig auftreten können.

// 当前foo函数, 在被其他地方调用时, 没有对参数做任何的校验
// 1> 没有对类型进行校验(字符串或数字都可以传入)
// 2> 没有对是否传入参数进行校验
function foo(message) {
    
    
  if (message) {
    
    
    console.log(message.length);
  }
}

foo("Hello World");
foo("你好啊TS");

foo() // 错误的调用代码会报错(IDE不会报错), 报错后续代码不会执行

Hier ist ein sehr häufiger Fehler, den wir machen :

Der Hauptgrund für diesen Fehler liegt darin, dass JavaScript keine Einschränkungen für die übergebenen Parameter auferlegt und dieser Fehler nur während der Laufzeit gefunden werden kann;

Und wenn dieser Fehler auftritt, wirkt sich dies auf die Fortsetzung der nachfolgenden Codeausführung aus, dh das gesamte Projekt stürzt aufgrund eines kleinen Fehlers tief ab .

Du denkst vielleicht: Wie konnte ich nur einen so kleinen Fehler machen?

Wenn wir einfache Demos wie unsere oben schreiben, sind solche Fehler leicht zu vermeiden, und wenn sie es tun, sind sie leicht zu überprüfen;

Aber was ist, wenn wir ein großes Projekt entwickeln? Können Sie garantieren, dass Sie solche Probleme nicht haben werden? Und wenn wir die Klassenbibliothek von jemand anderem aufrufen, woher wissen wir dann, welche Art von Parametern andere uns übergeben lassen? Mit anderen Worten, wenn Sie eine Funktion für andere zur Verwendung kapseln, woher wissen andere, welche Parameter Ihre Funktion übergeben muss?

Wenn wir JavaScript jedoch viele Einschränkungen hinzufügen können, können wir solche Probleme in der Entwicklung vermeiden :

Beispielsweise ist die Nachricht in der Funktion, die wir gerade übergeben haben, ein Typ, der übergeben werden muss.Wenn der Aufrufer sie nicht übergibt , wird während der Kompilierung ein Fehler gemeldet ;

Zum Beispiel verlangen wir, dass es sich um einen String-Typ handeln muss, und wenn andere Typen übergeben werden, wird direkt ein Fehler gemeldet;

Dann können Sie wissen, dass viele Fehler während der Kompilierung gefunden werden, anstatt darauf zu warten, dass sie zur Laufzeit entdeckt und geändert werden;

Einige der Probleme, die durch das Fehlen von Typprüfungen verursacht werden, haben wir bereits kurz erkannt: Da JavaScript von Anfang an Typbeschränkungen nicht berücksichtigt hat, hat es dazu geführt, dass Frontend-Entwickler kein Typdenken haben :

Frontend-Entwickler kümmern sich normalerweise nicht um den Typ von Variablen oder Parametern.Wenn der Typ bestimmt werden muss, müssen wir oft verschiedene Urteile zur Überprüfung verwenden;

Leute, die aus anderen Richtungen zum Frontend gehen, werden sich immer Sorgen machen, dass ihr Code nicht sicher und robust genug ist, weil es keine Typbeschränkung gibt;

Daher sagen wir oft, dass JavaScript nicht für die Entwicklung großer Projekte geeignet ist, denn sobald das Projekt riesig ist, bringt diese lockere Typbeschränkung viele Sicherheitsrisiken mit sich, und es gibt keinen guten Typvertrag zwischen mehreren Personen, die sie entwickeln .

Wenn wir beispielsweise eine Kernklassenbibliothek implementieren, müssen wir, wenn es keine Typbeschränkungen gibt, verschiedene Überprüfungen der von anderen übergebenen Parameter durchführen, um die Robustheit unseres Codes sicherzustellen;

Wenn wir beispielsweise die Funktion eines anderen aufrufen, kommentiert die andere Partei die Funktion nicht.Wir können nur die Logik im Inneren betrachten, um zu verstehen, welche Parameter diese Funktion übergeben muss und welche Art von Rückgabewert erforderlich ist.

Um die Mängel von JavaScript-Type Constraints auszugleichen und Type Constraints zu erhöhen, haben viele Unternehmen eigene Lösungen auf den Markt gebracht :

Im Jahr 2014 startete Facebook Flow zur Typprüfung von JavaScript;

Im selben Jahr brachte Microsoft auch TypeScript 1.0 auf den Markt;

Beide arbeiten an der Typprüfung für JavaScript;

Und jetzt besteht kein Zweifel daran, dass TypeScript vollständig gewonnen hat :

In Vue2.x wird Flow zur Typprüfung verwendet;

Vue3.x ist überall auf TypeScript umgestiegen, und 98,3 % wurden mit TypeScript umgestaltet;

Angular verwendete TypeScript in einem sehr frühen Stadium für das Refactoring von Projekten und muss TypeScript für die Entwicklung verwenden;

Und sogar einige von Facebooks eigenen Produkten verwenden TypeScript;

Das Erlernen von TypeScript kann unserem Code nicht nur Typbeschränkungen hinzufügen, sondern auch unsere Front-End-Programmierer mit Typdenken kultivieren .