引言

在布達佩斯2022 JSConf會議上，tc39（ES標(biāo)準(zhǔn)委員會）成員Gil Tayar介紹了一份當(dāng)前仍處于stage 1階段的提案 —— Type Annotations，意在讓原生JS支持類型注解。

換句話說，如果提案通過，很多.ts文件將后綴改為.js后就能直接在瀏覽器中運行。

一份tc39提案通常會經(jīng)歷5個階段：

• stage 0：被提出
• stage 1：接受審議
• stage 2：規(guī)范基本完成
• stage 3：等待被實現(xiàn)
• stage 4：納入語言標(biāo)準(zhǔn)中

所以Type Annotations當(dāng)前仍處于接受審議的狀態(tài)。

但是提案發(fā)起者Gil Tayar對這份提案的通過很有信心，本文我們來聊聊這份提案的相關(guān)內(nèi)容。

為什么需要原生類型注解？

根據(jù)20年、21年state of JS的統(tǒng)計，靜態(tài)類型高票當(dāng)選JS中當(dāng)前最欠缺的功能。

同時，在Github報告中，TS被列為第四大最常用的語言

所以，對前端工程師來說，類型注解需求很大。

那么，既然已經(jīng)有了TS，為什么還需要原生JS支持類型注解呢？

通常來說，從開發(fā)者編寫的源代碼到線上生產(chǎn)環(huán)境代碼間需要經(jīng)過代碼編譯。

代碼編譯主要包括兩個步驟：

• 降級編譯（包括高級語法轉(zhuǎn)換為低級語法，高級方法的polyfill）
• 代碼轉(zhuǎn)譯（比如壓縮、混淆、tree-shaking、類型擦除）

所謂類型擦除，是指擦除代碼中的類型注解，讓其變成符合原生JS規(guī)范的代碼，比如：

// 擦除前
function add(a: number, b: number): number {
  return a + b;
}
// 擦除后
function add(a, b) {
  return a + b;
}

隨著時間的推移，各主流瀏覽器兼容性越來越好，步驟1在可預(yù)見的未來重要性會逐漸降低。

對于TS開發(fā)者，從源代碼到線上生產(chǎn)環(huán)境代碼間可能只需要類型擦除。

如果原生JS支持類型注解，就能省去類型擦除對應(yīng)的編譯流程，讓代碼更容易在宿主環(huán)境執(zhí)行。

和TS的關(guān)系

這份提案的目的，并不是另起爐灶，獨立實現(xiàn)一套原生JS的類型注解。而是與TS團隊合作，提出一套合適的規(guī)范。

新的規(guī)范與TS規(guī)范的關(guān)系類似下圖：

一方面，Type Annotations提案從TS中借鑒了很多特性，這就是圖中相交的部分。

你可以到grammar-conventions看到規(guī)范當(dāng)前定義的類型

另一方面，TS迭代速度很快，新的特性產(chǎn)出很快。而Type Annotations作為JS語言的一部分，迭代會更加保守，所以TS中一些特性在Type Annotations中并不支持。

此外，TS中一些結(jié)構(gòu)（比如Enums、Namespaces）存在運行時的語義，Type Annotations也不會支持。

這些就是TS中存在，而Type Annotations中不存在的部分。

最后，Type Annotations設(shè)計的初衷并不是與TS強綁定，而僅僅是提供一套類型規(guī)范，開發(fā)者編寫代碼時的類型檢查還是由各種類型檢查器（比如TS、Flow）實現(xiàn)。

所以，Type Annotations還有一部分特性是TS當(dāng)前未定義的，這也是為了規(guī)范更廣泛的適用性考慮的，也就是圖中Type Annotations存在，而TS不存在的部分。

這部分特性需要TS后續(xù)實現(xiàn)，這也是為什么Type Annotations要與TS團隊合作的一大原因。

對開發(fā)者意味著什么

如果Type Annotations最終出現(xiàn)在ES20xx版中，屆時開發(fā)者編寫代碼的步驟是：

• 選擇合適的類型檢查器（比如TS），這個類型檢查器需要完全遵循Type Annotations規(guī)范（而不是自己的規(guī)范，比如TS規(guī)范）
• 編寫帶類型聲明的原生JS代碼
• 類型檢查器會檢查類型錯誤，并給予報錯或提示

對于如下原生JS代碼，如果開發(fā)者傳入了錯誤的類型，JS會報錯么？

function add(a: number, b: number): number {
  return a + b;
}
// 錯誤的類型傳參
add('KaSong', 123);

答案是：不會。

Type Annotations僅僅是一套規(guī)范，該規(guī)范由各種類型檢查器執(zhí)行。

JS的宿主環(huán)境（比如瀏覽器）在執(zhí)行帶類型聲明的JS代碼時，會忽略類型聲明。

總結(jié)

有同學(xué)可能會問：就為了減少編譯時類型擦除這一步，就提出原生類型規(guī)范，有必要么？

甚至當(dāng)Type Annotations落地后，開發(fā)者上線前在進行代碼壓縮時，類型擦除也會作為代碼壓縮的職責(zé)之一。

從這個角度看，甚至沒有減少編譯時的工作量。

所以提出原生的類型規(guī)范，有必要么？

前端的發(fā)展實際是一個努力去編譯時流程的過程。

比如，編譯時代碼需要降級，需要polyfill？隨著IE11停止服務(wù)，主流瀏覽器紛紛跟進標(biāo)準(zhǔn)落地，降級與polyfill的需求逐漸變少。

再比如，代碼需要打包？隨著ESM規(guī)范落地，在當(dāng)前，至少在開發(fā)環(huán)境中代碼已經(jīng)不需要打包（使用Vite）。

Type Annotations的出現(xiàn)，就是遵循努力去編譯時流程這一趨勢的產(chǎn)物。

從這個角度看，還是很有必要的。

以上就是原生JS以后也支持類型注解意義的詳細(xì)內(nèi)容，更多關(guān)于原生JS支持類型注解的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論