In unserer weiten Welt des Web-Buildings haben wir jede Gelegenheit, über Werkzeuge zu sprechen. Wir stürzen uns, um jede Lücke zu füllen, die wir in unseren Projekten finden, mit einem definitiven technologischen Ansatz. Einige von uns erhalten einen „Sitz am Tisch“, wo wir uns mit den winzigsten technologischen Debatten beschäftigen. Dieser Marktplatz der Meinungen gründet sich auf den Wunsch, zumindest für den Moment, ein Optimum zu erreichen. Wir postulieren über Werkzeuge, damit wir Effizienz erreichen, unsere Erkundungsreichweite erweitern oder den schnellsten Weg zur Machbarkeit ebnen können.
Wenn Sie etwas auf dieser Website gelesen haben, sind Sie wahrscheinlich mehr als vertraut mit dem Konzept des Imposter-Syndroms – der lähmenden Erkenntnis, dass Sie die Position, die Sie innehaben, nicht verdienen oder nicht wissen, was Sie wissen sollten. Diejenigen von uns, die gelernt haben, mit dem Imposter-Syndrom umzugehen, laufen Gefahr, in das (was ich bei mir selbst erkenne) Relevanz-Syndrom zu verfallen – eine Komplikation des Imposter-Syndroms im mittleren Karriereverlauf. Es ist das, was passiert, wenn man jahrelang das Mantra wiederholt: „Ich habe es verdient, hier zu sein“, aber seine Prämisse nie wirklich akzeptiert hat. Es passiert, wenn man versucht, die Abschwächung seiner Hard Skills zu kompensieren und stattdessen seine Soft Skills verhärtet. Relevanz zu wahren ist sicherlich ein guter Grund, über Werkzeuge zu sinnieren.
Damit lehne ich mich beiläufig gegen diese Ziegelwand, schiebe meine Sonnenbrille auf die Spitze meiner ach-so-relevanten Nase und erwähne abweisend, dass ja, ich auch, habe TypeScript gelernt. Ein Jahr Erfahrung später kann ich sagen, dass ich es ziemlich lieb gewonnen habe.
Ich möchte den Zweck von TypeScript nutzen, um einen separaten Punkt zu machen, also bitte ich Sie, mich bei diesem schnellen Beispiel zu begleiten.
TypeScript erzwingt unter anderem die Typen von Dingen, die Sie herumschicken. Nehmen Sie diese JavaScript-Funktion, die zwei Zahlen multipliziert
const product = (x, y) => x * y;Stellen Sie sich vor, Sie brechen Ihre Regeln, indem Sie diese Funktion ohne numerische Argumente aufrufen, wie z. B. product('A', 'B'). Es gibt viele Möglichkeiten, diese Funktion zu validieren, um dieses Szenario abzufangen, aber Ihre Validierung findet nur zum Zeitpunkt der Ausführung statt – während das Skript läuft, oft im Browser. Sie können dies erst debuggen, wenn diese Ereignisse eintreten. Was TypeScript tun kann, ist, Ihnen zu sagen, dass Sie die Regeln bevor der Ausführung brechen – während Sie Ihren Code schreiben. Dazu geben Sie an, welche Typen von Dingen Sie verwenden.
const product = (x: number, y: number) => x * y;Hier geben wir Typen für die beiden Argumente an und sagen, dass die Variablen x und y beide ein number sind. Wenn Sie diese Funktion nun mit falschen Argumenttypen verwenden würden, würde Ihr Anwendungsskript beim Erstellen lautstark fehlschlagen. Da Ihr Skript funktionieren muss, bevor es erstellt werden kann, müssen Sie sich nie darum sorgen, dass diese Art von Fehlern in freier Wildbahn auftritt. Das erfordert jedoch viel Aufwand. Sie müssen Ihre Typen überall definieren.
😍
Sie finden das Schreiben von TypeScript-Typen vielleicht wie das Organisieren eines Bücherregals. Sie legen einige Regeln fest, die, wenn sie befolgt werden, eine optimale Organisation erzielen, die leicht nachzuschlagen ist.
🙅♂️
Oder Sie finden das Schreiben von TypeScript-Typen vielleicht wie das Zwingen Ihres Kindes zu außerschulischen Aktivitäten gegen seinen Willen. Es ist starr unversöhnlich und lässt Ihren Code nicht herausfinden, wer er ist und wohin er geht! Sie behindern seine Entwicklung, indem Sie Ihren Willen aufzwingen!
Ich denke, es gibt genauso viel Potenzial für Wert in einem gut organisierten Bücherregal wie für Einfallsreichtum in einem unabhängigen Geist, und von beidem gibt es so viel zu lernen.
Lassen Sie uns noch einmal über Relevanz nachdenken.
Sie fühlen sich vielleicht unter Druck gesetzt, zu wissen, was Sie tun, bevor Sie es tun – sich selbst zu typisieren, bevor Ihr Code ausgeführt wird. Sie fühlen sich vielleicht unter Druck gesetzt, alle Ihre Fehler und Lernerfahrungen zu berücksichtigen, bevor Sie es öffentlich versuchen. Das, meine Freunde, ist ein immenser Aufwand, den Sie auf sich genommen haben, um Ihren Typ zu erhalten. Es ist ein Druck und eine Starrheit, die wir manchmal unserer Software gerne aufzwingen, die aber unfair ist, sich selbst oder anderen gegenüber anzuwenden.
Wir alle haben unsere "1" + "1" = "11" Momente. Sie sind relevant und zutiefst menschlich, wenn nicht sogar eine Form von Genie. Nehmen Sie sie an. Sie strikt zu verhindern ist nicht skalierbar.
Ich habe das Gefühl, in diesem Moment gelernt zu haben, wie man dieses Jahr TypeScript lernt, und hoffe, das zu halten, was auch immer für ein Typ mich das macht.
Das gibt Ihnen den falschen Eindruck, dass Sie qualitativ hochwertigen Code haben. Dass Sie keine bedingten Anweisungen schreiben müssen, um sicherzustellen, dass die Parameter die erwarteten Typen haben, dass Sie keine Unit-Tests schreiben müssen, weil TS Typen überprüft.
Alles falsch!!!
Das zwingt Sie nur dazu, etwas – völlig unnötigen – Code zu schreiben, der Ihnen das warme (aber falsche) Gefühl gibt, dass Sie „typsicher“ sind.
Dafür ist ein zusätzlicher Build-Schritt erforderlich, um Ihnen diese Lüge zu erzählen.
Spezielle Werkzeuge zum Ausführen von Tests (offensichtlich – auch in TS) und noch mehr Overhead, nur damit Sie sich selbst anlügen können, dass Ihr Code besser ist als der von echten JS-Entwicklern, die tatsächlich WISSEN, WAS SIE TUN, aber nur JS benutzen!
TS ist der Fluch meines Lebens!
Erzwungen von dummen Managern, weil F* M$ ihnen sagt, und F* M$ weiß es, weil es groß ist!
Es ist das Schlimmste, was der Frontend-Entwicklung seit GWT passiert ist, und zwar von der gleichen Art von Leuten!
Leute, die JS verabscheuen und denken, dass JS repariert werden muss, weil es Mist ist.
Leute, die an C/Java und andere serverseitige Sprachen gewöhnt sind, die nicht ohne all ihre künstlichen Einschränkungen und Begrenzungen auskommen können, und die JS einfach einschränken & limitieren müssen, damit sie beim Schreiben damit überleben können.
Halten Sie sich nicht zurück. Sagen Sie uns bitte, was Sie wirklich denken.
Ich stimme Ihnen teilweise zu, dass TypeScript ein Pflaster auf eine Sprache ist, die über das hinaus gestreckt wird, wofür sie ursprünglich geschaffen wurde.
Ich werde nicht sagen, dass JS kaputt ist, aber auch wenn man weiß, was man tut, heißt das nicht, dass das Team von „X“ Teammitgliedern weiß, was man zu diesem Zeitpunkt gedacht hat. Und da scheinen so viele Leute gegen Kommentare im Code zu sein, werden wir bei diesem Pflaster bleiben :)
Es wäre schön, eine Option zu haben, um Typenprüfungen auch zur Laufzeit zu erzwingen.
Jake, danke, dass Sie Ihre Erfahrungen mit dem Bleiben relevanten geteilt haben. Ich liebe es, wie Sie sich selbst dafür loben, gelernt zu haben, TypeScript zu lernen. Ich lerne TypeScript, indem ich Screeps spiele und es mit Hilfe des fantastischen https://github.com/screepers/screeps-typescript-starter Pakets verwende, das Rollup für die Bereitstellung nutzt. Machen Sie weiter so!