Sök…


Introduktion

Om du tycker att argumenten för typsystem är övertygande i allmänhet är du nöjd med TypeScript.

Det ger många av fördelarna med typsystem (säkerhet, läsbarhet, förbättrad verktyg) till JavaScript-ekosystemet. Det lider också av några av nackdelarna med typsystem (extra komplexitet och ofullständighet).

Anmärkningar

Meriterna med typade kontra otypade språk har diskuterats i årtionden. Argument för statiska typer inkluderar:

  1. Säkerhet: typsystem gör att många fel kan fångas tidigt utan att köra koden. TypeScript kan konfigureras så att färre programmeringsfel tillåts
  2. Läsbarhet: explicita typer gör koden lättare för människor att förstå. Som Fred Brooks skrev: "Visa mig dina flödesscheman och dölja dina bord, och jag ska fortsätta att vara mystifierad. Visa mig dina tabeller, och jag behöver vanligtvis inte dina flödesscheman; de kommer att vara uppenbara."
  3. Verktyg: typsystem gör kod lättare för datorer att förstå. Detta gör att verktyg som IDE och linters kan vara mer kraftfulla.
  4. Prestanda: typsystem gör att koden körs snabbare genom att minska behovet av körningstypkontroll.

Eftersom TypeScript-utgången är oberoende av dess typer , har TypeScript ingen inverkan på prestanda. Argumentet för att använda TypeScript vilar på de tre andra fördelarna.

Argument mot typsystem inkluderar:

  1. Tillagd komplexitet: typsystem kan vara mer komplexa än språktiden som de beskriver. Funktioner med högre ordning kan vara enkla att implementera korrekt men svåra att skriva . Att hantera typdefinitioner skapar ytterligare hinder för att använda externa bibliotek.
  2. Tillagd verbositet: typanteckningar kan lägga till pannplatta till din kod, vilket gör den underliggande logiken svårare att följa.
  3. Långsammare iteration: genom att införa ett byggsteg bromsar TypeScript redigerings- / spara / laddningscykeln.
  4. Ofullständighet: Ett typsystem kan inte vara både ljud och komplett. Det finns korrekta program som TypeScript inte tillåter. Och program som TypeScript accepterar kan fortfarande innehålla buggar. Ett typsystem minskar inte behovet av testning. Om du använder TypeScript kanske du måste vänta längre för att använda nya ECMAScript-språkfunktioner.

TypeScript erbjuder några sätt att hantera alla dessa problem:

  1. Tillsatt komplexitet. Om det är för svårt att skriva en del av ett program kan TypeScript till stor del inaktiveras med en ogenomskinlig any typ som any . Detsamma gäller för externa moduler.
  2. Tillagd verbositet. Detta kan delvis hanteras genom typalias och TypeScript: s förmåga att dra slutsatser. Att skriva tydlig kod är lika mycket en konst som en vetenskap: ta bort för många anteckningar av typen och koden kanske inte längre är tydlig för mänskliga läsare.
  3. Långsammare iteration: Ett build-steg är relativt vanligt i modern JS-utveckling och TypeScript integreras redan med de flesta build-verktyg . Och om TypeScript får ett fel tidigt kan det spara en hel iterationscykel!
  4. Ofullständighet. Även om detta problem inte kan lösas helt, har TypeScript kunnat fånga fler och mer uttryckliga JavaScript-mönster över tid. Nya exempel inkluderar tillägg av mappade typer i TypeScript 2.1 och mixins i 2.2 .

Argumenten för och mot typsystem i allmänhet gäller lika bra för TypeScript. Att använda TypeScript ökar omkostningen till att starta ett nytt projekt. Men med tiden, när projektet ökar i storlek och får fler bidragsgivare, är hoppet att fördelarna med att använda det (säkerhet, läsbarhet, verktyg) blir starkare och överväger nackdelarna. Detta återspeglas i TypeScript: s motto: "JavaScript som skalar."

Säkerhet

TypeScript fångar typfel tidigt genom statisk analys:

function double(x: number): number {
  return 2 * x;
}
double('2');
//     ~~~ Argument of type '"2"' is not assignable to parameter of type 'number'.

Läsbarhet

TypeScript gör det möjligt för redaktörer att tillhandahålla sammanhangsdokumentation:

Contextual autocomplete för strängskivmetod

Du kommer aldrig att glömma om String.prototype.slice tar (start, stop) eller (start, length) igen!

Tooling

TypeScript tillåter redaktörer att utföra automatiska refaktorer som är medvetna om språkreglerna.

En symbol som byts namn, men bara i sitt eget räckvidd

Här, till exempel, kan Visual Studio Code byta namn på referenser till den inre foo utan att förändra den yttre foo . Detta skulle vara svårt att göra med en enkel hitta / ersätta.



Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow