Hallo Freunde! Ich bin's, Daniel.
Wenn du mich im wirklichen Leben kennst, hast du wahrscheinlich schon einmal gehört, wie ich ausführlich über JavaScript geredet habe. Mein erster professioneller Programmierjob bestand fast ausschließlich aus Vanilla JavaScript, deshalb liebe ich JS schon seit langem. Im Gegensatz zu anderen finde ich seine Macken und Exzentrizitäten liebenswert. Die prototypische Vererbung ist anfangs ein bisschen verrückt, aber für den täglichen Gebrauch ist sie eigentlich ziemlich einfach. Ich habe schon viele Modeerscheinungen kommen und gehen sehen (ich schaue dich an, Coffeescript). Trotzdem hat es lange gedauert, bis ich auf den Typescript-Zug aufgesprungen bin. Aber jetzt, wo ich hier bin? Ich bin ALL IN.
I Liebe Typescript. Du kannst klar verständliche Verträge für deine Datenstrukturen, Funktionen und Klassen festlegen und sie zur Kompilierzeit durchsetzen. Das heißt, wenn jemand etwas missbraucht oder einen Vertrag/eine Schnittstelle ändert, wird das bemerkt. vor und deine Nutzerinnen und Nutzer zu verletzen. Es ist ein Code, der erklärt, wie er verwendet werden soll. Was gibt es daran nicht zu lieben? Ich habe bereits auf diese Weise über JS nachgedacht, warum sollte ich nicht noch eine Ebene hinzufügen, um meine Gedanken zu erklären? Das eignet sich hervorragend für Teams oder funktionsübergreifende Aufgaben, aber auch für die Zukunft (nachdem ich geschlafen und alles vergessen habe).
Wir verwenden Typescript in meinem Job™ aber das war nicht immer so. Ich arbeite in einer Anwendung, die mumble-mumble Jahren mit vielen Code-Generationen - von den Tagen des klassenbasierten React mit Redux+Thunks bis hin zu moderneren funktionalen Komponenten auf Basis von React Hooks. Es ist, als würde man sich durch felsige Sedimentschichten wühlen, um das historische Warum und Wie freizulegen. Alles Neue ist in Typescript geschrieben und das fühlt sich großartig an - aber es war nicht hilfreich, wenn wir uns in ältere Funktionen vertiefen mussten (oder *gasp* Schulden bereinigen). Als wir merkten, wie viel Spaß es macht, unsere neuen Komponenten zu nutzen (und wie weh es tut, die alten zu benutzen), wollte ich schneller ans Ziel kommen. Ich wollte in der Zukunft leben, nicht in der Vergangenheit.
Enter AirBnBs erstaunlich praktisches Tool, ts-migrate.

Ich wollte schneller ankommen. Ich wollte in der Zukunft leben, nicht in der Vergangenheit.
Dieses tolle Tool durchläuft deine gesamte Codebasis und konvertiert alle .js(x) Dateien zu .ts(x).
Ich weiß, ich weiß, das fühlt sich schmutzig an. Es verwendet standardmäßig das gefürchtete jede Datentyp, was ein bevorzugtes Verbot ist. An Stellen, an denen es nicht weiß, wie die Typen zusammenwirken sollen, fügt es einen Kommentar ein, der Typescript anweist, die nächste Zeile zu ignorieren. Ich weiß, ich weiß, das fühlt sich nicht weniger schmutzig an.
ABER hör zu. Diese JS-Dateien verhalten sich bereits im Wesentlichen auf diese Weise. Es gibt keine Typen, also ist alles bereits ein jeder.
Ungeachtet des Ekels hat dies mindestens zwei unmittelbare strategische Vorteile:
- Das Einbinden neuer Komponenten in alte Komponenten ist jetzt typsicher. Vor dieser Änderung hätten sie genauso gut normales JS sein können, wenn wir sie in alten Code einbauen mussten.
- Das bedeutet, dass unser neuer Typescript-Code jetzt die Qualität der alten Dateien anhebt, anstatt dass die alten Dateien die gesamte Codebasis herunterziehen.
- Jede einzelne Stelle, die beachtet werden muss, um wirklich Typescript-fähig zu sein, ist nun mit einem Kommentar oder einem jede Datentyp. Wir versuchen, jede alte Datei zu bereinigen, die angefasst wird, eine nach der anderen. Das Aufzählen des Umfangs eines Problems kann selbst zeitaufwändig sein - bei diesem Ansatz ist es schon erledigt.
Es ist ein Code, der erklärt, wie er verwendet werden soll. Was kann man daran nicht mögen?
Ich weiß, dass einige von euch dieses "schmutzige" Gefühl noch nicht losgeworden sind, aber ich sage euch. wird dein Leben besser sein. Unseres ist definitiv besser. Wir konnten JS-Dateien verbieten und so die Übernahme weiter erzwingen. Wir haben eine klare Auflistung unserer verbleibenden JS-Schulden. Und das Aufräumen alter Dateien ist nicht mehr ein unüberwindbares Chaos, sondern ein einfacher Zusatz zur bestehenden Arbeit.
Die positiven Vorteile überwiegen bei weitem die Bedenken wegen der Unordnung, die durch einen automatisierten Prozess entsteht. Das war uns nicht klar, bevor wir es eingesetzt haben, aber im Nachhinein ist es glasklar. Ist es das nicht immer?
Nimm die Zukunft an - es dauert nur eine Weile und du wirst es nicht bereuen.

Dies ist eine großartige Lektüre für jeden JS-Entwickler, der zögert, auf TypeScript umzusteigen. Die ehrliche Sicht des Autors auf das schmutzige Gefühl der automatisierten Konvertierung und wie sie letztendlich die Codequalität verbessert, ist nachvollziehbar und inspirierend. Sehr zu empfehlen!