关于javascript:为什么需要在-JavaScript-中使用顶层-await

3次阅读

共计 6115 个字符，预计需要花费 16 分钟才能阅读完成。

原文地址：Why Should You Use Top-level Await in JavaScript?

原文作者：Mahdhi Rezvi

译者：Chor

作为一门非常灵活和弱小的语言，JavaScript 对古代 web 产生了深远的影响。它之所以可能在 web 开发中占据主导地位，其中一个次要起因就是频繁更新所带来的继续改良。

顶层 await（top-level await）是近年来提案中波及的新个性。该个性能够让 ES 模块对外体现为一个 async 函数，容许 ES 模块去 await 数据并阻塞其它导入这些数据的模块。只有在数据确定并筹备好的时候，导入数据的模块才能够执行相应的代码。

无关该个性的提案目前仍处于 stage 3 阶段，因而咱们不能间接在生产环境中应用。但鉴于它将在不久的将来推出，提前理解一下还是大有益处的。

听起来一头雾水没关系，持续往下浏览，我会和你一起搞定这个新个性的。

在引入顶层 await 之前，如果你试图在一个 async 函数里面应用 await 关键字，将会引起语法错误。为了防止这个问题，开发者通常会应用立刻执行函数表达式（IIFE）

await Promise.resolve(console.log('❤️'));
// 报错

(async () => {await Promise.resolve(console.log('❤️'));
  //❤️
})();

在应用 ES6 模块化的时候，常常会遇到须要导入导出的场景。看看上面这个例子：

//------ library.js ------
export const sqrt = Math.sqrt;
export function square(x) {return x * x;}
export function diagonal(x, y) {return sqrt(square(x) + square(y));
}


//------ middleware.js ------
import {square, diagonal} from './library.js';

console.log('From Middleware');

let squareOutput;
let diagonalOutput;

// IIFE
 (async () => {await delay(1000);
     squareOutput = square(13);
     diagonalOutput = diagonal(12, 5);
 })();

function delay(delayInms) {
  return new Promise(resolve => {setTimeout(() => {resolve(console.log('❤️'));
    }, delayInms);
  });
}

export {squareOutput,diagonalOutput};

在这个例子中，咱们在 library.js 和 middleware.js 之间进行变量的导入导出（文件名随便，这里不是重点）

如果仔细阅读，你会留神到有一个 delay 函数，它返回的 Promise 会在计时完结之后被 resolve。因为这是一个异步操作（在实在的业务场景中，这里可能会是一个 fetch 调用或者某个异步工作），咱们在 async IIFE 中应用 await 以期待其执行后果。一旦 promise 被 resolve，咱们会执行从 library.js 中导入的函数，并将计算失去的后果赋值给两个变量。这意味着，在 promise 被 resolve 之前，两个变量都会是 undefined。

在代码最初面，咱们将计算失去的两个变量导出，供另一个模块应用。

上面这个模块负责导入并应用上述两个变量：

//------ main.js ------
import {squareOutput, diagonalOutput} from './middleware.js';

console.log(squareOutput); // undefined
console.log(diagonalOutput); // undefined
console.log('From Main');

setTimeout(() => console.log(squareOutput), 2000);
//169

setTimeout(() => console.log(diagonalOutput), 2000);
//13

运行下面代码，你会发现前两次打印失去的都是 undefined，后两次打印失去的是 169 和 13。为什么会这样呢？

这是因为，在 async 函数执行结束之前，main.js 就曾经拜访了 middleware.js 导出的变量。记得吗？咱们后面还有一个 promise 期待被 resolve 呢 ……

为了解决这个问题，咱们须要想方法告诉模块，让它在筹备好拜访变量的时候再将变量导入。

针对上述问题，有两个宽泛应用的解决方案：

1. 导出一个 Promise 示意初始化

你能够导出一个 IIFE 并依附它确定能够拜访导出后果的机会。async 关键字能够异步化一个办法，并相应返回一个 promise。因而，上面的代码中，async IIFE 会返回一个 promise。

//------ middleware.js ------
import {square, diagonal} from './library.js';

console.log('From Middleware');

let squareOutput;
let diagonalOutput;

// 解决方案
export default (async () => {await delay(1000);
    squareOutput = square(13);
    diagonalOutput = diagonal(12, 5);
})();

function delay(delayInms) {
  return new Promise(resolve => {setTimeout(() => {resolve(console.log('❤️'));
    }, delayInms);
  });
}

export {squareOutput,diagonalOutput};

当你在 main.js 中拜访导出后果的时候，你能够静待 async IIFE 被 resolve，之后再去拜访变量。

//------ main.js ------
import promise, {squareOutput, diagonalOutput} from './middleware.js';

promise.then(()=>{console.log(squareOutput); // 169
     console.log(diagonalOutput); // 13
     console.log('From Main');

     setTimeout(() => console.log(squareOutput), 2000);// 169

     setTimeout(() => console.log(diagonalOutput), 2000);// 13
})

只管这个计划能够失效，但它也引入了新的问题：

大家都必须将这种模式作为规范去遵循，而且必须要找到并期待适合的 promise；
假使有另一个模块依赖 main.js 中的变量 squareOutput 和 diagonalOutput，那么咱们就须要再次书写相似的 IIFE promise 并导出，从而让另一个模块得以正确地拜访变量。

为了解决这两个新问题，第二个计划应运而生。

2. 用导出的变量去 resolve IIFE promise

在这个计划中，咱们不再像之前那样独自导出变量，而是将变量作为 async IIFE 的返回值返回。这样的话，main.js 只需简略地期待 promise 被 resolve，之后间接获取变量即可。

//------ middleware.js ------
import {square, diagonal} from './library.js';

console.log('From Middleware');

let squareOutput;
let diagonalOutput;

export default (async () => {await delay(1000);
    squareOutput = square(13);
    diagonalOutput = diagonal(12, 5);
    return {squareOutput,diagonalOutput};
})();

function delay(delayInms) {
  return new Promise(resolve => {setTimeout(() => {resolve(console.log('❤️'));
    }, delayInms);
  });
}

//------ main.js ------

import promise from './middleware.js';

promise.then(({squareOutput,diagonalOutput})=>{console.log(squareOutput); // 169
    console.log(diagonalOutput); // 13
    console.log('From Main');

    setTimeout(() => console.log(squareOutput), 2000);// 169

    setTimeout(() => console.log(diagonalOutput), 2000);// 13
})

但这个计划有其本身的复杂性存在。

依据提案的说法，“这种模式的不良影响在于，它要求对相干数据进行大规模重构以应用动静模式；同时，它将模块的大部分内容放在 .then() 的回调函数中，以应用动静导入。从动态剖析、可测试性、工程学以及其它角度来讲，这种做法相比 ES2015 的模块化来说是一种不言而喻的倒退”。

顶层 await 容许咱们让模块零碎去解决 promise 之间的协调关系，从而让咱们这边的工作变得异样简略。

//------ middleware.js ------
import {square, diagonal} from './library.js';

console.log('From Middleware');

let squareOutput;
let diagonalOutput;

// 应用顶层 await 
await delay(1000);
squareOutput = square(13);
diagonalOutput = diagonal(12, 5);

function delay(delayInms) {
  return new Promise(resolve => {setTimeout(() => {resolve(console.log('❤️'));
    }, delayInms);
  });
}

export {squareOutput,diagonalOutput};

//------ main.js ------
import {squareOutput, diagonalOutput} from './middleware.js';

console.log(squareOutput); // 169
console.log(diagonalOutput); // 13
console.log('From Main');

setTimeout(() => console.log(squareOutput), 2000);// 169

setTimeout(() => console.log(diagonalOutput), 2000); // 13

在 middleware.js 中的 await promise 被 resolve 之前，main.js 中任意一条语句都不会执行。与之前提及的解决方案相比，这个办法要简洁得多。

必须留神的是，顶层 await 只在 ES 模块中失效。 此外，你必须要显式申明模块之间的依赖关系，能力让顶层 await 像预期那样失效。提案仓库中的这段代码就很好地阐明了这个问题：

// x.mjs
console.log("X1");
await new Promise(r => setTimeout(r, 1000));
console.log("X2");
// y.mjs
console.log("Y");
// z.mjs
import "./x.mjs";
import "./y.mjs";
//X1
//Y
//X2

这段代码打印的程序并不是料想中的 X1,X2,Y。这是因为 x 和 y 是独立的模块，相互之间没有依赖关系。

举荐你浏览一下文档问答，这样会对这个顶层 await 这个新个性有更加全面的理解。

你能够依照文档所说的，尝试应用顶层 await 个性。

我应用的是 V8 的办法。找到你电脑上 Chrome 浏览器的装置地位，确保敞开浏览器的所有过程，关上命令行运行如下命令：

chrome.exe --js-flags="--harmony-top-level-await"

这样，Chrome 从新关上后将开启对于顶层 await 个性的反对。

当然，你也能够在 Node 环境测试。浏览这个指南获取更多细节。

确保在 script 标签中申明该属性：type="module"

<script type="module" src="./index.js" >
</script>

须要留神的是，和一般脚本不一样，申明模块化之后的脚本会受到 CORS 策略的影响，因而你须要通过服务器关上该文件。

以下是提案中讲到的相干用例：

const strings = await import(`/i18n/${navigator.language}`);

容许模块应用运行时的值去计算失去依赖关系。这对生产 / 开发环境的辨别以及国际化工作等十分无效。

const connection = await dbConnector();

这有助于把模块看作某种资源，同时能够在模块不存在的时候抛出谬误。谬误能够在上面介绍的后备计划中失去解决。

上面的例子展现了如何用顶层 await 去加载带有后备计划的依赖。如果 CDN A 无奈导入 jQuery，那么会尝试从 CDN B 中导入。

let jQuery;
try {jQuery = await import('https://cdn-a.example.com/jQuery');
} catch {jQuery = await import('https://cdn-b.example.com/jQuery');
}

针对顶层 await 的个性，Rich Harris 提出了不少鞭挞性的问题：

顶层 await 会阻塞代码的执行
顶层 await 会阻塞资源的获取
CommonJS 模块没有明确的互操作计划

而 stage 3 的提案曾经间接解决了这些问题：

因为兄弟模块可能执行，所以不存在阻塞；
顶层 await 在模块图的执行阶段发挥作用，此时所有的资源都曾经获取并链接了，因而不存在资源被阻塞的危险；
顶层 await 只限于在 ES6 模块中应用，自身就不打算反对一般脚本或者 CommonJS 模块

我强烈推荐各位读者浏览提案的 FAQ 来加深对这个新个性的了解。

看到这里，想必你对这个酷炫的新个性曾经有了肯定的理解。是不是曾经急不可待要应用看看了呢？在评论区留言一起交换吧。

正文完

javascript

发表至： javascript

2021-01-29

0

关于javascript:深入13-观察者-发布订阅-双向数据绑定

纯django开发企业个人博客系统可以当成企业个人官网或博客特别适合自媒体人的自媒体官文网站

关于javascript:Leetcode34在排序数组中查找元素的第一个和最后一个位置二分法求解

关于javascript:前端面试每日-31-第929天

关于前端:还不知道简历如何写就该这样写

关于javascript:为什么需要在-JavaScript-中使用顶层-await

以前的写法，问题在哪里？

然而这只是冰山一角

解决方案

顶层 Await 是如何解决上述问题的？

留神

试用

V8

ES 模块

利用场景

动静的依赖门路

资源初始化

依赖的后备计划

鞭挞

站内搜索