JavaScript kan snart ha sin egen typsyntax om ett förslag som lämnats av Microsoft och andra utvecklare tidigare i år blir en del av ECMAScript-standarden. Initiativet planerar att lägga till “typer som kommentarer” stöd för JavaScript-språket, vilket låter utvecklare kommentera kod med typinformation som kommer att användas av andra ekosystemkomponenter.
Syntaxen
Den föreslagna syntaxen ser ut så här:
function sayAge(name: string, age: number) { console.log(`${namn} är ${ålder} år gammal.`); } sayAge("JavaScript", 26);
Det kommer att vara bekant för alla som tidigare har använt TypeScript, Microsofts maskinskrivna superset av JavaScript. TypeScript har fått en utbredd användning i branschen; detta nya förslag utger sig för att ge några av dess fördelar till den bredare JavaScript-världen.
Vad är inte förslaget?
Om det godkänns låter det här förslaget dig skriva helt giltig JavaScript med typanteckningarna som visas ovan. Det kommer att accepteras av JavaScript-körtider som webbläsare, Node.js och Deno som respekterar ES-standarden.
Förslaget utökar faktiskt inte JavaScript-språket. Dina typkommentarer kommer att vara exakt det: inerta metadata som inte har någon effekt på JavaScript-kompilatorn eller din kods körtid. Ett funktionsanrop som följande skulle fungera under körning:
function sayAge(name: string, age: number) { console.log(`${namn} är ${ålder} år gammal.`); } //"ålder" är en sträng när det ska vara ett tal, men det är fortfarande tillåtet att säga Ålder("JavaScript", "tjugo");
Tanken är att erbjuda en ny typsyntax som officiellt stöds men helt ignoreras av motorer. Den enda förändringen för implementeringar gäller att känna igen och ta bort typkommentarer varhelst de används.
Förslaget syftar till att skapa stöd för att kommentera typerna av parametrar, variabler och klassegenskaper. Det skulle också titta på att lägga till ett gränssnittsnyckelord, påståendeoperatorer som ! och som, och en ? modifierare för att markera typer som valfria. Avsikten är att alla dessa element ska spegla TypeScript; som med alla steg 0-förslag kan det slutliga resultatet dock fungera annorlunda.
Vad är poängen?
Om typkommentarer inte kommer att förändra ditt program är den uppenbara frågan om de är värda att ha. I förslaget argumenteras “ja” på grund av syntaxens förmåga att förkorta iterationstider och minska bördan kring moderna JavaScript-verktygskedjor.
Att skriva typsäker kod kräver för närvarande att du använder TypeScript, en annan språksmak som lägger till beroenden till ditt projekt och kräver ett manuellt kompileringssteg. Den koden kan sedan passera genom andra verktyg som en modulbuntare och transpilerare innan ditt slutliga JavaScript produceras för distribution. Det blir en komplex verktygskedja med flera rörliga delar.
Även om JavaScript är ett naturligt löst skrivet språk, är fördelarna med stark skrivning nu allmänt erkända av samhället. Så mycket framgår av farten kring TypeScript-projektet. Statisk typning var också den tydliga ledaren i 2021 års State of JS-undersöknings “missing feature” fråga.
Om du lägger till en typsyntax i JavaScript själv kan du få några av fördelarna med TypeScript utan att behöva kompilera din kod. Detta förenklar projektinställning och underhåll samtidigt som JavaScript utvecklas för att bättre anpassas till moderna utvecklingsmetoder.
Under de senaste åren har mer kod börjat migrera tillbaka mot en “ren JavaScript” närma sig. Nedgången av äldre webbläsare gör transpilering mindre nödvändig än den en gång var – majoriteten av moderna implementeringar erbjuder fullt stöd för funktioner som klasser, pilfunktioner, blockomfattade variabler och async/await. JavaScript’s fick till och med ett fullfjädrat modulsystem som fungerar över motorer, inklusive i webbläsare.
För bara några år sedan krävdes en lång verktygskedja för att kunna skriva in dessa funktioner i din kod med förtroende för att det skulle fungera på användare’ enheter. Nuförtiden kan utvecklare säkert lägga dessa byggprocesser åt sidan och återgå till den ursprungliga JavaScript-modellen för att referera filer med <script> taggar.
Typer är ett av de få återstående områdena i JavaScript-ekosystemet som inte ryms av själva språket. Älska dem eller hata dem, det går inte att förneka att typer har blivit en integrerad del av JavaScript-utveckling för många team och projekt. Syntaxförslaget erkänner formellt detta faktum. Den försöker få en viss typ av typstöd till JavaScript utan att bryta befintlig kod eller genomdriva prestandapåverkande körningstypkontroller.
Vad bör typerna egentligen göra?
Rollen av en “typ” varierar mellan språken. Den gemensamma demonatorn ligger i en typs förmåga att uttrycka vilken typ av data en viss variabel kommer att innehålla. Ytterligare betydelser, förmågor och beteenden läggs sedan på den grunden.
I statiskt skrivna kompilerade språk som C# och Java, tillämpas typer vid kompilering. Det är omöjligt att kompilera ett program när du har typinkompatibiliteter i din kod. I tolkade språk med valfri stark typning, där PHP är ett exempel, upprätthålls typer vid körning – programmet ger ett felmeddelande när ett värdes typ är inkompatibelt med sammanhanget där det används.
En aktiv debatt inom JavaScript-communityt har varit hur långt ett inbyggt systems uppdrag bör sträcka sig. Detta förslag begränsar dess roll till det mest grundläggande elementet, en enkel dokumentation av ett värdes förväntade typ. Detta överensstämmer väl med TypeScripts position som en raderbar typsyntax som ignoreras vid körning.
Syftet med denna modell är att ge utvecklare omedelbar feedback om potentiella buggar när de skriver kod. Du kan få information om typproblem när du skriver vanlig JavaScript i en kompatibel IDE. Om du vill kan du också använda ett stödverktyg som TypeScript, en statisk analysator eller en buntare för att granska din källa på begäran. Detta kan blockera en distribution i dina CI-pipelines när ett typproblem finns.
Den nuvarande känslan är att dessa funktioner är tillräckliga för att anpassa JavaScript till de vanligaste utvecklarbehoven. Funktioner som finns på andra språk som introspektion och reflektion behövs inte vanligtvis inom JavaScript-ekosystemet, delvis på grund av att utvecklare har vant sig vid TypeScripts raderingsmetod.
Det befintliga alternativet: docblocks
Det är värt att notera att något som liknar den föreslagna syntaxen för raderade kommentarer redan existerar: bekanta JSDoc-taggar används vanligtvis för att lägga till typdetaljer till vanlig JavaScript-kod:
/** * @paramnamn {string} * @ param age {number} */function sayAge(name, age) { console.log(`${namn} är ${ålder} år gammal.`); }
JSDoc-kommentarer stöds av olika populära verktyg. De är dock inte en standardiserad del av språket och de kräver att du blandar detaljer om din kods funktion – dess förväntade typer – med den mänskligt centrerade dokumentationen som omfattar resten av docblocket.
JSDoc’s syntax är också mycket mångsidig. Förutom de obligatoriska taggnamnen kräver det vanligtvis upprepning av element som redan finns i din kod, till exempel parameternamnen i exemplet ovan. Om du ändrar en parameter i funktionens signatur måste du komma ihåg att ändra JSDoc-taggen också.
Det nya syntaxförslaget kan vara funktionellt likvärdigt med docblocks men det erbjuder en mycket mer strömlinjeformad upplevelse. Typer sitter bredvid sina mål som en del av din källa, istället för i ett dokumentblock som du måste skriva och underhålla separat.
Vad är nästa?
Microsofts TypeScript-team och medförfattare inklusive Bloomberg, Igwalia och flera oberoende bidragsgivare lämnade in Steg 0-förslaget i TC39-plenumet i mars 2022. Förslaget har sedan dess gått in i steg 1. Acceptansen är dock fortfarande en bit bort, med implementering i motorer som eventuellt inte kommer på “år.”
Det övergripande syftet med detta förslag är att balansera JavaScripts långa svans av otypad kod med den nuvarande efterfrågan på en mer statiskt typad utvecklingsupplevelse. Användningen av en raderad helt valfri syntax garanterar bakåtkompatibilitet men ökar utsikterna att det inte kommer att vara ineffektivt när det gäller att uppmuntra adoption och konsolidera ekosystemet. Debatten kring denna ser ut att växa med nya åsikter och perspektiv allt eftersom förslaget fortskrider genom standardspåret.
LÄS NÄSTA
- › Hur man avblockerar Spotify
- › Windows 11’s 2022-uppdatering är här, filutforskaren flikar snart
- › Så här kontrollerar du PowerShell-versionen i Windows 11
- › Så här installerar du Windows 11’s 2022-uppdatering (22H2)
- › Hur man tar ögonblicksbilder i VLC
- › Så här uppdaterar du PowerShell i Windows 11