Miks peaksite (tõenäoliselt) kasutama Typescript'i

Typescript'i praegune positsioon ei tulnud tühjalt kohalt, sest see tehnoloogia suudab tõesti parandada meie arendajate kogemust. Selgemini selge kodeerimine suurendab kontrolli ja prognoositavust kood.
Selles artiklis püüan teid veenda kasutama Typescripti.

*- Andmeallikas: JS 2020 olukord ja Stack Overflow Developer Survey 2020.

Leia vigadest varem teada

Tavaliselt, kui te arendate rakendust aastal JavaScript, võib teie voolu
näevad välja nii:

1. Tehke muudatus,
2. Mine rakendusse ja vaata muudetud osa / Run (related) tests.
3. Uurige, kas kõik on korras.

Typescriptiga saab tegelikult teha muudatuse ja kui on mingi tüübiviga teie koodis, saate sellest kohe teada tänu kompilaatori veateatele või IDE reaalajas saadavale tagasisidele.
Loomulikult ei lahenda Typescripti kompilaator kõiki probleeme ja ei hoiata teie kõigi vigade eest, kuid selle abi võib olla hindamatu väärtusega.

Parem süntaksi täitmine IDEs

See on väga lihtne. Kui te kasutate head IDE-d, nagu WebStorm või VSCode, siis saate
parem süntaksi täiendamine Typescriptiga. Võib-olla ei tundu see tohutu arendajakogemuse paranemisena, kuid lõppkokkuvõttes on iga paranemine oluline, sest see võib säästa meile aega ja jällegi vältida trükivigu või vigu. Samuti saame oma tüübi või liidese defineerida üks kord; kuna me ei pea alati struktuuri meeles pidama, saame keskenduda äriloogika kirjutamisele.

Vähem valus refaktooring

Kujutage ette, et teil on vaja mingil põhjusel refaktoorida, näiteks liitusite te ühe projekt ja saate ülesande lisada uus funktsioon, kuid see funktsioon on kuidagi seotud vanema koodiga.
Typescript võib seda lihtsamaks ja vähem valusaks teha, sest kui teete muudatuse ja seal on veel üks koht, kus te peate tegema teise muudatuse, siis kompilaator hoiatab teid selle eest.

Näiteks - see võib olla muudetud funktsiooni allkiri või võib-olla pärast muudatust, a
funktsioon tagastab midagi täiesti erinevat, nii et ka tagastatav tüüp on erinev.

Olge koodibaasi suhtes kindlamad

JavaScript on nõrgalt ja dünaamiliselt tüpiseeritud, nii et kui initsialiseerite muutuja väärtusega let query = '' hiljem koodis võib arendaja kogemata teha midagi ebaratsionaalset, näiteks päring = trueja see on kehtiv JS-kood.

Hästi kirjutatud koodis ei tohiks muutujale, mis oli varem string, määrata boole'i väärtust. Nii et tavaliselt tuleneb see tüübimuutusega omistamine veast.

Typescript'i kasutamisel ei saa me muutuja tüüpi muuta, seega kui me teeme muutuja let query = '' muutuja, siis on see string tüüpi ja me ei saa selle tüüpi kogemata muuta.

Kui me tahame lasta muutujal olla rohkem kui ühte tüüpi, siis teeme seda alati selgesõnaliselt, kasutades liidu tüüpi, näiteks string | number.

Seetõttu muudab Typescript meie koodi prognoositavamaks ja selgemaks.
Samuti hoolitseb Typescript kontrollivoogude analüüsis eksplitsiitsuse eest ja kui on võimalus, et midagi võib valesti minna, siis hoiatab ta teid.

Siin näites esimeses kui plokk saame vea:

TS2339: Omadus 'patarei' ei eksisteeri tüübil 'RõivastusToode'. 2 korda, sest akuja ram omadused.

Teises plokis - else, saame selle vea eest suurus vara. Loomulikult on see ainult näide, et näidata, kuidas diskrimineeritud ametiühingud ja kontrollivoogude analüüs töötame Typescriptis, nii et me ei tee selle koodiga midagi liiga keerulist.

Lihtne, järkjärguline üleminek JavaScript-st

Kehtiv JavaScript-kood on samal ajal kehtiv Typescript-kood, nii et saate oma koodibaasi samm-sammult üle viia. Tavaliselt on Typescriptis range režiimi kasutamine hea tava, kuid antud juhul,
peame alustama "strict": false aadressil tsconfig.json ja me peaksime seadma veel 2 võimalust.

"allowJs": true, // see lubab meil kasutada .js faile ja nende tüüpi ei kontrollita.
"skipLibCheck": true // see jätab tüübi kontrollimise kasutatavates raamatukogudes vahele.

Nende valikute abil saame samm-sammult JS-ist TS-i üle minna - failide kaupa, muutes lihtsalt laiendit alates .js(x) aadressile .ts(x) ja tüüpide lisamine failidesse. Seda lähenemisviisi kasutades saame vältida sadu või tuhandeid hirmsaid kompileerimisvigu.

Kokkuvõte

Ma arvan, et me peaksime kasutama Tüüptekst nii tihti kui võimalik, sest see on pikas perspektiivis tõesti kasulik. See aitab säilitada projekte, suurendab arendajate kogemust ning muudab meie koodibaasi selgemaks ja usaldusväärsemaks.

Kuid nagu alati, on ka siin erandeid - näiteks lihtsa maandumislehe puhul võib
kus JavaScript kasutatakse ainult klassi lülitamiseks või muul lihtsal juhul ei ole Typescriptil mõtet.
Samuti peame meeles pidama, et Typescript'i täielikuks ärakasutamiseks tuleb õppida seda kasutama piisaval tasemel ja see võib võtta aega. Ma arvan, et see on ikkagi väga kasumlik investeering oma aega.

Loe edasi:

Ruby 3.0. Ruby ja vähemtuntud privaatsuskontrolli meetodid

Kõrgeima kvaliteediga kood teie SaaS-projektis. Miks peaksite sellest (mittetehnilise) asutajana hoolima?

*Tiitergraafika pärineb veebilehelt Know Your Meme.