Kan du beskrive hva TypeScript-språket er?
Hva kan det gjøre som JavaScript eller tilgjengelige biblioteker ikke kan gjøre, som gir meg grunn til å vurdere det?
Jeg skrev opprinnelig dette svaret da Typescript fortsatt var rykende fersk. Fem år senere, dette er en OK oversikt, men se på Lodewijk&# 39s svar nedenfor for mer dybde
For å få en idé om hva jeg mener, se Microsofts introduksjonsvideo om språket.
For et stort JavaScript-prosjekt kan det å ta i bruk TypeScript resultere i mer robust programvare, samtidig som det fortsatt kan distribueres der en vanlig JavaScript-applikasjon ville kjørt.
Det er åpen kildekode, men du får bare den smarte Intellisense mens du skriver hvis du bruker en IDE som støttes. Opprinnelig var dette bare Microsofts Visual Studio (også nevnt i blogginnlegg fra Miguel de Icaza). I disse dager tilbyr andre IDE-er også TypeScript-støtte.
Som et eksempel, her's litt TypeScript (du kan leke med dette i TypeScript Playground)
class Greeter {
greeting: string;
constructor (message: string) {
this.greeting = message;
}
greet() {
return "Hello, " + this.greeting;
}
}
Og her'er JavaScriptet det ville produsere
var Greeter = (function () {
function Greeter(message) {
this.greeting = message;
}
Greeter.prototype.greet = function () {
return "Hello, " + this.greeting;
};
return Greeter;
})();
Legg merke til hvordan TypeScript definerer typen av medlem variabler og klasse metode parametere. Dette fjernes når du oversetter til JavaScript, men brukes av IDE og kompilator for å oppdage feil, som å sende en numerisk type til konstruktøren.
Det er også i stand til å utlede typer som ikke er eksplisitt deklarert, for eksempel vil det bestemme at greet()
-metoden returnerer en streng.
TypeScript er et typet supersett av JavaScript som kompileres til vanlig JavaScript - typescriptlang.org. JavaScript er et programmeringsspråk som er utviklet av EMCAs tekniske komité 39, som er en gruppe mennesker sammensatt av mange forskjellige interessenter. TC39 er en komité under ECMA: en intern standardiseringsorganisasjon. JavaScript har mange forskjellige implementeringer fra mange forskjellige leverandører (f.eks. Google, Microsoft, Oracle osv.). Målet med JavaScript er å være nettets lingua franca. TypeScript er et supersett av JavaScript-språket som har en enkelt åpen kildekodekompilator og hovedsakelig er utviklet av én enkelt leverandør: Microsoft. Målet med TypeScript er å bidra til å fange opp feil tidlig gjennom et typesystem og å gjøre JavaScript-utviklingen mer effektiv. I hovedsak oppnår TypeScript sine mål på tre måter:
- Støtte for moderne JavaScript-funksjoner - JavaScript-språket (ikke kjøretiden) er standardisert gjennom ECMAScript-standardene. Ikke alle nettlesere og JavaScript-kjøretider støtter alle funksjonene i alle ECMAScript-standardene (se denne oversikten). TypeScript tillater bruk av mange av de nyeste ECMAScript-funksjonene og oversetter dem til eldre ECMAScript-mål etter eget valg (se listen over compile targets under kompilatoralternativet
--target
). Dette betyr at du trygt kan bruke nye funksjoner, som moduler, lambda-funksjoner, klasser, spredningsoperatoren og destrukturering, samtidig som du forblir bakoverkompatibel med eldre nettlesere og JavaScript-kjøretider.- Avansert typesystem - Typestøtten er ikke en del av ECMAScript-standarden og vil sannsynligvis aldri bli på grunn av den tolkede naturen i stedet for den kompilerte naturen til JavaScript. Typesystemet til TypeScript er utrolig rikt og inkluderer: grensesnitt, enums, hybride typer, generics, union/intersection types, access modifiers og mye mer. Det offisielle nettstedet til TypeScript gir en oversikt over disse funksjonene. Typescript&# 39s typesystem er på nivå med de fleste andre typede språk og i noen tilfeller uten tvil kraftigere.
- Støtte for utviklerverktøy - TypeScripts kompilator kan kjøres som en bakgrunnsprosess for å støtte både inkrementell kompilering og IDE-integrasjon slik at du lettere kan navigere, identifisere problemer, inspisere muligheter og refaktorere kodebasen din.
TypeScript&# 39s forhold til andre JavaScript-målspråk
TypeScript har en unik filosofi sammenlignet med andre språk som kompilerer til JavaScript. JavaScript-kode er gyldig TypeScript-kode; TypeScript er et supersett av JavaScript. Du kan nesten omdøpe
.js
-filene dine til.ts
-filer og begynne å bruke TypeScript (se "JavaScript-interoperabilitet" nedenfor). TypeScript-filer er kompilert til lesbar JavaScript, slik at migrering tilbake er mulig, og det er ikke vanskelig å forstå den kompilerte TypeScript i det hele tatt. TypeScript bygger på suksessene til JavaScript samtidig som det forbedrer svakhetene. På den ene siden har du fremtidssikre verktøy som tar moderne ECMAScript-standarder og kompilerer dem ned til eldre JavaScript-versjoner, med Babel som den mest populære. På den annen side har du språk som kan være helt forskjellige fra JavaScript som er rettet mot JavaScript, som CoffeeScript, Clojure, Dart, Elm, Haxe, Scala.js og en hel rekke flere (se denne listen). Disse språkene, selv om de kan være bedre enn hvor JavaScript&# 39s fremtid noen gang kan føre, løper en større risiko for ikke å finne nok adopsjon for at deres fremtid skal være garantert. Du kan også ha større problemer med å finne erfarne utviklere for noen av disse språkene, selv om de du finner ofte kan være mer entusiastiske. Interop med JavaScript kan også være litt mer involvert, siden de er lenger borte fra hva JavaScript faktisk er. TypeScript ligger mellom disse to ytterpunktene, og balanserer dermed risikoen. TypeScript er ikke et risikabelt valg etter noen standard. Det tar veldig lite innsats å bli vant til hvis du er kjent med JavaScript, siden det ikke er et helt annet språk, har utmerket JavaScript-interoperabilitetsstøtte og det har sett mye adopsjon nylig.Eventuelt statisk typing og type inferens
JavaScript er dynamisk skrevet. Dette betyr at JavaScript ikke vet hvilken type en variabel er før den faktisk er instansiert ved kjøretid. Dette betyr også at det kan være for sent. TypeScript legger til typestøtte til JavaScript. Feil som er forårsaket av falske antagelser om at en variabel er av en bestemt type, kan utryddes fullstendig hvis du spiller kortene dine riktig (hvor streng du skriver koden din eller om du i det hele tatt skriver koden din, er opp til deg). TypeScript gjør skriving litt enklere og mye mindre eksplisitt ved bruk av typeinferens. For eksempel:
var x = ""hello""
i TypeScript er det samme somvar x : string = ""hello""
. Typen er ganske enkelt utledet fra bruken. Selv om du ikke skriver typene eksplisitt, er de fortsatt der for å redde deg fra å gjøre noe som ellers ville resultere i en kjøretidsfeil. TypeScript er valgfritt skrevet som standard. For eksempel erfunction divideByTwo(x) { return x / 2 }
en gyldig funksjon i TypeScript som kan kalles med en hvilken som helst type parameter, selv om å kalle den med en streng åpenbart vil resultere i en runtime feil. Akkurat som du er vant til i JavaScript. Dette fungerer fordi når ingen type ble eksplisitt tilordnet og typen ikke kunne utledes, som i divideByTwo-eksemplet, vil TypeScript implisitt tilordne typenany
. Dette betyr at divideByTwo-funksjonens typesignatur automatisk blirfunction divideByTwo(x : any) : any
. Det finnes et kompilatorflagg for å hindre denne oppførselen:--noImplicitAny
. Aktivering av dette flagget gir deg en større grad av sikkerhet, men betyr også at du må skrive mer. Typer har en kostnad forbundet med dem. For det første er det en læringskurve, og for det andre vil det selvfølgelig koste deg litt mer tid å sette opp en kodebase ved hjelp av riktig streng typing også. Etter min erfaring er disse kostnadene helt verdt det på enhver seriøs kodebase du deler med andre. A Large Scale Study of Programming Languages and Code Quality in Github antyder at &" statisk typede språk, generelt, er mindre utsatt for feil enn de dynamiske typene, og at sterk typing er bedre enn svak typing i samme henseende &".. Det er interessant å merke seg at den samme artikkelen finner at TypeScript er mindre feilutsatt enn JavaScript: For de med positive koeffisienter kan vi forvente at språket er assosiert med, ceteris paribus, et større antall feilrettinger. Disse språkene inkluderer C, C++, JavaScript, Objective-C, Php og Python. Språkene Clojure, Haskell, Ruby, Scala og TypeScript, har alle negative koeffisienter, noe som innebærer at disse språkene er mindre sannsynlig enn gjennomsnittet å resultere i feilrettingsforpliktelser.Forbedret IDE-støtte
Utviklingsopplevelsen med TypeScript er en stor forbedring i forhold til JavaScript. IDE blir informert i sanntid av TypeScript-kompilatoren om dens rike typeinformasjon. Dette gir et par store fordeler. Med TypeScript kan du for eksempel trygt gjøre refactorings som å gi nytt navn på tvers av hele kodebasen. Gjennom kodeutfylling kan du få direkte hjelp til alle funksjoner et bibliotek kan tilby. Du trenger ikke lenger å huske dem eller slå dem opp i nettreferanser. Kompileringsfeil rapporteres direkte i IDE med en rød krøllete linje mens du er opptatt med koding. Alt i alt gir dette en betydelig produktivitetsgevinst sammenlignet med å jobbe med JavaScript. Man kan bruke mer tid på koding og mindre tid på feilsøking. Det finnes et bredt spekter av IDE-er som har utmerket støtte for TypeScript, som Visual Studio Code, WebStorm, Atom og Sublime.
Strenge null-sjekker
Kjøretidsfeil av formen
kan ikke lese egenskapen 'x' av udefinert
ellerudefinert er ikke en funksjon
er veldig ofte forårsaket av feil i JavaScript-kode. Ut av boksen TypeScript reduserer allerede sannsynligheten for at denne typen feil oppstår, siden man ikke kan bruke en variabel som ikke er kjent for TypeScript-kompilatoren (med unntak av egenskaper tilany
typede variabler). Det er imidlertid fortsatt mulig å feilaktig bruke en variabel som er satt tiludefinert
. Med 2.0-versjonen av TypeScript kan du imidlertid eliminere denne typen feil ved å bruke typer som ikke kan nullstilles. Dette fungerer som følger: Med strenge nullkontroller aktivert (--strictNullChecks
kompilatorflagg) vil TypeScript-kompilatoren ikke tillate atundefined
tilordnes en variabel med mindre du eksplisitt erklærer at den er av nullbar type. For eksempel villet x : number = undefined
resultere i en kompileringsfeil. Dette passer perfekt med typeteori sidenundefined
ikke er et tall. Man kan definerex
til å være en sumtype avnumber
ogundefined
for å korrigere dette:let x : number | undefined = undefined
. Når en type er kjent for å være nullable, noe som betyr at den er av en type som også kan ha verdiennull
ellerundefined
, kan TypeScript-kompilatoren avgjøre gjennom kontrollflytbasert typeanalyse om koden din trygt kan bruke en variabel eller ikke. Med andre ord, når du sjekker at en variabel erudefinert
gjennom for eksempel enif
-setning, vil TypeScript-kompilatoren utlede at typen i den grenen av kodens kontrollflyt ikke lenger er nullbar og derfor trygt kan brukes. Her er et enkelt eksempel:
let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.
Under byggingen ga Anders Hejlsberg, meddesigner av TypeScript på konferansen i 2016, en detaljert forklaring og demonstrasjon av denne funksjonen: video (fra 44:30 til 56:30).
For å bruke TypeScript trenger du en kompileringsprosess for å kompilere til JavaScript-kode. Byggeprosessen tar vanligvis bare et par sekunder, selvfølgelig avhengig av størrelsen på prosjektet ditt. TypeScript-kompilatoren støtter inkrementell kompilering (--watch
kompilatorflagg) slik at alle påfølgende endringer kan kompileres med større hastighet.
TypeScript-kompilatoren kan legge inn informasjon om kildekart i de genererte .js-filene eller opprette separate .map-filer. Kildekartinformasjon kan brukes av feilsøkingsverktøy som Chrome DevTools og andre IDE-er for å relatere linjene i JavaScript til de som genererte dem i TypeScript. Dette gjør det mulig for deg å sette breakpoints og inspisere variabler under kjøring direkte på TypeScript-koden. Kildekartinformasjon fungerer ganske bra, det eksisterte lenge før TypeScript, men feilsøking av TypeScript er generelt ikke så bra som når du bruker JavaScript direkte. Ta for eksempel nøkkelordet this
. På grunn av den endrede semantikken til nøkkelordet this
rundt avslutninger siden ES2015, kan this
faktisk eksistere under kjøretid som en variabel kalt _this
(se dette svaret). Dette kan forvirre deg under feilsøking, men er vanligvis ikke et problem hvis du vet om det eller inspiserer JavaScript-koden. Det bør bemerkes at Babel lider av nøyaktig samme type problem.
Det er noen andre triks TypeScript-kompilatoren kan gjøre, som å generere avskjæringskode basert på dekoratører, generere modulbelastningskode for forskjellige modulsystemer og analysere JSX. Imidlertid vil du sannsynligvis trenge et byggeverktøy i tillegg til Typescript-kompilatoren. Hvis du for eksempel vil komprimere koden din, må du legge til andre verktøy i byggeprosessen for å gjøre det.
Det er TypeScript-kompileringstillegg tilgjengelig for Webpack, Gulp, Grunt og stort sett alle andre JavaScript-byggeverktøy der ute. TypeScript-dokumentasjonen har en seksjon om integrering med byggeverktøy som dekker dem alle. En linter er også tilgjengelig i tilfelle du ønsker enda mer kontroll av byggetiden. Det finnes også et stort antall frøprosjekter der ute som vil få deg i gang med TypeScript i kombinasjon med en rekke andre teknologier som Angular 2, React, Ember, SystemJS, Webpack, Gulp osv.
Siden TypeScript er så nært beslektet med JavaScript, har det gode interoperabilitetsfunksjoner, men det kreves litt ekstra arbeid for å jobbe med JavaScript-biblioteker i TypeScript. TypeScript-definisjoner er nødvendig slik at TypeScript-kompilatoren forstår at funksjonskall som _.groupBy
eller angular.copy
eller $.fadeOut
faktisk ikke er ulovlige uttalelser. Definisjonene for disse funksjonene plasseres i .d.ts
-filer.
Den enkleste formen en definisjon kan ha, er å tillate at en identifikator brukes på en hvilken som helst måte. For eksempel, når du bruker Lodash, vil en enkelt linje definisjonsfil deklarere var _ : any
tillate deg å kalle en hvilken som helst funksjon du vil på _
, men da er du selvfølgelig også fortsatt i stand til å gjøre feil: _.foobar()
ville være et lovlig TypeScript-kall, men er selvfølgelig et ulovlig kall under kjøring. Hvis du vil ha riktig typestøtte og kodeutfylling, må definisjonsfilen din være mer nøyaktig (se lodash-definisjoner for et eksempel).
Npm-moduler som kommer ferdig pakket med sine egne typedefinisjoner blir automatisk forstått av TypeScript-kompilatoren (se documentation). For stort sett alle andre semi-populære JavaScript-bibliotek som ikke inkluderer sine egne definisjoner, har noen der ute allerede gjort typedefinisjoner tilgjengelig gjennom en annen npm-modul. Disse modulene er prefikset med "@types/" og kommer fra en Github repository kalt DefinitelyTyped.
Det er én advarsel: typedefinisjonene må samsvare med versjonen av biblioteket du bruker på kjøretidspunktet. Hvis de ikke gjør det, kan TypeScript nekte deg å kalle en funksjon eller dereferensiere en variabel som eksisterer, eller tillate deg å kalle en funksjon eller dereferensiere en variabel som ikke eksisterer, rett og slett fordi typene ikke samsvarer med kjøretiden på kompileringstidspunktet. Så sørg for at du laster inn riktig versjon av typedefinisjonene for riktig versjon av biblioteket du bruker.
For å være ærlig er det litt bry med dette, og det kan være en av grunnene til at du ikke velger TypeScript, men i stedet går for noe som Babel som ikke lider av å måtte hente typedefinisjoner i det hele tatt. På den annen side, hvis du vet hva du gjør, kan du enkelt overvinne alle slags problemer forårsaket av feil eller manglende definisjonsfiler.
Enhver .js
-fil kan omdøpes til en .ts
-fil og kjøres gjennom TypeScript-kompilatoren for å få syntaktisk den samme JavaScript-koden som utdata (hvis den var syntaktisk korrekt i utgangspunktet). Selv når TypeScript-kompilatoren får kompileringsfeil, vil den fremdeles produsere en .js
-fil. Den kan til og med godta .js
-filer som input med --allowJs
-flagget. Dette lar deg starte med TypeScript med en gang. Dessverre vil det sannsynligvis oppstå kompileringsfeil i begynnelsen. Man må huske at dette ikke er show-stoppende feil som du kanskje er vant til med andre kompilatorer.
Kompileringsfeilene man får i begynnelsen når man konverterer et JavaScript-prosjekt til et TypeScript-prosjekt er uunngåelige av TypeScript&# 39s natur. TypeScript sjekker all kode for gyldighet og må derfor vite om alle funksjoner og variabler som brukes. Derfor må typedefinisjoner være på plass for dem alle, ellers vil det garantert oppstå kompileringsfeil. Som nevnt i kapittelet over, finnes det for stort sett alle JavaScript-rammeverk .d.ts
-filer som enkelt kan anskaffes ved installasjon av DefinitelyTyped-pakker. Det kan imidlertid være at du har brukt et obskurt bibliotek som det ikke finnes TypeScript-definisjoner for, eller at du har polyfylt noen JavaScript-primitiver. I så fall må du levere typedefinisjoner for disse bitene for at kompileringsfeilene skal forsvinne. Bare opprett en .d.ts
-fil og inkluder den i tsconfig.json's files
-array, slik at den alltid blir vurdert av TypeScript-kompilatoren. I den erklærer du de bitene som TypeScript ikke vet om som type any
. Når du har eliminert alle feil, kan du gradvis introdusere skriving til disse delene i henhold til dine behov.
Noe arbeid med å (re)konfigurere byggepipelinen din vil også være nødvendig for å få TypeScript inn i byggepipelinen. Som nevnt i kapittelet om kompilering finnes det mange gode ressurser der ute, og jeg oppfordrer deg til å se etter frøprosjekter som bruker den kombinasjonen av verktøy du ønsker å jobbe med.
Den største hindringen er læringskurven. Jeg oppfordrer deg til å leke deg med et lite prosjekt til å begynne med. Se hvordan det fungerer, hvordan det bygger, hvilke filer det bruker, hvordan det er konfigurert, hvordan det fungerer i IDE, hvordan det er strukturert, hvilke verktøy det bruker osv. Å konvertere en stor JavaScript-kodebase til TypeScript er gjennomførbart når du vet hva du gjør. Les denne bloggen for eksempel på konvertere 600k linjer til typescript på 72 timer). Bare sørg for at du har en god forståelse av språket før du gjør hoppet.
TypeScript er åpen kildekode (Apache 2-lisensiert, se GitHub) og støttes av Microsoft. Anders Hejlsberg, hovedarkitekten for C#, leder prosjektet. Det er et veldig aktivt prosjekt; TypeScript-teamet har lansert mange nye funksjoner de siste årene, og det er fortsatt planlagt mange flotte funksjoner (se veikartet). Noen fakta om adopsjon og popularitet:
"TypeScript Fundamentals " -- et Pluralsight-videokurs av Dan Wahlin og John Papa er en veldig god, for tiden (25. mars 2016) oppdatert for å gjenspeile TypeScript 1.8, introduksjon til Typescript.
For meg er de virkelig gode funksjonene, ved siden av de fine mulighetene for intellisense, klasser, grensesnitt, moduler, den enkle implementeringen av AMD, og muligheten til å bruke Visual Studio Typescript debugger når den påkalles med IE.
For å oppsummere: Hvis det brukes som tiltenkt, kan Typescript gjøre JavaScript-programmering mer pålitelig og enklere. Det kan øke produktiviteten til JavaScript-programmereren betydelig over hele SDLC.