Waarom TypeScript de beste manier is om Front-end te schrijven in 2019

En waarom je iedereen zou moeten overtuigen om het te gebruiken.

TypeScript wordt steeds populairder in de Front-end-omgeving. Reeds 80% van de ontwikkelaars geeft toe dat ze TypeScript willen gebruiken of leren in hun volgende project. Zelf ben ik er dol op sinds ik het voor het eerst gebruikte. En ik zal dit zeker in al mijn volgende projecten blijven gebruiken.

Sommige mensen maken zich zorgen dat TypeScript een onnodige afhankelijkheid van de front-end toolchain is. Is het? Volg mij om te leren dat de realiteit precies het tegenovergestelde is.

Een verhaal van een "man met dynamisch getypte talen"

Gedurende het grootste deel van 18 jaar van mijn programmeercarrière had ik nooit van statisch getypte talen gehouden. Sinds ik in 2001 met programmeren begon, werden mijn favoriete talen altijd dynamisch getypt: PHP, JS, Ruby, Elixir. Ik had hier en daar een aantal programma's in C ++ en Java gedaan, maar ik haatte die omgevingen altijd. ("Waarom moet ik het type overal doorgeven? Dat is klote. Ik kan zelf voor ze zorgen.")

Alles veranderde ongeveer 2 jaar geleden. Het was toen ik TypeScript voor het eerst gebruikte. Ik was er echter niet vanaf het begin verliefd op geworden. In de eerste paar dagen irriteerde het me eigenlijk. De situatie veranderde echter snel. Hoe meer typedefinities ik in de code invoerde, des te vaker merkte ik op dat het me bespaarde tijd te verspillen aan het handmatig debuggen van domme bugs in de console. Ik begon de typen te waarderen.

In de komende twee jaar, toen ik samenwerkte aan front-end-applicaties, of het nu Angular of React was, merkte ik dat ongeacht welk framework ik gebruikte, er altijd één ding was dat ik miste in alle .js-projecten: TypeScript .

Nu moet ik toegeven. Ik hou niet meer van dynamisch getypte talen. Ik kan er nog steeds heel effectief in werken, maar het maakt me ongelukkig als ik niet alleen typedefinities in de IDE kan opzoeken, of de compiler kan vertrouwen tijdens het prototyperen van de code. (Het enige wat ik nog steeds mis in Elixir zijn sterke types.)

Gelukkig hoeven we niet te wachten tot Ecma TC39 commitee statisch type systeem in JavaScript introduceert. We kunnen in plaats daarvan TypeScript gebruiken. Vooral in de nieuwe projecten, wanneer het gebruik ervan minimaal is.

Anti-TypeScript-argumenten

Toch durven sommigen nog steeds te beweren dat het brengen van TypeScript naar uw project:

  • verlenging van de duur van nieuwe ontwikkelaars aan boord,
  • compliceren onderhoud,
  • veel conflicten met React introduceren,
  • verhoog de ontwikkeltijd,
  • sluit het project aan op een aantal hippe technologie die over een jaar niet meer bestaat,
  • voorkomen dat goede JS-mensen worden aangetrokken,
  • het onmogelijk maken om code van niet-TS codebases mee te nemen,
  • maken het moeilijk om de app in de verre toekomst te bewerken.

Ik durf te zeggen dat ze allemaal fout zijn. TypeScript helpt u bij alle bovenstaande gevallen en ik kan u specifieke argumenten geven waarom dat zo is.

Daarom heb ik besloten dit artikel te schrijven. Misschien helpt het u, uw vrienden, collega's of uw CTO te overtuigen in deze geweldige taal.

Opmerking: ik zal in dit artikel niet uitleggen "wat TypeScript is". Ik zal me alleen concentreren op "waarom" je het zou moeten gebruiken. Als u nog steeds niet bekend bent met wat TypeScript echt is, raad ik u aan eerst enkele van de volgende links te lezen:

  • "Wat is TypeScript en waarom zou ik het gebruiken in plaats van JavaScript?" - Lodewijk's Bogaards, StackOverflow
  • TypeScript taal officiële website
  • “TypeScript - JavaScript met superkrachten” - Indrek Lasn, Medium
  • "TypeScript Deep Dive" - ​​E-boek door Basarat Ali Syed

Voordelen van TypeScript

1. Code gemakkelijker te begrijpen

Meestal moet je, als je aan een stuk code werkt, bijvoorbeeld een functiecode, het volgende begrijpen:

  1. Welke argumenten accepteert het?
  2. Welke waarde retourneert het?
  3. Welke externe gegevens heeft het nodig?
  4. Wat doet het met deze argumenten en externe gegevens om de retourwaarde te produceren?

In dynamisch getypte talen is het vaak moeilijk om de eerste drie vragen te beantwoorden. Als een functie een artikelargument ontvangt, wat is het dan precies? Is het een object met enkele artikelkenmerken? Welke exacte attributen zijn er? Is er een article.title of article.name? Kan ik altijd aannemen dat article.title bestaat? Hoe zit het met article.isPublic? Ik weet misschien dat dit kenmerk op de meeste plaatsen in de app is samengevoegd met het artikelobject, maar kan ik er zeker van zijn dat het ook altijd op deze plek aanwezig is?

Om al deze vragen te beantwoorden, moet u meestal een van de volgende dingen doen:

a) plaats een console.log (artikel), voer het script uit in uw browser (klik misschien een beetje door de gebruikersinterface) en lees het logboek;

b) zien waar de functie wordt gebruikt en van daaruit opzoeken welke gegevens in al zijn gebeurtenissen worden geplaatst;

c) vraag het uw collega die recent aan deze code heeft gewerkt (in de hoop dat ze nog in leven zijn, online, en onthoud die code);

d) ga ervan uit dat het artikel is zoals je denkt dat het is en hoop maar dat het werkt.

Klinkt dat je bekend in de oren?

Voor mij klinkt dat als een typische web dev-workflow in elke dynamisch getypte taal zoals JS, PHP, Ruby, Python, Elixir.

In statisch getypte talen zoals TypeScript, krijgt u antwoorden op alle bovenstaande vragen direct van uw IDE en compiler. U hoeft niet langer de hele codebasis te doorzoeken, uw collega's te blijven lastigvallen met vragen of het risico te lopen dat er fouten in de productie komen.

2. Code eenvoudiger en sneller te implementeren

Meestal ziet uw workflow er ongeveer zo uit als u een nieuwe functie of een nieuw onderdeel moet maken:

  1. Bootstrap de componentfunctie, verzin de constructorargumenten en schrijf de resterende code.
  2. Als het externe of geavanceerde gegevens vereist (zoals gebruikers of artikelen), raad eens hoe het eruit zal zien, bewaar het in uw eigen geheugen en gebruik het zo in de code.
  3. Plaats het onderdeel in uw app en geef er rekwisieten door.
  4. Test het, handmatig of met unit-tests. (Je moet ervoor zorgen dat het de rekwisieten ontvangt die het zou moeten hebben en dat het werkt hoe het zou moeten werken.)
  5. Als er iets niet klopt, ga dan terug naar je code, probeer uit te zoeken wat er mis mee is, repareer het en ga terug naar stap nr. 4.

In TypeScript is het vergelijkbaar, maar gemakkelijker en sneller:

  1. Bootstrap de componentfunctie, definieer het type definitie en implementeer deze.
  2. Als het externe of geavanceerde gegevens vereist, zoek dan hun interfaces op en hergebruik ze (geheel of gedeeltelijk).
  3. Plaats het onderdeel in uw app en geef er rekwisieten door.
  4. Dat is het. (Als u de typedefs correct hebt gevonden tussen de beller en de gesprekspartner, zou alles perfect moeten werken. Het enige dat u nu nog moet testen, is de feitelijke bedrijfslogica van uw component.)

Wanneer u dus code in TypeScript schrijft, is deze niet alleen leesbaarder en minder foutgevoelig, maar vooral ook eenvoudiger om over te redeneren.

3. Code gemakkelijker te refactor

Er zijn vaak heel veel dingen die je graag wilt veranderen, maar omdat ze zoveel dingen en bestanden raken, ben je gewoon te bang om ze te veranderen.

In TypeScript kunnen dergelijke dingen vaak opnieuw worden ingevoerd met slechts één klik op de opdracht 'Naam wijzigen' in uw IDE.

Naam van

In dynamisch getypte talen is zoeken en vervangen door RegExp het beste wat u kunt doen om u te helpen bij het opnieuw activeren van meerdere bestanden tegelijk.

In statisch getypte talen is zoeken en vervangen niet meer nodig. Met IDE-opdrachten zoals "Find All Occurrences" en "Rename Symbol", kunt u alle instanties in de app van de gegeven functie, klasse of eigenschap van een objectinterface zien.

Wanneer u uw buildsysteem een ​​beetje wilt verbeteren, uw componenten wilt hernoemen, uw gebruikersobject wilt wijzigen of een verouderd kenmerk wilt verwijderen, hoeft u niet meer bang te zijn om dingen te breken. TypeScript helpt u bij het vinden van alle gebruiksmogelijkheden van het gerefacteerde bit, het hernoemen en u waarschuwen met een compileerfout in het geval dat uw code een typefout heeft na de refactor.

4. Minder bugs

Gedurende vele jaren front-end webontwikkeling, heb ik gemerkt dat ik ongeveer 50% van mijn tijd aan bugfixing kon besparen, gewoon door iemand naast me te hebben die meteen tegen me schreeuwde wanneer ik een typefout deed, met behulp van een waarde die nul kan zijn, of een object naar een plaats kan leiden waar het in plaats daarvan een array zou moeten zijn.

Ik ben blij te kunnen zeggen dat ik die buddy eindelijk heb ontmoet: het heet TypeScript.

Dankzij dit is het nu veel moeilijker om ongeldige code te schrijven. Als het compileert, weet je misschien vrij zeker dat het echt werkt.

5. Minder boilerplate-tests

Als je zeker weet dat je variabelen correct worden doorgegeven aan alle gegeven plaatsen, hoef je niet alles zo veel meer te testen.

In plaats van eenvoudige boilerplate-unit / integratietests te schrijven, kunt u zich meer richten op het testen van de bedrijfslogica van uw app, in plaats van te testen of uw functieargumenten correct tussen elkaar worden doorgegeven.

Minder tests betekent kortere tijd om nieuwe functies te ontwikkelen en een kleinere codebasis, die op zijn beurt minder gecompliceerd, minder foutgevoelig en gemakkelijker te onderhouden is.

6. Code gemakkelijker samen te voegen

Nieuwe junior ontwikkelaar in uw team heeft zojuist een PR uitgegeven met nieuwe code. Op het eerste gezicht ziet het er allemaal goed uit: de code ziet er goed uit, de unit-tests zijn er, alles gaat groen.

Weet je op dit moment zeker dat het werkt? Wat als het geen goede unit-tests heeft? (Yeh. Laten we de reality-mensen ontmoeten, velen van ons schrijven nog steeds niet voldoende aantal.) Zullen jullie de PR-maker gewoon vertrouwen? Of ga je je kostbare 5 minuten concentreren om de code daadwerkelijk zelf uit te voeren en te testen?

Als u TypeScript in uw toolchain hebt, geeft dit u nog een betrouwbaarheidscontrole: de typedef compilatiecontrole.

Als de code er goed uitziet, zijn de unit-tests er en het hele ding is samengesteld, nu kun je er vrij zeker van zijn dat het hele ding werkt.

TypeScript maakt het eenvoudiger om andere ontwikkelaars te vertrouwen. Het kan het tempo verbeteren waarmee u PR's beoordeelt en samenvoegt.

(Hetzelfde geldt voor de andere kant: dankzij typedefinities is het voor nieuwe ontwikkelaars gemakkelijker om te zien wat de codedelen van andere mensen echt doen, zonder diep in te duiken of het zelf uit te voeren.)

7. Helpt de ontwikkelaar bij het hebben van de juiste workflow

Wanneer u code schrijft in statisch getypte talen, moet u eerst nadenken over de soorten gegevens die u ontvangt en vervolgens over het type gegevens dat u wilt produceren. Meestal pas daarna ga je zitten voor de daadwerkelijke implementatie.

Veel mensen zullen hun leven wedden dat dit de juiste coderingsworkflow is.

Wanneer u bijvoorbeeld een algoritme ontwikkelt, moet u eerst nadenken over de theoretische formule en deze vervolgens implementeren.

Of, wanneer u TDD doet, moet u eerst bedenken hoe uw code in werkelijkheid zal werken (welke gegevens zal het ontvangen en welke gegevens zal het produceren), het als tests schrijven en vervolgens de eigenlijke code implementeren.

Hetzelfde geldt voor TypeScript. Het moedigt u aan om na te denken over de interface van uw code voordat u gaat zitten voor de interne implementatie ervan.

TypeScript betreft

1. "Het zal onze werving schaden"

Zal het?

Regelmatige JS-enquêtes laten duidelijk zien dat meer en meer mensen allebei in TS programmeren of het willen proberen.

https://2018.stateofjs.com/javascript-flavors/typescript/

De bovenstaande enquête bewijst het: vanaf 2018 zou 80% van de front-end-ontwikkelaars graag in TypeScript willen werken.

Als u TypeScript in uw stapel heeft, is dit waarschijnlijk niet schadelijk voor uw werving. Het zou eigenlijk het tegenovergestelde kunnen doen. Als een ontwikkelaar ziet dat u de beste tools op de markt gebruikt, is hij meer bereid om in uw bedrijf te werken. Moderne tools brengen moderne ontwikkelaars.

2. "Aan boord gaan kost meer tijd"

De waarheid is dat, hoewel TypeScript een superset van JavaScript is, het iets nieuws is dat iedereen moet leren. Een ontwikkelaar die niet bekend is met TS zal er minstens een uur of twee over moeten lezen voordat hij aan een dergelijk project begint samen te werken.

Integendeel, als je een al gebouwd project in TypeScript hebt, is het voor nieuwe ontwikkelaars super eenvoudig om erin te passen. TS Syntax is intuïtief en zeer gemakkelijk te begrijpen (wat waarschijnlijk de reden is waarom het zo populair is geworden). Generieke functie-interfaces, typebeschermingen, voorwaardelijke typen? U hoeft deze in 99% van uw dagelijkse werkzaamheden nooit aan te raken of te begrijpen. De resterende 1% is meestal iets dat alleen in het begin moet worden gedaan, wat kan worden voorbereid door een reeds vloeiende TS-programmeur.

Dankzij TS-voordelen (die ik eerder al heb genoemd), zal het bovendien gemakkelijker zijn voor een nieuwe ontwikkelaar om dingen in uw bestaande codebase te gaan doen. Als hij slechts een klein ding hoeft te veranderen of iets nieuws moet implementeren, hoeft hij niet meer door de hele codebase te bladeren om te begrijpen welke gegevens worden doorgegeven en waar. Hij kan het direct in zijn IDE lezen en spelen met de gegevens. De TS-compiler geeft hem onmiddellijk feedback over de variabelen die hij gebruikt en begeleidt hem wanneer hij een fout maakt.

3. "React / Redux en TS passen niet bij elkaar"

Knopcomponent in React en TypeScript

False. TS heeft sinds lange tijd TSX-ondersteuning. Ook kun je dankzij eenvoudige generieke types zoals React.Component van PropTypes afkomen en in plaats daarvan het echte type systeem gebruiken.

Het is waar dat het ongeveer een jaar geleden nodig was om een ​​beetje boilerplate-code te schrijven om TypeScript te laten werken met Redux-actiemakers. Maar omdat TS 2.8 in februari 2018 is uitgebracht, is dit niet langer het geval. U kunt zowel getypte als eenvoudige React / Redux-code in TypeScript hebben. Ter info, React Contexts of Hooks werken perfect met TypeScript.

4. "Het zal onmogelijk zijn om JS-code opnieuw te gebruiken in een TS-app"

Nogmaals, vals. Elke JS-code is een geldige TS-code.

Het is waar dat als je TS in de strikte modus (noImplicitAny) gebruikt, je hier en daar wat typen moet toevoegen om de JS-code te laten werken. Maar dat is het! Er is zelfs een IDE-plug-in die uw JS React-componenten automatisch rechtstreeks naar TS kan converteren.

Wanneer je een rare oude verkoper js lib naar je TS-project moet kopiëren: doe het gewoon. Als er geen TS-typen voor zijn (wat nu steeds minder vaak gebeurt), voeg ze dan zelf toe of gebruik er gewoon een wanneer u naar de leverancier verwijst. Het is niet alsof je ineens je typeveiligheid in je hele app verliest. Je verliest het alleen in de laag die de ongetypte verkoper raakt. Maar dat betekent niet dat je je laag tenminste niet gemakkelijk kunt typen. En voor de verkoper kunt u de typedefs er later altijd voor toevoegen, wanneer u besluit dat ze ook nuttig zouden zijn.

5. "Door TypeScript te kiezen, kunnen we uiteindelijk worden vergrendeld met een oudere tool die niemand in de toekomst zal ondersteunen"

TypeScript wordt momenteel gebruikt door Microsoft, Asana, Lyft, Slack, alle Angular 2+ ontwikkelaars, meerdere React & Vue.js ontwikkelaars en duizenden andere bedrijven. Vele anderen doen er elke dag mee mee. TypeScript is de meest populaire superset van JS op dit moment en gaat niet snel ten onder.

Wat is de kans dat zo'n taal wordt verlaten?

Ik zou zeggen bijna nul. Het enige scenario waarin TS zou kunnen sterven, is als JS zelf typen in hun taal zou brengen. Maar dit zal zeker niet snel gebeuren. Tenminste niet in de komende ~ 5-10 jaar. In het zeldzame geval dat zich daadwerkelijk zou voordoen, kunt u er zeker van zijn dat er ook tools zijn waarmee u gemakkelijk van TS naar getypte JS kunt migreren.

~ 5-10 jaar vanaf nu is misschien een tijd waarin niemand React, Vue of Angular meer kent. Maar je ziet geen probleem om je aan die kaders te houden, denk ik? ;)

6. "Hoe zit het met Flow?"

TypeScript geeft je hetzelfde als Flow, en meer. Het is ook veel populairder.

TS vs Flow npm downloads in de afgelopen 2 jaar (npmtrends.com)

Alleen dit zou al genoeg moeten zijn om Flow helemaal niet te overwegen. Als het hetzelfde is, maar met minder functionaliteit en veel kleinere community-ondersteuning, waarom zou je het dan overwegen?

Achteraf gezien was Flow ongeveer ~ 3 jaar geleden net zo populair als TS, toen beiden nieuwe spelers op de markt waren. Een van hen werd gepusht door Microsoft en de Angular-gemeenschap, terwijl de andere de voorkeur kreeg van Facebook en sommige van de React-gemeenschap.

TypeScript heeft uiteindelijk gewonnen. Tegenwoordig schakelen steeds meer ontwikkelaars van alle front-end frameworks over naar TypeScript.

Er zijn ook een paar andere getypte JS-alternatieven die er zijn (zoals PureScript of Elm), maar laten we ze hier niet beschouwen. Ik wil het hebben over iets dat brede gemeenschapsondersteuning heeft en meerdere bedrijven die het al in productie gebruiken, niet alleen een paar hobbyisten. (Sorry, mensen.)

TypeScript nadelen

1. Vereist een compilatiestap

Sommige van mijn back-end Node.js-vrienden vertelden me dat het introduceren van TS voor hen gewoon niet de moeite waard is, omdat het veel gedoe zou opleveren met de noodzaak om alle .ts-bestanden vooraf te compileren voordat ze op Node worden uitgevoerd.

Hoewel het iets is dat je zeker aankan met een goede build- en ontwikkelingsconfiguratie, kan ik het niet oneens zijn dat het een beetje overhead toevoegt aan je Node.js-applicatie.

Ik ben het hier echter niet mee eens in de front-end omgeving. Iedereen stelt tegenwoordig JS in de front-end samen. Heeft u ondersteuning voor oudere browsers nodig? ES7-functies? CSS-in-JS? Voor al deze dingen gebruik je waarschijnlijk al babel. TypeScript kan worden gecompileerd met Babel, net als elke andere syntaxis van JS (inclusief ES7 of JSX).

Door TypeScript naar uw front-end project te brengen, heeft de build-setup bijna geen overhead. (Het kan alleen overhead met zich meebrengen als je je JS helemaal niet compileert, maar dat gebeurt heel zelden in de front-end.)

2. Een beetje moeilijk in te stellen

Daar ben ik het mee eens. Wat is bijvoorbeeld het verschil tussen een Next.js-app en een Next.js-app in TypeScript? In het tweede geval moet u uw Node.js-server, webpack en jest-testloper laten werken met TypeScript. Ook wanneer u een bibliotheek zoals React, Redux, Styled-Components toevoegt, moet u er ook typedefs voor toevoegen, zoals npm i @ types / styled-components (tenzij in de lib TS-typedefs-bestand is opgenomen).

De vraag die je zelf moet beantwoorden, hoe vaak doe je zoiets? Is het zoveel moeite om waardig te zijn om afstand te doen van alle voordelen van TypeScript?

Samenvatting

Zeg ik dat we allemaal plotseling moeten overschakelen op TypeScript? Nee. Het is bijvoorbeeld heel wat werk om er in een bestaand project naar over te schakelen en daar moet goed over worden nagedacht.

Als u echter een nieuwe front-end-applicatie maakt, die na verloop van tijd moet worden onderhouden, is de zaak duidelijk. Ga met TypeScript. Eerlijk gezegd hoor ik graag wat de redenen zijn om TS niet te gebruiken in een van je volgende front-endprojecten.

Ik wil alleen dit zeggen: door TypeScript te gebruiken krijg je heel veel krachtige voordelen, voor de kosten van weinig extra inspanningen in het begin.

Laten we TypeScript-mensen doen

Links

Over TypeScript

  • "Wat is TypeScript en waarom zou ik het gebruiken in plaats van JavaScript?" - Lodewijk's Bogaards, StackOverflow

Case-Studios "Overstappen op TS"

  • "TypeScript at Lyft" - Mohsen Azimi, gemiddeld
  • "TypeScript at Slack" - Felix Rieseberg, Medium
  • “Hoe we een 200K + LOC-project naar TypeScript migreerden en het overleefden om het verhaal te vertellen” - Kleo Petrov, Hashnode
  • “600K-lijnen in 72 uur naar TypeScript converteren” - Paul Draper & Ryan Stringham, LucidChard TechBlog

Anderen beoordelingen van TS

  • "7 slechte excuses voor het niet gebruiken van TypeScript" - Dmitry Pashkevich, Medium
  • “Waarom TypeScript gebruiken, goede en slechte redenen” - Charly Poly, Medium
  • "JavaScript versus TypeScript versus ReasonML" - Dr. Axel Rauschmayer, 2ality
  • "Typoscript - waarom zou men het gebruiken?" - Majid, Medium
  • "Waarom TypeScript populairder wordt" - Mary Branscombe, de nieuwe stapel