Hvorfor TypeScript er den beste måten å skrive Front-end i 2019

Og hvorfor du bør overbevise alle om å bruke den.

TypeScript blir mer og mer populært i front-miljøet. Allerede 80% av utviklerne innrømmer at de vil bruke eller lære TypeScript i sitt neste prosjekt. Selv har jeg elsket den siden jeg brukte den for første gang. Og jeg vil fortsette å bruke dette i alle de neste prosjektene mine helt sikkert.

Noen mennesker reiser bekymring for at TypeScript er en unødvendig avhengighet av frontkjeden. Er det? Følg meg for å lære at virkeligheten er helt motsatt.

En historie om en "dynamisk typisk språk fyr"

I det meste av 18 år av min programmeringskarriere hadde jeg aldri likt statisk maskinskrevne språk. Siden jeg startet med programmering i 2001, ble språkene mine alltid valgt dynamisk: PHP, JS, Ruby, Elixir. Jeg hadde gjort noen programmer i C ++ og Java her og der, men jeg hatet alltid disse miljøene. ("Hvorfor trenger jeg å passere typen overalt? Det suger. Jeg kan ta vare på dem selv.")

Alt forandret seg for rundt 2 år siden. Det var da jeg brukte TypeScript for første gang. Jeg hadde imidlertid ikke blitt forelsket i det fra begynnelsen. De første dagene irriterte det meg faktisk. Situasjonen endret seg raskt. Jo flere typedefinisjoner jeg la inn koden, jo oftere la jeg merke til at det sparte meg for å kaste bort tid på manuelt å feilsøke dumme feil i konsollen. Jeg begynte å sette pris på typene.

I løpet av de neste to årene, hver gang jeg samarbeidet om front-end applikasjoner, enten det var Angular eller React, la jeg merke til at uansett hvilken ramme jeg brukte, så var det alltid denne tingen jeg savnet i alle .js-prosjekter: TypeScript .

Nå må jeg innrømme. Jeg liker ikke dynamisk maskinskrevne språk lenger. Jeg kan fortsatt jobbe veldig effektivt i dem, men det gjør meg ulykkelig når jeg ikke bare kan slå opp type definisjoner i IDE, eller stole på kompilatoren mens jeg prototyper koden. (Det eneste jeg fremdeles savner i Elixir er sterke typer.)

Heldigvis trenger vi ikke å vente til Ecma TC39-komiteen introduserer statisk type system i JavaScript. Vi kan bruke TypeScript i stedet. Spesielt i de nye prosjektene, når bryet med å bruke det er minimalt.

Anti-TypeScript-argumenter

Likevel tør noen fortsatt argumentere for at å bringe TypeScript til prosjektet ditt:

  • øke varigheten av ombordgående nye utviklere,
  • komplisere vedlikehold,
  • introdusere mange konflikter med React,
  • øke utviklingstiden,
  • låser inn prosjektet til noen hipsteryteknologier som ikke vil eksistere om et år fra nå,
  • hindre rekruttering av gode JS-folk,
  • gjør det umulig å ta med kode fra ikke-TS-kodebaser,
  • gjøre det vanskelig å redigere appen i en fjern fremtid.

Jeg tør påstå at de tar feil. TypeScript vil hjelpe deg med alle de ovennevnte sakene, og jeg kan gi deg spesifikke argumenter hvorfor er det slik.

Derfor bestemte jeg meg for å skrive denne artikkelen. Kanskje vil det hjelpe å overbevise deg, dine venner, arbeidskamerater eller CTO, til dette fantastiske språket.

Merk: Jeg vil ikke forklare “hva TypeScript er” i denne artikkelen. Jeg fokuserer bare på "hvorfor" du skal bruke den. Hvis du fremdeles ikke er kjent med hva TypeScript egentlig er, foreslår jeg at du leser noen av følgende lenker først:

  • "Hva er TypeScript, og hvorfor skulle jeg bruke det i stedet for JavaScript?" - Lodewijk's Bogaards, StackOverflow
  • TypeScript-offisielle nettsted
  • “TypeScript - JavaScript med superkrefter” - Indrek Lasn, Medium
  • “TypeScript Deep Dive” - E-bok av Basarat Ali Syed

TypeScript fordeler

1. Kode enklere å forstå

Vanligvis når du jobber med et stykke kode, for eksempel en funksjonskode, for å forstå det fullstendig, må du forstå:

  1. Hvilke argumenter godtar den?
  2. Hvilken verdi gir den tilbake?
  3. Hvilke eksterne data krever det?
  4. Hva gjør det med disse argumentene og eksterne data for å produsere returverdien?

I dynamisk maskinskrevne språk er det ofte vanskelig å svare på de tre første spørsmålene. Hvis en funksjon mottar artikkelargumentasjon, hva er det da? Er det et objekt med noen artikkelattributter? Hvilke eksakte attributter er det? Er det en Article.title eller Article.name? Kan jeg alltid anta at artikkel.tittelen eksisterer? Hva med artikkelen.isPublisert? Jeg vet kanskje at denne attributtet er slått sammen til artikkelobjektet de fleste stedene i appen, men kan jeg være sikker på at den alltid er til stede også på dette stedet?

For å svare på alle disse spørsmålene, trenger du vanligvis å gjøre ett av følgende:

a) legg en konsoll.logg (artikkel), kjør skriptet i nettleseren din, (kanskje klikk litt gjennom brukergrensesnittet) og les loggen;

b) se hvor funksjonen brukes og derfra spore hvilke data som blir lagt inn i alle dens forekomster;

c) spør kollegaen som nylig hadde jobbet med denne koden (mens du håpet at de fremdeles er i live, online og husker den koden);

d) antar at artikkelen er som du tror den er, og bare håper den fungerer.

Høres det kjent ut for deg?

For meg høres det ut som en typisk nettverksarbeidsflyt på et hvilket som helst dynamisk typisk språk som JS, PHP, Ruby, Python, Elixir.

På statisk maskinskrevne språk som TypeScript får du svar på alle spørsmålene ovenfor umiddelbart fra IDE og kompilatoren. Du trenger ikke lenger å se gjennom hele kodebasen, fortsette å trenge arbeidskameratene dine med spørsmål eller risikere å få feil på produksjonen.

2. Kode enklere og raskere å implementere

Når du må lage en ny funksjon eller en ny komponent, ser arbeidsflyt antagelig ut noe slik:

  1. Bootstrap komponentfunksjonen, utgjør konstruktørargumentene, skriv den gjenværende koden.
  2. Hvis det krever eksterne eller sofistikerte data (som bruker eller artikler), gjett hvordan vil det se ut, ha det i ditt eget minne og bruk det sånn i koden.
  3. Sett komponenten i appen din, og send rekvisitter til den.
  4. Test det, enten manuelt eller med enhetstester. (Du må sørge for at den mottar rekvisittene den skal ha, og at den fungerer slik den skal fungere.)
  5. Hvis noe ikke stemmer, kan du gå tilbake til koden din, prøv å finne ut hva som er galt med den, fikse den og gå tilbake til trinn nr. 4.

I TypeScript er den lik, men enklere og raskere:

  1. Bootstrap komponentfunksjonen, definer dens definisjon av type og implementer den.
  2. Hvis det krever eksterne eller sofistikerte data, må du slå opp grensesnittene og bruke dem (helt eller delvis).
  3. Sett komponenten i appen din, og send rekvisitter til den.
  4. Det er det. (Hvis du matchet typefolkene riktig mellom den som ringte og callee, skal alt fungere feilfritt. Det eneste du må teste nå er den faktiske forretningslogikken for komponenten din.)

Når du skriver kode i TypeScript, er det ikke bare mer leselig og mindre feilutsatt, men hovedsakelig bare lettere å resonnere seg om.

3. Kode lettere å refaktorere

Det er ofte ganske mange ting du ønsker å refactor, men fordi de berører så mange ting og filer, er du bare for redd for å endre dem.

I TypeScript kan slike ting ofte refactureres med bare ett klikk på "Rename Symbol" -kommandoen i IDE-en.

Gi nytt navn til

På dynamisk maskinskrevne språk er det beste du kan hjelpe deg med å gjenskape flere filer på samme tid, Søk og erstatt med RegExp.

På statisk skrevne språk er det ikke nødvendig med Søk og erstatt lenger. Med IDE-kommandoer som "Finn alle forekomster" og "Gi nytt navn symbol", kan du se alle forekomster i appen til den gitte funksjonen, klassen eller egenskapen til et objektgrensesnitt.

Hver gang du vil forbedre build-systemet ditt, gi nytt navn til komponentene dine, endre brukerobjektet ditt eller fjerne et utdatert attributt, trenger du ikke være redd for å ødelegge ting lenger. TypeScript vil hjelpe deg med å finne alle bruksområdene til den refactored biten, endre navn på den og varsle deg med en kompilasjonsfeil i tilfelle koden din har en hvilken som helst type feilpasning etter refactoren.

4. Mindre feil

Gjennom mange år med front-end webutvikling har jeg lagt merke til at jeg kunne spare rundt ~ 50% av tiden min med feilrettelse bare ved å ha noen som satt ved siden av meg som umiddelbart ville kjefte på meg når jeg gjorde en skrivefeil, ved å bruke en verdi som kan være null, eller sende et objekt til et sted der det skal være en matrise i stedet.

Jeg er glad for å si at jeg endelig traff den kompisen: den heter TypeScript.

Takket være det er det nå vanskeligere å skrive ugyldig kode. Hvis det samles, er du kanskje ganske sikker på at den faktisk fungerer.

5. Mindre kjeleplattester

Når du er sikker på at variablene dine blir gitt riktig på alle gitte steder, trenger du ikke å teste alt det så mye lenger.

I stedet for å skrive enkle kjeleplateenheter / integrasjonstester, kan du fokusere mer på å teste forretningslogikk for appen din, i stedet for å teste om funksjonsargumentene dine sendes riktig mellom hverandre.

Mindre tester betyr kortere tid for å utvikle nye funksjoner, og en mindre kodebase, som igjen er mindre komplisert, mindre feilutsatt og enklere å vedlikeholde.

6. Kode enklere å slå sammen

Ny juniorutvikler i teamet ditt har nettopp gitt ut en PR som introduserer ny kode. Ved første øyekast ser det bra ut: koden ser bra ut, enhetstestene er der, alt passerer grønt.

Kan du være sikker på at det fungerer i det øyeblikket? Hva om den ikke har riktige enhetstester? (Yeh. La oss møte virkelighetens folk, mange av oss skriver fremdeles ikke nok av dem.) Vil du bare stole på PR-skaperen? Eller vil du fokusere dine dyrebare 5 minutter på å faktisk kjøre koden på egen hånd og teste den?

Hvis du har TypeScript i verktøykjeden din, gir den deg en sikkerhetskontroll: typedef-kompileringskontrollen.

Hvis koden ser bra ut, er enhetstestene der, og det hele samles, nå kan du være ganske sikker på at det hele fungerer.

TypeScript gjør det lettere å stole på andre utviklere. Det kan forbedre tempoet du vurderer og fletter PR-er.

(Det samme går den andre veien: takket være typedefinisjoner, for nye utviklere er det lettere å se hva andres porsjoner med kode virkelig gjør, uten å behøve å dykke dypt inn i den eller kjøre den av seg selv.)

7. Hjelper utvikleren med å ha riktig arbeidsflyt

Når du skriver kode på statisk skrevne språk, må du først tenke på datatypene du vil motta, og deretter om datatypen du vil produsere. Vanligvis bare etter det setter du deg ned til selve implementeringen.

Mange vil satse livet sitt på at dette er riktig koding arbeidsflyt.

Når du for eksempel utvikler en algoritme, bør du først tenke på dens teoretiske formel og deretter implementere den.

Eller, når du gjør TDD, må du først tenke hvordan koden din vil virke i virkeligheten (hvilke data vil den motta og hvilke data den vil produsere), skrive den som tester og deretter implementere den faktiske koden.

Det samme gjelder TypeScript. Det oppfordrer deg til å tenke på grensesnittet til koden din før du setter deg ned til den interne implementeringen.

TypeScript bekymringer

1. "Det vil skade rekrutteringen vår"

Vil det?

Vanlige JS-undersøkelser viser tydelig at flere og flere mennesker programmerer i TS eller er villige til å prøve det.

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

Ovennevnte undersøkelse beviser det: fra og med 2018 vil 80% av front-end-utviklerne gjerne jobbe i TypeScript.

Å ha TypeScript i bunken din vil sannsynligvis ikke skade rekrutteringen din. Det kan faktisk gjøre det motsatte. Hvis en utvikler ser at du bruker de beste verktøyene som er tilgjengelige på markedet, vil han være mer villig til å jobbe i bedriften din. Moderne verktøy bringer moderne utviklere.

2. "Innstigning tar mer tid"

Sannheten er at selv om TypeScript er et supersett av JavaScript, er det noe nytt som alle må lære. En utvikler som ikke er kjent med TS, må lese om det i minst en time eller to, før han begynner å samarbeide om et slikt prosjekt.

Tvert imot, hvis du har et allerede bygget prosjekt i TypeScript, vil det være superenkelt for nye utviklere å få plass i. TS Syntax er intuitivt og veldig lett å forstå (som sannsynligvis er grunnen til at det har blitt så populært). Generiske funksjonsgrensesnitt, typevakter, betingede typer? Du trenger aldri å berøre eller forstå dem i 99% av det daglige arbeidet ditt. De resterende 1% er vanligvis noe som bare må gjøres i begynnelsen, som kan utarbeides av en allerede flytende TS-programmerer.

Takket være TS-fordeler (som jeg nevnte tidligere på), vil det dessuten være lettere for en ny utvikler å begynne å gjøre ting i din eksisterende kodebase. Hvis han bare trenger å endre en liten ting eller implementere noe nytt, trenger han ikke å bla gjennom hele kodebasen lenger for å forstå hvilke data som sendes og hvor. Han kan lese den øyeblikkelig på IDE-en og leke med dataene. TS-kompilatoren vil gi ham øyeblikkelig tilbakemelding om variablene han bruker og vil veilede ham når han gjør noe feil.

3. "React / Redux og TS passer ikke hverandre"

Knappkomponent i React og TypeScript

Falsk. TS har hatt TSX-støtte siden lenge. Også takket være enkle generiske typer som React.Component , kan du bli kvitt PropTypes og bruke ekte type system i stedet.

Det er sant at for omtrent et år siden ble det påkrevd å skrive litt kjeleplate-kode for å få TypeScript til å fungere med Redux-actionskapere. Men siden TS 2.8 har blitt utgitt i februar 2018, er dette ikke lenger en sak. Du kan ha både skrevet og enkel React / Redux-kode i TypeScript. FYI, React Contexts eller Hooks fungerer feilfritt med TypeScript.

4. "Det vil være umulig å gjenbruke JS-kode i en TS-app"

Igjen, usant. Enhver JS-kode er en gyldig TS-kode.

Det er sant at hvis du bruker TS i streng modus (noImplicitAny), må du legge til noen typer her og der for å få JS-koden til å fungere. Men det er det! Det er til og med en IDE-plugin som automatisk kan konvertere JS React-komponenter direkte til TS.

Når du trenger å kopiere noen rare gamle leverandører js lib til TS-prosjektet ditt: bare gjør det. Hvis det ikke er noen TS-typ for det (som skjer mindre og mindre ofte nå), kan du legge dem til selv eller bare bruke noen når du henviser til leverandøren. Det er ikke som om du plutselig mister tryggheten i hele appen din. Du mister det bare i laget som berører den ikke-skrevne leverandøren. Men det forhindrer ikke i å minst skrive laget ditt i det minste. Og for leverandøren, kan du alltid legge til typefefs for det senere, når du bestemmer deg for at de også vil være til hjelp.

5. "Ved å velge TypeScript kan vi ende opp med å være låst med et eller annet arvverktøy som ingen vil støtte i fremtiden."

TypeScript brukes for øyeblikket av Microsoft, Asana, Lyft, Slack, alle Angular 2+-utviklere, flere React & Vue.js-utviklere og tusenvis av andre selskaper. Mange andre blir med dem hver dag. TypeScript er det mest populære supersettet til JS for øyeblikket og går ikke av når som helst.

Hva er sjansen for at et slikt språk blir forlatt?

Jeg vil si nær null. Det eneste scenariet der TS kan dø, er om JS ville bringe inn typer til språket på egen hånd. Men dette vil ikke skje når som helst snart. I hvert fall ikke de neste ~ 5–10 årene. I sjeldne tilfeller som faktisk ville skje, kan du være sikker på at det også vil være verktøy som lar deg enkelt migrere fra TS til typet JS.

~ 5–10 år fra nå kan være en tid der ingen kjenner React, Vue eller Angular lenger. Men du ser ikke noe problem med å holde deg til de rammene jeg antar? ;)

6. "Hva med flyt?"

TypeScript gir deg det samme som Flow gjør, og mer. Det er også langt mer populært.

TS vs Flow npm nedlastinger de siste 2 årene (npmtrends.com)

Akkurat dette skal allerede være nok til at du ikke vurderer Flow i det hele tatt. Hvis det er det samme, men med mindre funksjonalitet og mye mindre samfunnsstøtte, hvorfor ville du vurdere det?

I ettertid pleide Flow å være så populær som TS for omtrent 3 år siden, da begge var ferske aktører på markedet. En av dem ble presset av Microsoft og Angular samfunnet, mens den andre ble foretrukket av Facebook og noen av React-samfunnet.

TypeScript vant til slutt. Nå for tiden bytter flere og flere utviklere fra alle frontrammer til TypeScript.

Det er også noen få andre JS-alternativer som er skrevet (som PureScript eller Elm), men la oss ikke vurdere dem her. Jeg vil snakke om noe som har bred samfunnsstøtte og flere selskaper som allerede bruker det i produksjonen, ikke bare noen få amatører. (Beklager, folkens.)

TypeScript kons

1. Krever et kompileringstrinn

Noen av mine back-end Node.js-venner fortalte meg at det bare ikke er verdt å introdusere TS for dem, fordi det ville gi mye bry med behovet for å forhåndskompilere alle .ts-filene før du kjører dem på Node.

Selv om det er noe du med sikkerhet kan takle et godt bygg- og utviklingsoppsett, kan jeg ikke være uenig i at det tilfører Node.js-applikasjonen litt overhead.

Jeg kan ikke være enig i dette i front-end-miljøet. Alle sammen JS i front-end nå for tiden. Trenger du eldre nettleserstøtte? ES7 funksjoner? CSS-in-JS? For alle disse bruker du sannsynligvis allerede babel. TypeScript kan kompileres med Babel, akkurat som alle andre syntaks for JS (inkludert ES7 eller JSX).

Å bringe TypeScript til front-end-prosjektet ditt gir nesten ingen overhead til byggeoppsettet. (Det kan føre til overhead bare i tilfeller der du ikke sammenstiller JS-en i det hele tatt, men det skjer veldig i sjeldne tilfeller.)

2. Litt vanskelig å sette opp

Det kan jeg være enig i. Hva er for eksempel forskjellen mellom en Next.js-app og en Next.js-app i TypeScript? I det andre tilfellet må du gjøre at Node.js-serveren, webpack og jest-testløperen skal fungere med TypeScript. Når du legger til et bibliotek som React, Redux, Styled-Components, må du også legge til typedefs for det, for eksempel npm i @ types / styled-komponenter (med mindre lib har TS typedefs-fil inkludert i den).

Spørsmålet du selv må svare på, hvor ofte gjør du noe slikt? Er det så mye arbeid å være verdig å trekke seg fra alle TypeScript-fordelene?

Sammendrag

Sier jeg at alle av oss plutselig bør bytte til TypeScript? Nei. For eksempel er det definitivt mye arbeid å bytte til det i et eksisterende prosjekt, og det bør tenkes grundig gjennom før du gjør det.

Imidlertid, hvis du oppretter en ny front-end applikasjon, som må opprettholdes over tid, er saken klar. Gå med TypeScript. Ærlig talt, jeg er opptatt av å høre hva som er grunnene til å bruke TS i noen av dine neste front-end-prosjekter.

Jeg vil bare si dette: ved å bruke TypeScript får du masse kraftige fordeler, for kostnadene for lite ekstra krefter i begynnelsen.

La oss gjøre TypeScript-folk

lenker

Om TypeScript

  • "Hva er TypeScript, og hvorfor skulle jeg bruke det i stedet for JavaScript?" - Lodewijk's Bogaards, StackOverflow

“Bytt til TS” Case Studios

  • “TypeScript at Lyft” - Mohsen Azimi, Medium
  • “TypeScript at Slack” - Felix Rieseberg, Medium
  • “Hvordan vi migrerte et 200K + LOC-prosjekt til TypeScript og overlevde for å fortelle historien” - Kleo Petrov, Hashnode
  • “Konvertere 600K linjer til TypeScript på 72 timer” - Paul Draper & Ryan Stringham, LucidChard TechBlog

Andre anmeldelser av TS

  • “7 dårlige unnskyldninger for ikke å bruke TypeScript” - Dmitry Pashkevich, Medium
  • “Hvorfor bruke TypeScript, gode og dårlige grunner” - Charly Poly, Medium
  • “JavaScript vs. TypeScript vs. ReasonML” - Dr. Axel Rauschmayer, 2ality
  • “Typeskrift - Hvorfor skal man bruke det?” - Majid, Medium
  • “Hvorfor TypeScript vokser mer populært” - Mary Branscombe, The New Stack