Waarom je (waarschijnlijk) Typescript zou moeten gebruiken

De huidige positie van Typescript kwam niet uit het niets, omdat die technologie onze ontwikkelaarservaring echt kan verbeteren. Explicietere codering verhoogt de controle en voorspelbaarheid van code.
In dit artikel zal ik je proberen te overtuigen om Typescript te gebruiken.

*- Gegevensbron: Staat van JS 2020 en Stack Overflow enquête voor ontwikkelaars 2020.

Ontdek fouten eerder

Als je een applicatie ontwikkelt in JavaScriptkan je stroom
er als volgt uitzien:

1. Maak een verandering,
2. Ga naar de app en bekijk het gewijzigde onderdeel / Voer (gerelateerde) tests uit.
3. Zoek uit of alles in orde is.

Met Typescript kun je de wijziging doorvoeren en als er een typefout in je code, dan weet je dat meteen dankzij de foutmelding van de compiler of de realtime feedback van de IDE.
Natuurlijk zal de Typescript compiler niet elk probleem oplossen en niet waarschuwen voor alle bugs, maar zijn hulp kan van onschatbare waarde zijn.

Betere syntaxaanvulling in IDE's

Het is heel eenvoudig. Als je goede IDE's gebruikt, zoals WebStorm of VSCode, krijg je
betere syntaxaanvulling met Typescript. Misschien klinkt dit niet als een enorme verbetering van de ervaring van ontwikkelaars, maar uiteindelijk is elke verbetering belangrijk omdat het ons tijd kan besparen en, nogmaals, een typefout of vergissing kan voorkomen. Ook kunnen we ons type of interface één keer definiëren; omdat we niet steeds de structuur hoeven te onthouden, kunnen we ons richten op het schrijven van bedrijfslogica.

Minder pijnlijke refactoring

Stel je voor dat je om wat voor reden dan ook moet refactoren, bijvoorbeeld omdat je bij een project en je krijgt de opdracht om een nieuwe functie toe te voegen, maar die functie is op de een of andere manier verbonden met oudere code.
Typescript kan het makkelijker en minder pijnlijk maken, want als je een wijziging maakt en er is een andere plek waar je nog een wijziging moet maken, dan zal de compiler je daarvoor waarschuwen.

Het kan bijvoorbeeld een gewijzigde functiehandtekening zijn of misschien na de wijziging een
functie zal iets totaal anders retourneren, dus ook het geretourneerde type zal verschillen.

Meer vertrouwen hebben in de codebase

JavaScript is zwak en dynamisch getypeerd, dus als je een variabele initialiseert met de waarde laat query = '' later in de code kan de ontwikkelaar per ongeluk iets irrationeels doen, bijvoorbeeld vraag = waaren het zal een geldige JS-code zijn.

In goed geschreven code zou het toewijzen van een booleaanse waarde aan een variabele die eerder een string was, niet mogen gebeuren. Dus meestal is die toewijzing met typeverandering het gevolg van een fout.

Wanneer we Typescript gebruiken, kunnen we het type van de variabele niet wijzigen, dus als we de laat query = '' variabele, zal het string type en kunnen we het type niet per ongeluk wijzigen.

Als we een variabele meer dan één type willen laten zijn, doen we dat altijd expliciet met union type, bijvoorbeeld tekenreeks | getal.

Daarom maakt Typescript onze code voorspelbaarder en explicieter.
Typescript zorgt ook voor explicietheid in controlestroomanalyse en als er een mogelijkheid is dat er iets fout kan gaan, zal het je waarschuwen.

Hier in voorbeeld in eerste als blok krijgen we een foutmelding:

TS2339: Eigenschap 'batterij' bestaat niet op type 'Kledingproduct'. 2 keer, voor batterijen ram eigenschappen.

In tweede blok - anderskrijgen we die foutmelding voor maat eigendom. Natuurlijk is dit slechts een voorbeeld om te laten zien hoe gediscrimineerde vakbonden en controlestroomanalyse werken in Typescript, dus we doen niets te ingewikkelds met die code.

Eenvoudige, progressieve migratie van JavaScript

Geldige JavaScript-code is tegelijkertijd geldige Typescript-code, dus je kunt je codebase stap voor stap migreren. Meestal is het gebruik van de strikte modus in Typescript een goede gewoonte, maar in dit geval,
moeten we beginnen met "strikt": vals in tsconfig.json en we moeten ook nog 2 opties instellen.

"allowJs": true, // hierdoor kunnen we .js-bestanden gebruiken en wordt het type niet gecontroleerd
"skipLibCheck": true // het type wordt niet gecontroleerd in bibliotheken die we gebruiken

Met deze opties kunnen we stap voor stap migreren van JS naar TS - bestand voor bestand, door simpelweg de extensie te veranderen van .js(x) naar .ts(x) en het toevoegen van types in de bestanden. Met deze aanpak kunnen we honderden of duizenden enge compilatiefouten voorkomen.

Samenvatting

Ik denk dat we Typescript zo vaak als mogelijkomdat het op de lange termijn echt nuttig is. Het helpt om projecten te onderhouden, vergroot de ervaring van ontwikkelaars en maakt onze codebase explicieter en betrouwbaarder.

Zoals altijd zijn er echter uitzonderingen - bijvoorbeeld voor een eenvoudige landingspagina
waar JavaScript alleen wordt gebruikt voor het wisselen van klasse of een ander eenvoudig geval, heeft Typescript geen zin.
We moeten ook niet vergeten dat we Typescript op voldoende niveau moeten leren gebruiken om er ten volle van te kunnen profiteren, en dat kan wel even duren. Ik denk dat het nog steeds een zeer rendabele investering van je tijd is.

Lees meer:

Ruby 3.0. Ruby en minder bekende privacycontrolemethoden

De hoogste kwaliteit code in je SaaS-project. Waarom zou je daar als (niet-technische) oprichter om geven?

*De titelafbeelding komt van de Know Your Meme-website.