【TS 演化史 -- 14】拼寫校訂和動態導入表達式

時間 2020-02-07

標籤 TS 演化史 -- 14 拼寫校訂動態導入表達式简体版

原文原文鏈接

做者：Marius Schulz
譯者：前端小智
來源： https://mariusschulz.com/

點贊再看，養成習慣
本文 GitHub https://github.com/qq44924588... 上已經收錄，更多往期高贊文章的分類，也整理了不少個人文檔，和教程資料。歡迎Star和完善，你們面試能夠參照考點複習，但願咱們一塊兒有點東西。html

TypeScript 2.4 爲標識符實現了拼寫糾正機制。即便我們稍微拼錯了一個變量、屬性或函數名，TypeScript 在不少狀況下均可以提示正確的拼寫。前端

拼寫更正

假設我們想要調用window.location.reload()來從新加載當前頁面。但不當心把location寫成了locatoin或其餘一些拼寫錯誤，TypeScript 會提示正確的拼寫並提供快速修復。jquery

此更正機制對於一般拼寫錯誤的名稱特別有用。以單詞"referrer"爲例，對於
document.referrer 我們有時候會寫成以下的錯誤拼寫：webpack

document.referrerer
document.referrawr
document.refferrrr

TypeScript 將識別全部這些拼寫錯誤，並提示document.referrer爲正確的拼寫。它甚至還能夠提供如下幾種選擇：git

document.referrerer
document.referrawr
document.refferrrr

固然，若是我們只是輸入document.ref，而後按TAB或ENTER鍵讓TypeScript爲我們補全，則不須要拼寫建議，可是若是本身快速輸入整個屬性名稱，則可能會拼錯。github

編輯距離 (Levenshtein Distance算法)

在內部，TypeScript 計算拼寫錯誤的名稱和程序中該位置可用的名稱列表中每一個候選項之間的編輯距離。最佳匹配後(若是有的話)將做爲拼寫提示返回。web

該算法在 TypeScript 編譯器的checker.ts文件中的getSpellingSuggestionForName函數中實現，以下所示面試

/**
 * Given a name and a list of symbols whose names are *not* equal to the name, return a spelling suggestion if there is one that is close enough.
 * Names less than length 3 only check for case-insensitive equality, not levenshtein distance.
 *
 * If there is a candidate that's the same except for case, return that.
 * If there is a candidate that's within one edit of the name, return that.
 * Otherwise, return the candidate with the smallest Levenshtein distance,
 *    except for candidates:
 *      * With no name
 *      * Whose meaning doesn't match the `meaning` parameter.
 *      * Whose length differs from the target name by more than 0.34 of the length of the name.
 *      * Whose levenshtein distance is more than 0.4 of the length of the name
 *        (0.4 allows 1 substitution/transposition for every 5 characters,
 *         and 1 insertion/deletion at 3 characters)
 */
function getSpellingSuggestionForName(name: string, symbols: Symbol[], meaning: SymbolFlags): Symbol | undefined {
    const maximumLengthDifference = Math.min(2, Math.floor(name.length * 0.34));
    let bestDistance = Math.floor(name.length * 0.4) + 1; // If the best result isn't better than this, don't bother.
    let bestCandidate: Symbol | undefined;
    let justCheckExactMatches = false;
    const nameLowerCase = name.toLowerCase();
    for (const candidate of symbols) {
        const candidateName = symbolName(candidate);
        if (!(candidate.flags & meaning && Math.abs(candidateName.length - nameLowerCase.length) <= maximumLengthDifference)) {
            continue;
        }
        const candidateNameLowerCase = candidateName.toLowerCase();
        if (candidateNameLowerCase === nameLowerCase) {
            return candidate;
        }
        if (justCheckExactMatches) {
            continue;
        }
        if (candidateName.length < 3) {
            // Don't bother, user would have noticed a 2-character name having an extra character
            continue;
        }
        // Only care about a result better than the best so far.
        const distance = levenshteinWithMax(nameLowerCase, candidateNameLowerCase, bestDistance - 1);
        if (distance === undefined) {
            continue;
        }
        if (distance < 3) {
            justCheckExactMatches = true;
            bestCandidate = candidate;
        }
        else {
            Debug.assert(distance < bestDistance); // Else `levenshteinWithMax` should return undefined
            bestDistance = distance;
            bestCandidate = candidate;
        }
    }
    return bestCandidate;
}

getSpellingSuggestionForName使用大量試探法來產生合理的拼寫建議，該建議既不太嚴格也不太寬鬆，這是一個有趣的平衡點！算法

編輯距離 (Levenshtein Distance算法)
字符串的編輯距離，又稱爲Levenshtein距離，由俄羅斯的數學家Vladimir Levenshtein在1965年提出。是指利用字符操做，把字符串A轉換成字符串B所須要的最少操做數。其中，字符操做包括：typescript

刪除一個字符
插入一個字符
修改一個字符

例如對於字符串"if"和"iff"，能夠經過插入一個'f'或者刪除一個'f'來達到目的。

通常來講，兩個字符串的編輯距離越小，則它們越類似。若是兩個字符串相等，則它們的編輯距離（爲了方便，本文後續出現的「距離」，若是沒有特別說明，則默認爲「編輯距離」）爲0（不須要任何操做）。不難分析出，兩個字符串的編輯距離確定不超過它們的最大長度（能夠經過先把短串的每一位都修改爲長串對應位置的字符，而後插入長串中的剩下字符）。

動態導入表達式

TypeScript 2.4 添加了對動態import()表達式的支持，容許用戶在程序的任何位置異步地請求某個模塊。

靜態導入模塊

我們先從靜態導入模塊開始，而後看看我們須要動態導入的狀況。假設我們已經爲一些客戶端小部件編寫了一個widget.ts模塊：

import * as $ from "jquery";

export function render(container: HTMLElement) {
  $(container).text("Hello, World!");
}

我們的小部件須要 jQuery，所以從jquery npm包中導入$。請注意，我們在第1行中使用的是徹底靜態的導入聲明，而不是動態的import()表達式。

如今，我們切換到main.ts模塊，並假設我們要將小部件呈現到特定的<div>容器中。若是打到 DOM 剛渲染，不然不渲染。

import * as widget from "./widget";

function renderWidget() {
  const container = document.getElementById("widget");
  if (container !== null) {
    widget.render(container);
  }
}

renderWidget();

若是如今使用webpack或Rollup之類的工具將main.ts做爲輸入模塊捆綁應用程序，則生成的JS 捆綁包（處於未縮小狀態）的長度超過10,000行。這是由於在widget.ts模塊中，須要要導入很大的jquery npm 包。

問題在於，即便不渲染該窗口小部件，我們也要導入其窗口小部件及其全部依賴項。新用戶第一次打開我們的Web應用程序時，其瀏覽器必須下載並解析大量無效代碼。這對於具備不穩定網絡鏈接，低帶寬和有限處理能力的移動設備尤爲不利。

接着來看看動態的 import() 如何解決這個問題。

動態導入模塊

更好的方法是僅在須要時導入小部件模塊。可是，ES6 導入聲明是徹底靜態的，必須位於文件的頂層，這意味着我們不能將它們嵌套在if語句中，以便有條件地導入模塊。這就是動態import()出現的緣由。

在main.ts模塊中，刪除文件頂部的import聲明，並使用import()表達式動態加載小部件，但前提是我們確實找到了小部件容器：

function renderWidget() {
  const container = document.getElementById("widget");
  if (container !== null) {
    import("./widget").then(widget => {
      widget.render(container);
    });
  }
}

renderWidget();

因爲按需獲取 ECMAScript 模塊是異步操做，所以import()表達式始終返回promise。

將 await 運算符與 `import()` 一塊兒使用

進行一些重構，以使renderWidget函數的嵌套更少，從而更易於閱讀。由於import()返回一個普通的ES2015 Promise（具備.then()方法），因此我們可使用await運算符來等待Promise解析：

async function renderWidget() {
  const container = document.getElementById("widget");
  if (container !== null) {
    const widget = await import("./widget");
    widget.render(container);
  }
}

renderWidget();

清晰明瞭，不要忘記經過在其聲明中添加async關鍵字來使renderWidget函數異步化。

針對各類模塊系統

TypeScript 編譯器支持各類 JS 模塊系統，例如 ES2015，CommonJS 或 AMD。根據目標模塊系統的不一樣，爲 import() 表達式生成的 JS 代碼將大不相同。

若是我們使用--module esnext編譯我們的 TypeScript 應用程序，將生成如下 JS 代碼。它幾乎與咱們本身編寫的代碼相同：

"use strict";
function renderWidget() {
  var container = document.getElementById("widget");
  if (container !== null) {
    var widget = import("./widget").then(function(widget) {
      widget.render(container);
    });
  }
}
renderWidget();

注意import()表達式沒有以任何方式進行轉換。若是我們在這個模塊中使用了任何import或export聲明，那麼它們也不會受到影響。

將此代碼與如下代碼進行比較，當我們使用--module commonjs編譯應用程序時，會生成如下代碼（爲了便於閱讀，還有一些換行符）：

"use strict";
function renderWidget() {
  var container = document.getElementById("widget");
  if (container !== null) {
    var widget = Promise.resolve()
      .then(function() {
        return require("./widget");
      })
      .then(function(widget) {
        widget.render(container);
      });
  }
}
renderWidget();

CommonJS 對於 Node 應用程序將是一個不錯的選擇。全部import()表達式都將轉換爲require()調用，這些調用能夠在程序中的任意位置有條件地執行，而沒必要事先加載，解析和執行模塊。

那麼，在使用import()按需延遲加載模塊的客戶端web應用程序中，應該針對哪一個模塊系統呢?我建議將——module esnext與 webpack 的代碼分割特性結合使用。檢查帶有import()和webpack的TypeScript 應用程序的代碼分解，以進行演示應用程序設置。

代碼部署後可能存在的BUG無法實時知道，過後爲了解決這些BUG，花了大量的時間進行log 調試，這邊順便給你們推薦一個好用的BUG監控工具 Fundebug。

原文：
https://mariusschulz.com/blog...
https://mariusschulz.com/blog...
https://www.tslang.cn/docs/re...

交流

文章每週持續更新，能夠微信搜索「大遷世界」第一時間閱讀和催更（比博客早一到兩篇喲），本文 GitHub https://github.com/qq449245884/xiaozhi 已經收錄，整理了不少個人文檔，歡迎Star和完善，你們面試能夠參照考點複習，另外關注公衆號，後臺回覆福利，便可看到福利，你懂的。