Derfor bør du (sannsynligvis) bruke Typescript

Typescripts nåværende posisjon kom ikke ut av ingenting, ettersom teknologien virkelig kan forbedre utvikleropplevelsen vår. Mer eksplisitt koding øker kontrollen og forutsigbarheten av kode.
I denne artikkelen skal jeg prøve å overbevise deg om å bruke Typescript.

*- Datakilde: Tilstanden til JS 2020 og Stack Overflow Developer Survey 2020.

Finn ut om feil tidligere

Når du utvikler en applikasjon i JavaScriptkan det hende at flyten din
se slik ut:

1. Gjør en forandring,
2. Gå til appen og sjekk ut den endrede delen / Kjør (relaterte) tester.
3. Finn ut om alt er i orden.

Med Typescript kan du faktisk gjøre endringen, og hvis det er noen type feil i koden din, vil du vite det umiddelbart takket være kompilatorens feilmelding eller IDE-tilbakemelding i sanntid.
Typescript-kompilatoren vil selvfølgelig ikke løse alle problemer og vil ikke advare om alle feil, men hjelpen kan være uvurderlig.

Bedre syntaksfullføring i IDE-er

Det er veldig enkelt. Hvis du bruker gode IDE-er, som WebStorm eller VSCode, vil du få
bedre syntaksfullføring med Typescript. Det høres kanskje ikke ut som en stor forbedring av utvikleropplevelsen, men hver eneste forbedring er viktig, ettersom den kan spare oss for tid og, igjen, forhindre skrivefeil eller feil. I tillegg kan vi definere typen eller grensesnittet vårt én gang, og siden vi ikke alltid trenger å huske strukturen, kan vi fokusere på å skrive forretningslogikken.

Mindre smertefull refaktorisering

Tenk deg at du av en eller annen grunn må refaktorere, for eksempel at du har sluttet deg til en prosjekt og du får i oppgave å legge til en ny funksjon, men denne funksjonen er på en eller annen måte knyttet til eldre kode.
Typescript kan gjøre det enklere og mindre smertefullt, for når du gjør en endring og det er et annet sted der du må gjøre en ny endring, vil kompilatoren advare deg om det.

Det kan for eksempel være en endret funksjonssignatur, eller kanskje etter endringen, en
funksjon vil returnere noe helt annet, så også den returnerte typen vil være forskjellig.

Bli tryggere på kodebasen

JavaScript er svakt og dynamisk typet, så når du initialiserer en variabel med verdien let query = '' senere i koden kan utvikleren gjøre noe irrasjonelt ved en feiltakelse, for eksempel query = true, og det vil være gyldig JS-kode.

I en velskrevet kode skal det ikke skje at en boolsk verdi tilordnes en variabel som tidligere var en streng. Så vanligvis skyldes denne tilordningen med typeendring en feil.

Når vi bruker Typescript, kan vi ikke endre typen på variabelen, så hvis vi gjør let query = '' variabel, vil den være streng typen, og vi vil ikke kunne endre typen ved en feiltakelse.

Hvis vi ønsker å la en variabel være mer enn én type, gjør vi det alltid eksplisitt ved å bruke union type, for eksempel streng | tall.

Derfor gjør Typescript koden vår mer forutsigbar og eksplisitt.
Typescript tar også hensyn til eksplikativitet i kontrollstrømanalysen, og hvis det er en mulighet for at noe kan gå galt, vil den advare deg.

Her i eksempel i første hvis blokken får vi en feilmelding:

TS2339: Egenskapen 'battery' finnes ikke på typen 'ClothingProduct' 2 ganger, for batteri, og ram egenskaper.

I den andre blokken - ellersvil vi få den feilen for størrelse eiendom. Det er selvfølgelig bare et eksempel for å vise deg hvordan diskriminerte fagforeninger og kontrollflytanalyse fungerer i Typescript, så vi gjør ikke noe altfor komplisert med den koden.

Enkel, gradvis migrering fra JavaScript

Gyldig JavaScript-kode er samtidig gyldig Typescript-kode, slik at du kan migrere kodebasen din trinn for trinn. Vanligvis er det god praksis å bruke strict-modus i Typescript, men i dette tilfellet,
må vi begynne med "strict": false i tsconfig.json og vi bør også angi to alternativer til.

"allowJs": true, // det vil tillate oss å bruke .js-filer, og typen vil ikke bli sjekket i dem
"skipLibCheck": true // det vil hoppe over å sjekke typer i biblioteker som vi bruker

Med disse alternativene kan vi migrere fra JS til TS trinn for trinn - fil for fil, ved ganske enkelt å endre filtypen fra .js(x) til .ts(x) og legge til typer i filene. På denne måten kan vi unngå hundrevis eller tusenvis av skumle kompileringsfeil.

Sammendrag

Jeg synes vi bør bruke Maskinskrevet manuskript så ofte som muligVi gjør det fordi det er veldig gunstig på lang sikt. Det bidrar til å vedlikeholde prosjekter, øker utviklernes erfaring og gjør kodebasen vår mer tydelig og pålitelig.

Men som alltid finnes det unntak - for eksempel for en enkel landingsside
der JavaScript bare brukes til å veksle klasse eller et annet enkelt tilfelle, gir Typescript ingen mening.
Vi må også huske at for å dra full nytte av Typescript, må vi lære oss å bruke det på et tilstrekkelig nivå, og det kan ta litt tid. Jeg tror likevel det er en svært lønnsom investering av tiden din.

Les mer om dette:

Ruby 3.0. Ruby og mindre kjente metoder for personvernkontroll

Høyeste kvalitetskode i SaaS-prosjektet ditt. Hvorfor bør du som (ikke-teknisk) grunnlegger bry deg om det?

*Tittelgrafikken kommer fra nettstedet Know Your Meme.