【譯】Typescript 3.9 經常使用新特性一覽

Typescript 3.9 新特性一覽

• 好消息好消息，3.9 正式版本發佈了

相關文章導航

• Typescript 3.7 經常使用新特性一覽
• Typescript 3.8 經常使用新特性一覽
• Typescript 3.9 經常使用新特性一覽

更新什麼？概況一覽

• 一、優化了 Promise.all 的定義，在 3.7 版本中一些混用 null 或 undefined 的時候的問題已經在 3.9 獲得了修復。
• 二、大大的提升了打包速度，微軟團隊自測的時候 typescript項目的平均編譯時間由 26s 縮短到了 10s 左右。
• 三、// @ts-expect-error 新註釋的添加
• 四、在條件語句中檢測未調用的函數
• 五、編輯器提高
  • 5.1 在 JavaScript 中 CommonJS 的自動引入
  • 5.2 在代碼操做的時候正確的保留換行符
  • 5.3 添加快速修復缺失的函數返回表達式
  • 5.4 支持 "Solution Style" tsconfig.json 文件
• 六、一些重大變化
  • 主要是在 TypeScript 定義和書寫規範上的改動和修復之前的 bugs

挑幾個重點的寫一下

一、interface 的優化和 promise.all 使用修復

• 咱們知道在 3.7 版本後面對 promise.all & promise.race 等方法作出了更新，可是也製造出了一個問題。在使用 null & undefined 尤爲明顯。

nterface Lion {

    roar(): void

}

interface Seal {

    singKissFromARose(): void

}

async function visitZoo(lionExhibit: Promise<Lion>, sealExhibit: Promise<Seal | undefined>) {

    let [lion, seal] = await Promise.all([lionExhibit, sealExhibit]);

    lion.roar(); // uh oh

// ~~~~

// Object is possibly 'undefined'.

}
複製代碼

這種行爲就很奇怪了，實際上 sealExhibit 當中包含的 undefined，至關因而把 undefined 錯誤引入了 lion type 當中, 這裏是一個錯誤引用。

固然在最新的 3.9 版本中修復了這個問題。

1.1 全新的 awaited type

• awaited type 主要是對如今的 promise 更好的定義和使用。

預計在 **`3.9`** 發佈的，結果微軟又跳票了，能夠等下一個版本了。

二、TypeScript 打包編譯等速度提高

• 這裏主要是優化了幾個微軟的內部項目的性能優化，好比:
  • Typescript 團隊發現之前的 Material-ui 與 Styled-Components 等組件會帶來極差的編輯 / 編譯速度後。主要從聯合類型、交叉類型、條件 判斷的 type 類型以及各類映射 type 類型的性能問題來優化。 把相關的庫編譯時間減小了 40% 左右。
  • 根據 Visual Studio Code 團隊提供的建議，咱們發如今執行文件重命名時，單是查明哪些導入語句須要更新就要耗去 5 到 10 秒時間。TypeScript 3.9 調整了內部編譯器與語言服務緩存文件的查找方式，順利解決了這個問題。
• 詳情能夠看看下面這幾個 pull request 的具體優化內容
  • github.com/microsoft/T…
  • github.com/microsoft/T…
  • github.com/microsoft/T…
  • github.com/microsoft/T…
  • github.com/microsoft/T…
  • github.com/microsoft/T…

四、在條件語句中檢測未調用的函數

• 在 3.7 的時候引入了檢測未調用函數錯誤提示，3.9 作了部分優化

function hasImportantPermissions(): boolean {
    // ...
}

// Oops!
if (hasImportantPermissions) {
// ~~~~~~~~~~~~~~~~~~~~~~~
// This condition will always return true since the function is always defined.
// Did you mean to call it instead?
    deleteAllTheImportantFiles();
}
複製代碼

可是，此錯誤僅適用於if語句中的條件。如今三元條件（即語法）如今也支持此功能。好比 cond ? trueExpr : falseExpr

declare function listFilesOfDirectory(dirPath: string): string[];
declare function isDirectory(): boolean;

function getAllFiles(startFileName: string) {
    const result: string[] = [];
    traverse(startFileName);
    return result;

    function traverse(currentPath: string) {
        return isDirectory ?
        // ~~~~~~~~~~~
        // This condition will always return true
        // since the function is always defined.
        // Did you mean to call it instead?
            listFilesOfDirectory(currentPath).forEach(traverse) :
            result.push(currentPath);
    }
}
複製代碼

五、編輯器的提高

5.1 CommonJS 的自動補全

• 新版本的另外一項重大改進，是使用 CommonJS 模塊自動導入 JavaScript 文件。
• 在舊版本中，TypeScript 強制要求用戶不管使用什麼文件，都必須以 ECMAScript 的形式導入，例如：

import * as fs from "fs";
複製代碼

• 但在編寫 JavaScript 文件時，不少用戶並不打算使用 ECMScript 樣式模塊。很多朋友仍在使用 CommonJS 樣式的 require(...) 導入，例如：

const fs = require("fs");
複製代碼

TypeScript 如今可以自動檢測您所使用的導入類型，保證文件樣式簡潔而統一。如今有了以下自動引入的功能

const { readFile } = require('fs')
複製代碼

5.2 缺失的函數返回值的自動修復功能

• 在某些狀況下，咱們可能會忘記返回函數中的最後一條語句的值，尤爲是在向箭頭函數添加大括號時。

// before
let f1 = () => 42

// oops - not the same!
let f2 = () => { 42 }
複製代碼

六、重大改進！

6.1 解析可選鏈與非 null 斷言中的差別

• ypeScript 最近實現了對可選鏈操做符的支持，但根據廣大使用者的反饋，非 null 斷言操做符（！）的可選鏈（？.）行爲不符合直覺。

具體來說，在以往的版本中，代碼：

foo?.bar!.baz
複製代碼

被解釋爲等效於如下 JavaScript 代碼：

(foo?.bar).baz
複製代碼

在以上代碼中，括號會阻止可選鏈的「短路」行爲；所以若是未定義 foo 爲 undefined，則訪問 baz 會引起運行時錯誤。

換句話說，大多數人認爲以上原始代碼片斷應該被解釋爲在：

foo?.bar.baz
複製代碼

中，當 foo 爲 undefined 時，計算結果爲 undefined。

這是一項重大變化，但咱們認爲大部分代碼在編寫時都是爲了考慮新的解釋場景。若是您但願繼續使用舊有行爲，則可在！操做符左側添加括號，以下所示：

(foo?.bar)!.baz

參考

• www.typescriptlang.org/docs/handbo…