文蔺

浏览器中的 ES6 module 实现

文蔺 · 2017-05-06翻译 · 1782阅读 原文链接

ES6 的模块特性(module) 开始在浏览器端实现啦!一切正在路上...

浏览器 备注
Safari 10.1 (无)
Chrome Canary 60 打开 chrome:flags 启用“实验性网络平台功能”
Firefox 54 打开 about:config 启用 dom.moduleScripts.enabled
Edge 15 打开 about:flags 启用“实验性 JavaScript 功能”
`<script type="module">`
  import {addTextToBody} from './utils.js';

  addTextToBody('Modules are pretty cool.');
</script>
// utils.js
export function addTextToBody(text) {
  const div = document.createElement('div');
  div.textContent = text;
  document.body.appendChild(div);
}

Live demo

只需为 script 元素添加 type=module 属性,浏览器就会把该元素对应的内联脚本或外部脚本当成 ECMAScript 模块进行处理。

目前已经有一些 很棒的关于 ECMAScript 模块的文章了,不过我还是想分享一些和浏览器相关的东西,它们都是我在测试代码、阅读规范的过程中学习到的。

尚未得到支持的 import 路径符号

// 支持
import {foo} from 'https://jakearchibald.com/utils/bar.js';
import {foo} from '/utils/bar.js';
import {foo} from './bar.js';
import {foo} from '../bar.js';

// 不支持
import {foo} from 'bar.js';
import {foo} from 'utils/bar.js';

有效的路径符号应当符合以下条件规则之一:

  • 完整的非相对路径。这样在将其传给new URL(moduleSpecifier)的时候才不会报错。
  • / 开头。
  • ./ 开头。
  • ../ 开头。

其他形式的符号被保留下来,未来将用于其他功能(如引入[import]内置模块)。

使用 nomodule 属性向后兼容

`<script type="module" src="module.js">`</script>
`<script nomodule src="fallback.js">`</script>

Live demo

支持 type=module 的浏览器将会忽略带有 nomodule 属性的 script 标签。这意味着我们可以为支持模块的浏览器提供模块形式的代码,同时为那些不支持模块的浏览器提供降级处理。

浏览器 issue

  • Firefox 暂不支持 nomodule (issue)。
  • Edge 暂不支持 nomodule (issue)。
  • Safari 10.1 暂不支持 nomodule,但在最新的技术预览版中已经解决了此问题。对于 10.1 来说,有一个相当棒的解决方案

默认延迟执行

<!-- 这个脚本会在… -->
`<script type="module" src="1.js">`</script>

<!-- …这个脚本之后、… -->
`<script src="2.js">`</script>

<!-- …这个脚本之前执行。 -->
`<script defer src="3.js">`</script>

Live demo。脚本执行顺序为 2.js, 1.js, 3.js

获取脚本会导致 HTML parser 阻塞,这简直太太太太恶心了。对正常的脚本,我们可以使用 defer 属性来防止阻塞,脚本将延迟至文档解析完毕后执行,同时保持与其他使用 defer 的脚本之间的执行顺序。模块脚本的默认行为与 defer 相同 —— 无法使模块脚本阻塞 HTML parser。

模块脚本与使用 defer 的正常脚本使用相同的执行队列。

内联脚本同样延迟

<!-- 这个脚本会在… -->
`<script type="module">`
  addTextToBody("Inline module executed");
</script>

<!-- …这个脚本… -->
`<script src="1.js">`</script>

<!-- …以及这个脚本之后、… -->
`<script defer>`
  addTextToBody("Inline script executed");
</script>

<!-- …这个脚本之前执行。 -->
`<script defer src="2.js">`</script>

Live demo。执行顺序依次为 1.js、内联脚本、内联模块、2.js

正常的内联脚本会忽略 defer 属性,而内联模块则总是延迟执行,无论是否引入其他内容。

async 对内联、外部模块同样适用

<!-- 脚本将会在其引入的模块加载完成后立即执行 -->
``<script async type="module">``
  import {addTextToBody} from './utils.js';

  addTextToBody('Inline module executed.');
</script>

<!-- 脚本及其引入的模块加载完成后立即执行 -->
``<script async type="module" src="1.js">``</script>

Live demo。先完成加载的脚本先执行。

与正常脚本相同,带有 async 属性的脚本在下载时不会阻塞 HTML parser,一旦加载完毕,立即执行。不同的是,async 对内联模块也同样适用。

使用 async 时,脚本的执行顺序可能会和它们在 DOM 中出现的顺序不尽相同。

浏览器 issue

  • Firefox 不支持内联模块使用 async(issue)。

模块只执行一次

<!-- 1.js 只执行一次 -->
`<script type="module" src="1.js">`</script>
`<script type="module" src="1.js">`</script>
`<script type="module">`
  import "./1.js";
</script>

<!-- 普通脚本会执行多次 -->
`<script src="2.js">`</script>
`<script src="2.js">`</script>

Live demo

引入同一个模块多次的时候,模块只会执行一次。这对 HTML 中的模块脚本同样适用 —— 在同一个页面中,URL 相同的模块只会执行一次。

浏览器 issue

  • Edge 会执行多次 (issue)。

总是使用 CORS

<!-- 模块不会执行,因其未通过 CORS 检查 -->
`<script type="module" src="https://….now.sh/no-cors">`</script>

<!-- 模块不会执行,因其引入的脚本未通过 CORS 检查 -->
`<script type="module">`
  import 'https://….now.sh/no-cors';

  addTextToBody("This will not execute.");
</script>

<!-- CORS 检查通过,模块将会执行 -->
`<script type="module" src="https://….now.sh/cors">`</script>

Live demo

与正常脚本不同,模块脚本(及其引入的脚本)是通过 CORS 获取的。这意味着,跨域模块脚本必须返回类似 Access-Control-Allow-Origin: * 这样的有效的响应头。

浏览器 issue

  • Firefox 无法加载 demo 页面(issue)。
  • Edge 加载了没有 CORS 响应头的模块(issue)。

不携带凭证信息

<!-- 请求脚本时会携带相关凭证 (如 cookie) -->
`<script src="1.js">`</script>

<!-- 不会携带相关凭证 -->
`<script type="module" src="1.js">`</script>

<!-- 会携带相关凭证 -->
`<script type="module" crossorigin src="1.js?">`</script>

<!-- 不会携带相关凭证 -->
`<script type="module" crossorigin src="https://other-origin/1.js">`</script>

<!-- 会携带相关凭证-->
`<script type="module" crossorigin="use-credentials" src="https://other-origin/1.js?">`</script>

Live demo

在请求同源的情况下,多数基于 CORS 的 API 都会发送凭证信息(credentials,如 Cookie)。但 fetch() 和模块脚本恰恰例外 —— 除非手动声明,否则是不会发送相关凭证的。

对于一个同源的模块脚本,可以为其添加 crossorigin 属性(这看起来挺怪的,我已经在规范中提出这个问题了),这样在请求时就可以携带相关凭证了。如果你还想将凭证发给其他域,请使用 crossorigin="use-credentials"。需要注意的是,接收凭证的域必须返回 Access-Control-Allow-Credentials: true 的响应头。

此外,还有一个与“模块只会执行一次”这条规则相关的问题。浏览器是通过 URL 来区别不同模块的,所以如果你先请求了一个模块而不携带任何凭证,紧接着又携带凭证信息去请求该模块,那么第二次得到的依然是不携带凭证的请求所返回的模块。这正是我在上面代码中的 URL 后面加上“?”的原因。

浏览器 issue

  • 请求同源模块时,Chrome 会携带凭证信息(issue)。
  • 即使添加了 crossorigin 属性,Safari 在请求同源脚本时也不会携带凭证信息(issue)。
  • Edge 则完全弄反了。请求同源模块时,Edge 默认会发送凭证信息,但如果手动添加了 crossorigin 属性,则又不会携带 (issue)。

Firefox 是唯一正确实现这一点的浏览器 —— 好样的!

Mime-types

不同于普通脚本,对于通过 module 引入的脚本,服务器必须返回合法的 MIME type,否则脚本将不会执行。

Live demo

浏览器 issue

  • Edge 仍将执行 MIME type 非法的脚本(issue)。

以上就是我目前所学习到的所有内容。浏览器开始支持 ES6 模块,简直太开心啦~

相关文章