更新什么？概況一覽

1、優(yōu)化了 Promise.all 的定義，在 3.7 版本中一些混用 null 或 undefined 的時候的問題已經(jīng)在 3.9 得到了修復(fù)。
2、大大的提高了打包速度，微軟團隊自測的時候 typescript項目的平均編譯時間由 26s 縮短到了 10s 左右。
3、// @ts-expect-error 新注釋的添加
4、在條件語句中檢測未調(diào)用的函數(shù)
5、編輯器提升

• 5.1 在 JavaScript 中 CommonJS 的自動引入
• 5.2 在代碼操作的時候正確的保留換行符
• 5.3 添加快速修復(fù)缺失的函數(shù)返回表達式
• 5.4 支持 "Solution Style" tsconfig.json 文件

6、一些重大變化

主要是在 TypeScript 定義和書寫規(guī)范上的改動和修復(fù)以前的 bugs

挑幾個重點的寫一下

1、interface 的優(yōu)化和 promise.all 使用修復(fù)

我們知道在 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 版本中修復(fù)了這個問題。

1.1 全新的 awaited type

awaited type 主要是對現(xiàn)在的 promise 更好的定義和使用。

預(yù)計在 **`3.9`** 發(fā)布的，結(jié)果微軟又跳票了，可以等下一個版本了。

2、TypeScript 打包編譯等速度提升

這里主要是優(yōu)化了幾個微軟的內(nèi)部項目的性能優(yōu)化，比如:

• Typescript 團隊發(fā)現(xiàn)以前的 Material-ui 與 Styled-Components 等組件會帶來極差的編輯 / 編譯速度后。主要從聯(lián)合類型、交叉類型、條件 判斷的 type 類型以及各種映射 type 類型的性能問題來優(yōu)化。 把相關(guān)的庫編譯時間減少了 40% 左右。
• 根據(jù) Visual Studio Code 團隊提供的建議，我們發(fā)現(xiàn)在執(zhí)行文件重命名時，單是查明哪些導(dǎo)入語句需要更新就要耗去 5 到 10 秒時間。TypeScript 3.9 調(diào)整了內(nèi)部編譯器與語言服務(wù)緩存文件的查找方式，順利解決了這個問題。

詳情可以看看下面這幾個 pull request 的具體優(yōu)化內(nèi)容

https://github.com/microsoft/TypeScript/pull/36576
https://github.com/microsoft/TypeScript/pull/36590
https://github.com/microsoft/TypeScript/pull/36607
https://github.com/microsoft/TypeScript/pull/36622
https://github.com/microsoft/TypeScript/pull/36754
https://github.com/microsoft/TypeScript/pull/36696

4、在條件語句中檢測未調(diào)用的函數(shù)

在 3.7 的時候引入了檢測未調(diào)用函數(shù)錯誤提示，3.9 做了部分優(yōu)化

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語句中的條件?，F(xiàn)在三元條件（即語法）現(xiàn)在也支持此功能。比如 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、編輯器的提升

5.1 CommonJS 的自動補全

新版本的另一項重大改進，是使用 CommonJS 模塊自動導(dǎo)入 JavaScript 文件。
在舊版本中，TypeScript 強制要求用戶無論使用什么文件，都必須以 ECMAScript 的形式導(dǎo)入，例如：

import * as fs from "fs";

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

const fs = require("fs");

TypeScript 現(xiàn)在能夠自動檢測您所使用的導(dǎo)入類型，保證文件樣式簡潔而統(tǒng)一?，F(xiàn)在有了如下自動引入的功能

const { readFile } = require('fs')

5.2 缺失的函數(shù)返回值的自動修復(fù)功能

在某些情況下，我們可能會忘記返回函數(shù)中的最后一條語句的值，尤其是在向箭頭函數(shù)添加大括號時。

// before
let f1 = () => 42

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

6、重大改進！

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

ypeScript 最近實現(xiàn)了對可選鏈操作符的支持，但根據(jù)廣大使用者的反饋，非 null 斷言操作符（?。┑目蛇x鏈（？.）行為不符合直覺。

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

foo?.bar!.baz

被解釋為等效于以下 JavaScript 代碼：

(foo?.bar).baz

在以上代碼中，括號會阻止可選鏈的“短路”行為；因此如果未定義 foo 為 undefined，則訪問 baz 會引發(fā)運行時錯誤。

換句話說，大多數(shù)人認為以上原始代碼片段應(yīng)該被解釋為在：

foo?.bar.baz

中，當 foo 為 undefined 時，計算結(jié)果為 undefined。

這是一項重大變化，但我們認為大部分代碼在編寫時都是為了考慮新的解釋場景。如果您希望繼續(xù)使用舊有行為，則可在！操作符左側(cè)添加括號，如下所示：

(foo?.bar)!.baz

參考

https://www.typescriptlang.org/docs/home.html

到此這篇關(guān)于Typescript3.9 常用新特性一覽(推薦)的文章就介紹到這了,更多相關(guān)Typescript3.9 新特性內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！ 

最新評論