具备基本工程素养的同学都会注重编码规范，而代码风格检查（Code Linting，简称 Lint）是保障代码规范一致性的重要手段，你的工作流中有 Lint 环节么？有的话你用的爽么？你在团队中推广过 Lint，但是大家都不买账？究竟是为啥？

Lint 是什么？

探讨怎么做之前，我们很有必要给 Lint 来个清晰、准确的定义，wikipedia 的定义如下：

In computer programming, lint is a Unix utility that flags some suspicious and non-portable constructs (likely to be bugs) in C language source code; generically, lint or a linter is any tool that flags suspicious usage in software written in any computer language. The term lint-like behavior is sometimes applied to the process of flagging suspicious language usage. Lint-like tools generally perform static analysis of source code.

简单来说，Lint 就是对代码做静态分析，并试图找出潜在问题的工具，实战中我们也用 Lint 来指使用工具的过程。

为什么要 Lint？

使用 Lint 会有什么好处呢？在我看来至少具有如下 3 点：

• 更少的 Bug，剑桥大学的研究发现，全世界每年因为软 Bug 造成的经济损失约 3120 亿美金；

• 更高的开发效率，工程师平均会花掉 50% 的工作时间定位和解决各种 Bug，其中不乏那些显而易见的低级错误，而 Lint 很容易发现低级的、显而易见的错误；

• 更高的可读性，代码可读性的首要因子是“表面文章”，表面上看起来乱糟糟的代码通常更难读懂；

可以毫不客气的说，如果你不做 Lint，就是在浪费自己的时间，浪费公司的资源。既然做 Lint 的预期效果很好？该怎么做呢？

提交后 Lint：反馈链条太长？

说到怎么做，多数人会自然而然的想到各种 Lint 工具，目前社区中针对各种语言都开发了 Lint 工具，前端能用到的就有大把：ESLint、Standard、SCSSLint、JSONLint、HTMLHint 等。GitHub 官方出品的 Lint 工具列表 也是个非常不错的参考。

很多同学选择在持续集成阶段（后文用 CI 代称）做 Lint，比如使用远程的 Git Hooks 来触发。但是从实际的经历来看，这种做法的反馈链条通常如下：

代码提交 --> 发现问题(远程) --> 修复问题 --> 重新提交 --> 通过检查(远程)

整个过程可能会浪费掉你不少时间，毕竟 CI 过程通常不仅是在做 Lint，如果你是那种不知道自己时间每天都去哪儿了的工程师，可以反思下自己或者团队的工作流是否是这样。并且，请相信我，你不是少数人。

你有没有这样的经历：吭哧吭哧写了几天代码，各种验收都通过了，最后被 CI 拒绝，竟是因为你的代码中少加了一个逗号，这时候心情简直崩溃到无法形容：

从 GitHub 上各种修复 Lint 的提交数量不难发现工程师在修复 Lint 问题上浪费的时间，比如搜索 "fix lint"，多达 45W 次提交：

再比如搜索 “fix indent”，多达 226W 次提交，是不是很触目惊心？

只在 CI 流程做 Lint 的缺点也是显而易见的：

• Lint 在整个开发工作流中的反馈链条太长，浪费时间、注意力和资源，最致命的；

• CI 流程搭建成本比较高，即使有各种 CI 服务，步骤也还是比较繁琐；

我们该怎么改进？

提交前 Lint：错误信息不相关？

为了缩短 Lint 的反馈链条，把 Lint 挪到本地是最有效的办法。常见做法是使用 husky 或者 pre-commit 在本地提交之前做 Lint。

使用 husky 的具体做法如下：

首先，安装依赖：

npm install -D husky
yarn add --dev husky

然后修改 package.json，增加配置：

{
  "scripts": {
    "precommit": "eslint src/**/*.js"
  }
}

最后尝试 Git 提交，你就会很快收到反馈：

git commit -m "Keep calm and commit"

但是在遗留代码仓库上工作的同学很快会遇到新的问题，开启 Lint 初期，你可能会面临成千上万的 Lint Error 需要修复。部分同学对下面这个图可能并不陌生：只改了文件 A，但是文件 B、C、D 中也有大量错误。

把整个仓库都格式化不失为一种选择，但是实际上需要很大的勇气。多数人在项目中运用新工具都希望是渐进式的，而不是推到重来式的，因为相比而言，业务系统稳定是更重要的事情。简单的把 Lint 挪到本地，反馈链条是缩短了，但是面对每次改动，工具还是给出了太多不相关的信息，这无疑与小步快跑的互联网节奏是相违背的。

该怎么破？

只 Lint 改动的：66666

如果把 Lint 挪到本地，并且每次提交只检查本次提交所修改的文件，上面的痛点就都解决了。Feedly 的工程师 Andrey Okonetchnikov 开发的 lint-staged 就是基于这个想法，其中 staged 是 Git 里面的概念，指待提交区，使用 git commit -a，或者先 git add 然后 git commit 的时候，你的修改代码都会经过待提交区。

lint-staged 用法如下：

首先，安装依赖：

npm install -D lint-staged
yarn add --dev lint-staged

然后，修改 package.json 配置：

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": "eslint"
  }
}

最后，尝试提交的效果：

实际上，lint-staged 给了你提交前代码操作的更大自由度，比如使用下面的配置，自动修复错误：

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["eslint --fix", "git add"]
  }
}

或者使用下面的配置，自动格式化代码（谨慎使用）：

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "src/**/*.js": ["prettier --write", "git add"]
  }
}

此外，lint-staged 和 prettier 已经集成到 create-react-app 中了。你是不是也应该好好打磨下自己的 Lint 工作流了？

总结

有人说前端攻城狮是世界上最奇怪的动物，提交代码时用 prettier 把代码排版的很美观，但部署上线时又使用 uglify 把代码压缩的连亲妈都不认了，事实是，如果我们写出来的代码本来就很丑陋，就根本不需要用 uglify。希望读到这里的你能把 Lint 工作流打磨到极致，把更多时间专注在解决真正的问题上，成为真正高效的工程师。

One More Thing

本文作者王仕军，商业转载请联系作者获得授权，非商业转载请注明出处。如果你觉得本文对你有帮助，请点赞！如果对文中的内容有任何疑问，欢迎留言讨论。想知道我接下来会写些什么？欢迎订阅我的掘金专栏或知乎专栏：《前端周刊：让你在前端领域跟上时代的脚步》。

以下会涉及到的技术点：react mobx compositionstart compositionupdate compositionend

问题描述

在使用 input 时，通常会对输入的内容做校验，校验的方式无非两种：

1. 允许用户输入，并且做错误提示；
2. 不允许用户输入正则或者函数匹配到的字符。

现有如下需求：“仅允许输入英文、数字和汉字，不允许输入其他特殊字符和符号”。显然这种场景需要使用第二种校验方式。

然后我自以为很机智的写了下面的代码（引入了组件库 cloud-react），在输入值变化的时候（onChange 事件），处理绑定到 input 上的 value，将除了英文、数字、和汉字之外的字符都替换成空字符串。

export default class CompositionDemo extends Component {
  constructor() {
     this.state = {
       value: ''
     };
  }
  
  onChange(evt) {
     this.setState({
       value: evt.target.value.replace(/[^a-zA-Z0-9\u4E00-\u9FA5]/g, '')
     });
  };
  
  render() {
    return <Input
        onChange={this.onChange.bind(this)}
          value={this.state.value}
       />
  }
}

平平常常，普普通通，一切看起来都是正常的操作，结果，当我输入拼音的时候，神奇的事情发生了：连拼的时候除了最后一个字，前面的都变成了字符。

what??? 小问号，你是否有很多朋友？

于是，我踏上了一条不归路，呸呸呸，是打开了新世界的大门，就是这个门对于我来说可能有点沉，推了两天才看到新世界。

纠其原因：拼音输入是一个过程，确切的说，在这个过程中，你输入的每一个字母都触发了 onChange 事件，而你输入过程中的这个产物在校验中被吃掉了，留下了一坨空字符串，所以就发生了上面那个神奇的现象。

解决方案

这里需要用到两个属性：

compositionstart

compositionend

简单点来说，就是当你开始使用输入法进行新的输入的时候，会触发 compositionstart ，中间过程其实也有一个函数 compositionupdate，顾名思义，输入更新时会触发它；当结束输入法输入的时候，会触发 compositionend。

下面进入正题：

首先，我们先看一下 Input 组件的一个很正常的实现：

import React, { Component } from 'react';
import PropTypes from 'prop-types';

export default class InputDemo1 extends Component {

    constructor(props) {
        super(props);
        this.state = {
            value: '',
        };
    }
    static getDerivedStateFromProps({ value }, { value: preValue }) {
        if (value !== preValue) {
            return { value };
        }
        return null;
    }

    onChange = evt => {
        this.props.onChange(evt);
    };

    render() {
        return <input
            value={this.state.value}
            type="text"
            onChange={this.onChange}
        />
    }
}

Input 组件有两种应用场景：

1. 不受控的输入框：业务方不给组件传入 value，无法控制输入框的值；
2. 受控的输入框：业务方可以通过给组件传入 value，从而可以在外部控制输入框的值。

不受控的输入框在我使用过程中并没有什么 bug，此处不做赘述，此处只谈受控的输入框，也就是我们需求（仅允许输入英文、数字和汉字，不允许输入其他特殊字符和符号）中需要使用的场景。

前面提到的 compositionstart 和 compositionend 该出场了：利用这两个属性的特点，在输入拼音的“过程中”不让 input 触发 onChange 事件，自然就不会触发校验，好了，既然有了思路，开始码代码。

我们定义一个变量 isOnComposition 来判断是否在“过程中”

isOnComposition = false;

handleComposition = evt => {
  if (evt.type === 'compositionend') {
    this.isOnComposition = false;
    return;
  }

  this.isOnComposition = true;
};

 onChange = evt => {
   if (!this.isOnComposition) {
     this.props.onChange(evt);
   }
 };

render() {
  const commonProps = {
    onChange: this.onChange,
    onCompositionStart: this.handleComposition,
    onCompositionUpdate: this.handleComposition,
    onCompositionEnd: this.handleComposition,
  };
  return <input
    value={this.state.value}
    type="text"
      {...commonProps}
  />
}

你以为就这么轻松解决了么？

呵，你想多了！

我仍然使用开篇那个 demo 来测试这个代码，发现事情又神奇了一点呢，这次拼音压根就输不进去了哇～

我查看了下在输入拼音时函数的调用:
是的，宁没有看错，只触发了onCompositionstart 和 onCompositionupdate这两个函数，我起初以为是逻辑被我写扣圈了，想了想原因（其实我想了好久，人略笨，见笑）：

罪魁祸首就是绑定在 input 上的那个 value，输入拼音的过程中，state.value 一直没变，input 中自然不会有任何输入值，没有输入值，也就完成不了输入过程，触发不了 compositionend，一直处于“过程中”。

所以这次不是程序逻辑扣圈，是中断了。

于是我又想如何把中断的程序接起来（对的，垮掉了我们就捡起来，哈），完成这个链条。

我想了好多办法，也在网上看了好多办法，可惜都解决不了我的困境。

各种心酸不堪回首，幸好最后找到了一个办法：其实想想原来代码中用 state.value 去控制 input 值的变化，还是没有把 input 中何时输入值的控制权放在自己手里，“过程中”这个概念也就失去了意义。只要 state.value 还和 input 绑在一起，就是我自己玩我自己的，人家玩人家的。于是，就有了下面让控制权回到我手中的代码。

import React, { Component, createRef } from 'react';
import PropTypes from 'prop-types';

export default class InputDemo extends Component {

    inputRef = createRef();

    isOnComposition = false;

    componentDidMount() {
        this.setInputValue();
    }

    componentDidUpdate() {
        this.setInputValue();
    }

    setInputValue = () => {
        this.inputRef.current.value = this.props.value || ''
    };

    handleComposition = evt => {
        if (evt.type === 'compositionend') {
            this.isOnComposition = false;
            return;
        }

        this.isOnComposition = true;
    };

    onChange = evt => {
        if (!this.isOnComposition) {
            this.props.onChange(evt);
        }
    };

    render() {
        const commonProps = {
            onChange: this.onChange,
            onCompositionStart: this.handleComposition,
            onCompositionUpdate: this.handleComposition,
            onCompositionEnd: this.handleComposition,
        };
        return <input
            ref={this.inputRef}
            type="text"
            {...commonProps}
        />
    }
}

测了一下，大致上是没问题了。

还要看一下谷歌浏览器和火狐浏览器，果然还有坑：

1. 火狐浏览器中的执行顺序：compositionstart compositionend onChange
2. 谷歌浏览器中的执行顺序：compositionstart onChange compositionend

最后再做一下兼容处理，修改一下 handleComposition 函数

handleComposition = evt => {
   if (evt.type === 'compositionend') {
     this.isOnComposition = false;

     // 谷歌浏览器：compositionstart onChange compositionend
     // 火狐浏览器：compositionstart compositionend onChange
     if (navigator.userAgent.indexOf('Chrome') > -1) {
       this.onChange(evt);
     }

     return;
   }

   this.isOnComposition = true;
 };

因为不管中间执行了那些函数，最后都是需要执行 onChange 事件的，因此加了判断，对谷歌浏览器做了特殊处理（其它浏览器暂时没做考虑和处理）。

完整代码 https://github.com/liyuan-meng/my-react-app/tree/master/src/inputAndComposition

后记

到此，正文结束了，我还要说两个需要注意的地方，其实也是踩了的坑：

1. 如果 Input 组件的实现使用了 React.PureComponent ，在以上需求中会出现的问题：输入特殊字符时，外部通过正则将其 replace 掉了，传入 Input 组件内部的 value 实际上没有任何变化，也不会触发组件 render。这是因为 PureComponent 对 shouldComponentUpdate 函数做了优化，如果发现 props 和 state 上的属性都没有变化，不会重新渲染组件，因此我暂时的处理是：使用 React.Component ，组件实现中对 shouldComponentUpdate 封装。
2. 在外部使用 mobx 的时候，如果使用 observable 监听 value，会出现和上面蕾丝的情况—输入特殊字符时，通过正则将其 replace 掉了，mobx 也发现 value 没有任何变化，就不会触发 render，我暂时的处理是使用 state，虽然我觉得这不是最好的办法，但我目前还想不到其它的处理方式。

前言

一切要都要从打包构建说起。

当下我们很多项目都是基于 webpack 构建的， 主要用于：

• 本地开发
• 打包上线

首先，webpack 是一个伟大的工具。

经过不断的完善，webpack 以及周边的各种轮子已经能很好的满足我们的日常开发需求。

我们都知道，webpack 具备将各类资源打包整合在一起，形成 bundle 的能力。

可是，当资源越来越多时，打包的时间也将越来越长。

一个中大型的项目， 启动构建的时间能达到数分钟之久。

拿我的项目为例， 初次构建大概需要三分钟， 而且这个时间会随着系统的迭代越来越长。

相信不少同学也都遇到过类似的问题。 打包时间太久，这是一个让人很难受的事情。

那有没有什么办法来解决呢？

当然是有的。

这就是今天的主角 ESM， 以及以它为基础的各类构建工具， 比如：

1. Snowpack
2. Vite
3. Parcel

等等。

今天，我们就这个话题展开讨论， 希望能给大家一些其发和帮助。

文章较长，提供一个传送门：

1. 什么是 ESM
2. ESM 是如何工作的
3. Bundle & Bundleless
4. 实现一个乞丐版 Vite
5. Snowpack & 实践
6. bundleless 模式在实际开发中存在的一些问题
7. 结论

正文

什么是 ESM

ESM 是理论基础， 我们都需要了解。

「 ESM 」 全称 ECMAScript modules，基本主流的浏览器版本都以已经支持。

ESM 是如何工作的

当使用ESM 模式时， 浏览器会构建一个依赖关系图。不同依赖项之间的连接来自你使用的导入语句。

通过这些导入语句， 浏览器 或 Node 就能确定加载代码的方式。

通过指定一个入口文件，然后从这个文件开始，通过其中的import语句，查找其他代码。

通过指定的文件路径， 浏览器就找到了目标代码文件。 但是浏览器并不能直接使用这些文件，它需要解析所有这些文件，以将它们转换为称为模块记录的数据结构。

然后，需要将 模块记录 转换为 模块实例 。

模块实例， 实际上是 「 代码 」（指令列表）与「 状态」（所有变量的值）的组合。

对于整个系统而言， 我们需要的是每个模块的模块实例。

模块加载的过程将从入口文件变为具有完整的模块实例图。

对于ES模块，这分为 三个步骤：

1. 构造—查找，下载所有文件并将其解析为模块记录。
2. 实例化—查找内存中的框以放置所有导出的值（但尚未用值填充它们）。然后使导出和导入都指向内存中的那些框，这称为链接。
3. 运行—运行代码以将变量的实际值填充到框中。

在构建阶段时， 发生三件事情：

1. 找出从何处下载包含模块的文件
2. 提取文件（通过从URL下载文件或从文件系统加载文件）
3. 将文件解析为模块记录

1. 查找

首先，需要找到入口点文件。

在HTML中，可以通过脚本标记告诉加载程序在哪里找到它。

但是，如何找到下一组模块， 也就是 main.js 直接依赖的模块呢？

这就是导入语句的来源。

导入语句的一部分称为模块说明符， 它告诉加载程序可以在哪里找到每个下一个模块。

在解析文件之前，我们不知道模块需要获取哪些依赖项，并且在提取文件之前，也无法解析文件。

这意味着我们必须逐层遍历树，解析一个文件，然后找出其依赖项，然后查找并加载这些依赖项。

如果主线程要等待这些文件中的每个文件下载，则许多其他任务将堆积在其队列中。

那是因为当浏览器中工作时，下载部分会花费很长时间。

这样阻塞主线程会使使用模块的应用程序使用起来太慢。

这是ES模块规范将算法分为多个阶段的原因之一。

将构造分为自己的阶段，使浏览器可以在开始实例化的同步工作之前获取文件并建立对模块图的理解。

这种方法（算法分为多个阶段）是 ESM 和 CommonJS模块 之间的主要区别之一。

CommonJS可以做不同的事情，因为从文件系统加载文件比通过Internet下载花费的时间少得多。

这意味着Node可以在加载文件时阻止主线程。

并且由于文件已经加载，因此仅实例化和求值（在CommonJS中不是单独的阶段）是有意义的。

这也意味着在返回模块实例之前，需要遍历整棵树，加载，实例化和评估任何依赖项。

在具有CommonJS模块的Node中，可以在模块说明符中使用变量。

require在寻找下一个模块之前，正在执行该模块中的所有代码。这意味着当进行模块解析时，变量将具有一个值。

但是，使用ES模块时，需要在进行任何评估之前预先建立整个模块图。

这意味着不能在模块说明符中包含变量，因为这些变量还没有值。

但是，有时将变量用于模块路径确实很有用。

例如，你可能要根据代码在做什么，或者在不同环境中运行来记载不同的模块。

为了使ES模块成为可能，有一个建议叫做动态导入。有了它，您可以使用类似的导入语句：

import(`${path}/foo.js`)。

这种工作方式是将使用加载的任何文件import()作为单独图的入口点进行处理。

动态导入的模块将启动一个新图，该图将被单独处理。

但是要注意一件事–这两个图中的任何模块都将共享一个模块实例。

这是因为加载程序会缓存模块实例。对于特定全局范围内的每个模块，将只有一个模块实例。

这意味着发动机的工作量更少。

例如，这意味着即使多个模块依赖该模块文件，它也只会被提取一次。（这是缓存模块的一个原因。我们将在评估部分中看到另一个原因。）

加载程序使用称为模块映射的内容来管理此缓存。每个全局变量在单独的模块图中跟踪其模块。

当加载程序获取一个URL时，它将把该URL放入模块映射中，并记下它当前正在获取文件。然后它将发出请求并继续以开始获取下一个文件。

如果另一个模块依赖于同一文件会怎样？加载程序将在模块映射中查找每个URL。如果在其中看到fetching，它将继续前进到下一个URL。

但是模块图不仅跟踪正在获取的文件。模块映射还充当模块的缓存，如下所示。

2. 解析

现在我们已经获取了该文件，我们需要将其解析为模块记录。这有助于浏览器了解模块的不同部分。

创建模块记录后，它将被放置在模块图中。这意味着无论何时从此处请求，加载程序都可以将其从该映射中拉出。

解析中有一个细节看似微不足道，但实际上有很大的含义。

解析所有模块，就像它们"use strict"位于顶部一样。还存在其他细微差异。

例如，关键字await是在模块的顶级代码保留，的值this就是undefined。

这种不同的解析方式称为“解析目标”。如果解析相同的文件但使用不同的目标，那么最终将得到不同的结果。
因此，需要在开始解析之前就知道要解析的文件类型是否是模块。

在浏览器中，这非常简单。只需放入type="module"的script标签。
这告诉浏览器应将此文件解析为模块。并且由于只能导入模块，因此浏览器知道任何导入也是模块。

但是在Node中，您不使用HTML标记，因此无法选择使用type属性。社区尝试解决此问题的一种方法是使用 .mjs扩展。使用该扩展名告诉Node，“此文件是一个模块”。您会看到人们在谈论这是解析目标的信号。目前讨论仍在进行中，因此尚不清楚Node社区最终决定使用什么信号。

无论哪种方式，加载程序都将确定是否将文件解析为模块。如果它是一个模块并且有导入，则它将重新开始该过程，直到提取并解析了所有文件。

我们完成了！在加载过程结束时，您已经从只有入口点文件变为拥有大量模块记录。

下一步是实例化此模块并将所有实例链接在一起。

3. 实例化

就像我之前提到的，实例将代码与状态结合在一起。

该状态存在于内存中，因此实例化步骤就是将所有事物连接到内存。

首先，JS引擎创建一个模块环境记录。这将管理模块记录的变量。然后，它将在内存中找到所有导出的框。模块环境记录将跟踪与每个导出关联的内存中的哪个框。

内存中的这些框尚无法获取其值。只有在评估之后，它们的实际值才会被填写。该规则有一个警告：在此阶段中初始化所有导出的函数声明。这使评估工作变得更加容易。

为了实例化模块图，引擎将进行深度优先的后顺序遍历。这意味着它将下降到图表的底部-底部的不依赖其他任何内容的依赖项-并设置其导出。

引擎完成了模块下面所有出口的接线-模块所依赖的所有出口。然后，它返回一个级别，以连接来自该模块的导入。

请注意，导出和导入均指向内存中的同一位置。首先连接出口，可以确保所有进口都可以连接到匹配的出口。

这不同于CommonJS模块。在CommonJS中，整个导出对象在导出时被复制。这意味着导出的任何值（例如数字）都是副本。

这意味着，如果导出模块以后更改了该值，则导入模块将看不到该更改。

相反，ES模块使用称为实时绑定的东西。两个模块都指向内存中的相同位置。这意味着，当导出模块更改值时，该更改将显示在导入模块中。

导出值的模块可以随时更改这些值，但是导入模块不能更改其导入的值。话虽如此，如果模块导入了一个对象，则它可以更改该对象上的属性值。

之所以拥有这样的实时绑定，是因为您可以在不运行任何代码的情况下连接所有模块。当您具有循环依赖性时，这将有助于评估，如下所述。

因此，在此步骤结束时，我们已连接了所有实例以及导出/导入变量的存储位置。

现在我们可以开始评估代码，并用它们的值填充这些内存位置。

4. 执行

最后一步是将这些框填充到内存中。JS引擎通过执行顶级代码（函数外部的代码）来实现此目的。

除了仅在内存中填充这些框外，评估代码还可能触发副作用。例如，模块可能会调用服务器。

由于存在潜在的副作用，您只需要评估模块一次。与实例化中发生的链接可以完全相同的结果执行多次相反，评估可以根据您执行多少次而得出不同的结果。

这是拥有模块映射的原因之一。模块映射通过规范的URL缓存模块，因此每个模块只有一个模块记录。这样可以确保每个模块仅执行一次。与实例化一样，这是深度优先的后遍历。

那我们之前谈到的那些周期呢？

在循环依赖关系中，您最终在图中有一个循环。通常，这是一个漫长的循环。但是为了解释这个问题，我将使用一个简短的循环的人为例子。

让我们看一下如何将其与CommonJS模块一起使用。首先，主模块将执行直到require语句。然后它将去加载计数器模块。

然后，计数器模块将尝试message从导出对象进行访问。但是由于尚未在主模块中对此进行评估，因此它将返回undefined。JS引擎将在内存中为局部变量分配空间，并将其值设置为undefined。

评估一直持续到计数器模块顶级代码的末尾。我们想看看我们是否最终将获得正确的消息值（在评估main.js之后），因此我们设置了超时时间。然后评估在上恢复main.js。

消息变量将被初始化并添加到内存中。但是由于两者之间没有连接，因此在所需模块中它将保持未定义状态。

如果使用实时绑定处理导出，则计数器模块最终将看到正确的值。到超时运行时，main.js的评估将完成并填写值。

支持这些循环是ES模块设计背后的重要理由。正是这种设计使它们成为可能。

（以上是关于 ESM 的理论介绍， 原文链接在文末）。

Bundle & Bundleless

谈及 Bundleless 的优势，首先是启动快。

因为不需要过多的打包，只需要处理修改后的单个文件，所以响应速度是 O(1) 级别，刷新即可即时生效，速度很快。

所以， 在开发模式下，相比于Bundle，Bundleless 有着巨大的优势。

基于 Webpack 的 bundle 开发模式

上面的图具体的模块加载机制可以简化为下图：

在项目启动和有文件变化时重新进行打包，这使得项目的启动和二次构建都需要做较多的事情，相应的耗时也会增长。

基于 ESModule 的 Bundleless 模式

从上图可以看到，已经不再有一个构建好的 bundle、chunk 之类的文件，而是直接加载本地对应的文件。

从上图可以看到，在 Bundleless 的机制下，项目的启动只需要启动一个服务器承接浏览器的请求即可，同时在文件变更时，也只需要额外处理变更的文件即可，其他文件可直接在缓存中读取。

对比总结

Bundleless 模式可以充分利用浏览器自主加载的特性，跳过打包的过程，使得我们能在项目启动时获取到极快的启动速度，在本地更新时只需要重新编译单个文件。

实现一个乞丐版 Vite

Vite 也是基于 ESM 的， 文件处理速度 O(1)级别， 非常快。

作为探索， 我就简单实现了一个乞丐版Vite:

GitHub 地址： Vite-mini，

简要分析一下。

<body>
  <div id="app"></div>
  <script type="module" data-original="/src/main.js"></script>
</body>

html 文件中直接使用了浏览器原生的 ESM（type="module"） 能力。

所有的 js 文件经过 vite 处理后，其 import 的模块路径都会被修改，在前面加上 /@modules/。当浏览器请求 import 模块的时候，vite 会在 node_modules 中找到对应的文件进行返回。

其中最关键的步骤就是模块的记载和解析， 这里我简单用koa简单实现了一下， 整体结构：

const fs = require('fs');
const path = require('path');
const Koa = require('koa');
const compilerSfc = require('@vue/compiler-sfc');
const compileDom = require('@vue/compiler-dom');
const app = new Koa();

// 处理引入路径
function rewriteImport(content) {
  // ...
}

// 处理文件类型等， 比如支持ts, less 等类似webpack的loader的功能
app.use(async (ctx) => {
  // ...
}

app.listen(3001, () => {
  console.log('3001');
});

我们先看路径相关的处理：

function rewriteImport(content) {
    return content.replace(/from ['"]([^'"]+)['"]/g, function (s0, s1) {
        // import a from './c.js' 这种格式的不需要改写
        // 只改写需要去node_module找的
        if (s1[0] !== '.' && s1[0] !== '/') {
          return `from '/@modules/${s1}'`;
        }
        return s0;
    });
}

处理文件内容： 源码地址

后续的都是类似的：

这个代码只是解释实现原理， 不同的文件类型处理逻辑其实可以抽离出去， 以中间件的形式去处理。

代码实现的比较简单， 就不额解释了。

Snowpack

和 webpack 的对比：

我使用 Snowpack 做了个 demo , 支持打包， 输出 bundle。

github: Snowpack-React-Demo

能够清晰的看到， 控制台产生了大量的文件请求(也叫瀑布网络请求)，

不过因为都是加载的本地文件， 所以速度很快。

配合HMR， 实现编辑完成立刻生效， 几乎不用等待：

但是如果是在生产中，这些请求对于生产中的页面加载时间而言， 就不太好了。

尤其是HTTP1.1，浏览器都会有并行下载的上限，大部分是5个左右，所以如果你有60个依赖性要下载，就需要等好长一点。

虽然说HTTP2多少可以改善这问题，但若是东西太多，依然没办法。

关于这个项目的打包， 直接执行build：

打包完成后的文件目录，和传统的 webpack 基本一致：

在 build 目录下启动一个静态文件服务：

build 模式下，还是借助了 webpack 的打包能力：

做了资源合并：

就这点而言， 我认为未来一段时间内， 生产环境还是不可避免的要走bundle模式。

bundleless 模式在实际开发中的一些问题

开门见山吧， 开发体验不是很友好，几点比较突出的问题：

• 部分模块没有提供 ESModule 的包。（这一点尤为致命）
• 生态不够健全，工具链不够完善；

当然还有其他方方面面的问题， 就不一一列举。

我简单改造了一个页面， 就遇到很多奇奇怪怪的问题， 开发起来十分难受， 尽管代码的修改能立刻生效。

结论

bundleless 能在开发模式下带了很大的便利。 但就目前来说，要运用到生产的话， 还是有一段路要走的。

就目当下而言， 如果真的要用的话，可能还是 bundleless(dev) + bundle(production) 的组合。

至于未来能不能全面铺开 bundleless，我认为还是有可能的， 交给时间吧。

结尾

本文主要介绍了 esm 的原理， 以及介绍了以此为基础的Vite, Snowpack 等工具， 提供了两个可运行的 demo：

1. Vite-mini，
2. Snowpack-React-Demo

并探索了 bundleless 在生产中的可行性。

Bundleless, 本质上是将原先 Webpack 中模块依赖解析的工作交给浏览器去执行，使得在开发过程中代码的转换变少，极大地提升了开发过程中的构建速度，同时也可以更好地利用浏览器的相关开发工具。

最后，也非常感谢 ESModule、Vite、Snowpack 等标准和工具的出现，为前端开发提效。

才疏学浅， 文中若有错误，还能各位大佬指正， 谢谢。

参考资料

1. https://hacks.mozilla.org/201...
2. https://developer.aliyun.com/...

如果你觉得这篇内容对你挺有启发，可以：

1. 点个「在看」，让更多的人也能看到这篇内容。
2. 关注公众号「前端e进阶」，掌握前端面试重难点，公众号后台回复「加群」和小伙伴们畅聊技术。

我也不知道应该说点撒。

就是一个目录，后续应该还有10多篇的样子，主要是实战，更新了会把目录补上。

超性感的React Hooks（一）：为何她独具魅力

超性感的React Hooks（二）：再谈闭包

超性感的React Hooks（三）：useState

超性感的React Hooks（四）：useEffect

超性感的React Hooks（五）：自定义hooks

超性感的React Hooks（六）：自定义hooks的思维方式

超性感的React Hooks（七）：useReducer

超性感的React Hooks（八）：useContext

超性感的React Hooks（九）：useContext实践

超性感的React Hooks（十）：useRef

超性感的React Hooks（十一）：useCallback、useMemo

这期来关注一下CodeSandbox, 这是一个浏览器端的沙盒运行环境，支持多种流行的构建模板，例如 create-react-app、 vue-cli、parcel等等。 可以用于快速原型开发、DEMO 展示、Bug 还原等等.

相似的产品有很多，例如codepen、JSFiddle、WebpackBin(已废弃).

CodeSandbox 则更加强大，可以视作是浏览器端的 Webpack 运行环境, 甚至在 V3 版本已经支持 VsCode 模式，支持 Vscode 的插件和 Vim 模式、还有主题.

另外 CodeSandbox 支持离线运行(PWA)。基本上可以接近本地 VSCode 的编程体验. 有 iPad 的同学，也可以尝试基于它来进行开发。所以快速的原型开发我一般会直接使用 CodeSandbox

目录

• 引
• 基本目录结构

• 项目构建过程

  • Packager

    • WebpackDllPlugin
    • 在线打包服务
    • 回退方案

  • Transpilation

    • 基本对象
    • Manager
    • TranspiledModule
    • Transpiler
    • BabelTranspiler
  • Evaluation
• 技术地图
• 扩展

引

笔者对 CodeSandbox 的第一印象是这玩意是运行在服务器的吧？ 比如 create-react-app 要运行起来需要 node 环境，需要通过 npm 安装一大堆依赖，然后通过 Webpack 进行打包，最后运行一个开发服务器才能在浏览器跑起来.

实际上 CodeSandbox 打包和运行并不依赖于服务器, 它是完全在浏览器进行的. 大概的结构如下:

• Editor: 编辑器。主要用于修改文件，CodeSandbox这里集成了 VsCode, 文件变动后会通知 Sandbox 进行转译. 计划会有文章专门介绍CodeSandbox的编辑器实现
• Sandbox: 代码运行器。Sandbox 在一个单独的 iframe 中运行, 负责代码的转译(Transpiler)和运行(Evalation). 如最上面的图，左边是Editor，右边是Sandbox
• Packager 包管理器。类似于yarn和npm，负责拉取和缓存 npm 依赖

CodeSandbox 的作者 Ives van Hoorne 也尝试过将 Webpack 移植到浏览器上运行，因为现在几乎所有的 CLI 都是使用 Webpack 进行构建的，如果能将 Webpack 移植到浏览器上, 可以利用 Webpack 强大的生态系统和转译机制(loader/plugin)，低成本兼容各种 CLI.

然而 Webpack 太重了😱，压缩过后的大小就得 3.5MB，这还算勉强可以接受吧；更大的问题是要在浏览器端模拟 Node 运行环境，这个成本太高了，得不偿失。

所以 CodeSandbox 决定自己造个打包器，这个打包器更轻量，并且针对 CodeSandbox 平台进行优化. 比如 CodeSandbox 只关心开发环境的代码构建, 目标就是能跑起来就行了, 跟 Webpack 相比裁剪掉了以下特性:

• 生产模式. CodeSandbox 只考虑 development 模式，不需要考虑 production一些特性，比如

  • 代码压缩，优化
  • Tree-shaking
  • 性能优化
  • 代码分割
• 文件输出. 不需要打包成chunk
• 服务器通信. Sandbox直接原地转译和运行, 而Webpack 需要和开发服务器建立一个长连接用于接收指令，例如 HMR.
• 静态文件处理(如图片). 这些图片需要上传到 CodeSandbox 的服务器
• 插件机制等等.

所以可以认为CodeSandbox是一个简化版的Webpack, 且针对浏览器环境进行了优化，比如使用worker来进行并行转译

CodeSandbox 的打包器使用了接近 Webpack Loader 的 API, 这样可以很容易地将 Webpack 的一些 loader 移植过来. 举个例子，下面是 create-react-app 的实现(查看源码):

import stylesTranspiler from "../../transpilers/style";
import babelTranspiler from "../../transpilers/babe";
// ...
import sassTranspiler from "../../transpilers/sass";
// ...

const preset = new Preset(
  "create-react-app",
  ["web.js", "js", "json", "web.jsx", "jsx", "ts", "tsx"],
  {
    hasDotEnv: true,
    setup: manager => {
      const babelOptions = {
        /*..*/
      };
      preset.registerTranspiler(
        module =>
          /\.(t|j)sx?$/.test(module.path) && !module.path.endsWith(".d.ts"),
        [
          {
            transpiler: babelTranspiler,
            options: babelOptions
          }
        ],
        true
      );
      preset.registerTranspiler(
        module => /\.svg$/.test(module.path),
        [
          { transpiler: svgrTranspiler },
          {
            transpiler: babelTranspiler,
            options: babelOptions
          }
        ],
        true
      );
      // ...
    }
  }
);

可以看出, CodeSandbox的Preset和Webpack的配置长的差不多. 不过, 目前你只能使用 CodeSandbox 预定义的 Preset, 不支持像 Webpack 一样进行配置, 个人觉得这个是符合 CodeSandbox 定位的，这是一个快速的原型开发工具，你还折腾 Webpack 干嘛？

目前支持这些Preset:

基本目录结构

CodeSandbox 的客户端是开源的，不然就没有本文了，它的基本目录结构如下:

• packages

  • app CodeSandbox应用

    • app 编辑器实现
    • embed 网页内嵌运行 codesandbox

    • sandbox 运行沙盒，在这里执行代码构建和预览，相当于一个缩略版的 Webpack. 运行在单独的 iframe 中

      • eval

        • preset

          • create-react-app
          • parcel
          • vue-cli
          • ...

        • transpiler

          • babel
          • sass
          • vue
          • ...
      • compile.ts 编译器
  • common 放置通用的组件、工具方法、资源
  • codesandbox-api: 封装了统一的协议，用于 sandbox 和 editor 之间通信(基于postmessage)
  • codesandbox-browserfs: 这是一个浏览器端的‘文件系统’，模拟了 NodeJS 的文件系统 API，支持在本地或从多个后端服务中存储或获取文件.
  • react-sandpack: codesandbox公开的SDK，可以用于自定义自己的codesandbox

源码在这

项目构建过程

packager -> transpilation -> evaluation

Sandbox 构建分为三个阶段:

• Packager 包加载阶段，下载和处理所有npm模块依赖
• Transpilation 转译阶段，转译所有变动的代码, 构建模块依赖图
• Evaluation 执行阶段，使用 eval 运行模块代码进行预览

下面会按照上述的步骤来描述其中的技术点

Packager

尽管 npm 是个'黑洞'，我们还是离不开它。 其实大概分析一下前端项目的 node_modules，80%是各种开发依赖组成的.

由于 CodeSandbox 已经包揽了代码构建的部分，所以我们并不需要devDependencies, 也就是说 在CodeSandbox 中我们只需要安装所有实际代码运行需要的依赖，这可以减少成百上千的依赖下载. 所以暂且不用担心浏览器会扛不住.

WebpackDllPlugin

CodeSandbox 的依赖打包方式受 WebpackDllPlugin 启发，DllPlugin 会将所有依赖都打包到一个dll文件中，并创建一个 manifest 文件来描述dll的元数据(如下图).

Webpack 转译时或者 运行时可以根据 manifest 中的模块索引(例如__webpack_require__('../node_modules/react/index.js'))来加载 dll 中的模块。 因为WebpackDllPlugin是在运行或转译之前预先对依赖的进行转译，所以在项目代码转译阶段可以忽略掉这部分依赖代码，这样可以提高构建的速度(真实场景对npm依赖进行Dll打包提速效果并不大):

manifest文件

在线打包服务

基于这个思想, CodeSandbox 构建了自己的在线打包服务, 和WebpackDllPlugin不一样的是，CodeSandbox是在服务端预先构建Manifest文件的, 而且不区分Dll和manifest文件。 具体思路如下:

简而言之，CodeSandbox 客户端拿到package.json之后，将dependencies转换为一个由依赖和版本号组成的Combination(标识符, 例如 v1/combinations/babel-runtime@7.3.1&csbbust@1.0.0&react@16.8.4&react-dom@16.8.4&react-router@5.0.1&react-router-dom@5.0.1&react-split-pane@0.1.87.json), 再拿这个 Combination 到服务器请求。服务器会根据 Combination 作为缓存键来缓存打包结果，如果没有命中缓存，则进行打包.

打包实际上还是使用yarn来下载所有依赖，只不过这里为了剔除 npm 模块中多余的文件，服务端还遍历了所有依赖的入口文件(package.json#main), 解析 AST 中的 require 语句，递归解析被 require 模块. 最终形成一个依赖图, 只保留必要的文件.

最终输出 Manifest 文件，它的结构大概如下, 他就相当于WebpackDllPlugin的dll.js+manifest.json的结合体:

{
  // 模块内容
  "contents": {
    "/node_modules/react/index.js": {
      "content": "'use strict';↵↵if ....", // 代码内容
      "requires": [                        // 依赖的其他模块
        "./cjs/react.development.js",
      ],
    },
    "/node_modules/react-dom/index.js": {/*..*/},
    "/node_modules/react/package.json": {/*...*/},
    //...
  },
  // 模块具体安装版本号
  "dependencies": [{name: "@babel/runtime", version: "7.3.1"}, {name: "csbbust", version: "1.0.0"},/*…*/],
  // 模块别名, 比如将react作为preact-compat的别名
  "dependencyAliases": {},
  // 依赖的依赖, 即间接依赖信息. 这些信息可以从yarn.lock获取
  "dependencyDependencies": {
    "object-assign": {
      "entries": ["object-assign"], // 模块入口
      "parents": ["react", "prop-types", "scheduler", "react-dom"], // 父模块
      "resolved": "4.1.1",
      "semver": "^4.1.1",
    }
    //...
  }
}

Serverless 思想


值得一提的是 CodeSandbox 的 Packager 后端使用了 Serverless(基于 AWS Lambda)，基于 Serverless 的架构让 Packager 服务更具伸缩性，可以灵活地应付高并发的场景。使用 Serverless 之后 Packager 的响应时间显著提高，而且费用也下去了。

Packager 也是开源的, 围观

回退方案

AWS Lambda函数是有局限性的, 比如/tmp最多只能有 500MB 的空间. 尽管大部分依赖打包场景不会超过这个限额, 为了增强可靠性(比如上述的方案可能出错，也可能漏掉一些模块), Packager还有回退方案.

后来CodeSanbox作者开发了新的Sandbox，支持把包管理的步骤放置到浏览器端, 和上面的打包方式结合着使用。原理也比较简单: 在转译一个模块时，如果发现模块依赖的npm模块未找到，则惰性从远程下载回来. 来看看它是怎么处理的:

在回退方案中CodeSandbox 并不会将 package.json 中所有的包都下载下来，而是在模块查找失败时，惰性的去加载。比如在转译入口文件时，发现 react 这个模块没有在本地缓存模块队列中，这时候就会到远程将它下载回来，然后接着转译。

也就是说，因为在转译阶段会静态分析模块的依赖，只需要将真正依赖的文件下载回来，而不需要将整个npm包下载回来，节省了网络传输的成本.

CodeSandbox 通过 unpkg.com 或 cdn.jsdelivr.net 来获取模块的信息以及下载文件, 例如

• 获取 package.json: https://unpkg.com/react@latest/package.json
• 包目录结构获取: https://unpkg.com/antd@3.17.0/?meta 这个会递归返回该包的所有目录信息
• 具体文件下载: https://unpkg.com/react@16.8.6/cjs/react.production.min.js 或者 https://cdn.jsdelivr.net/npm/@babel/runtime@7.3.1/helpers/interopRequireDefault.js

Transpilation

讲完 Packager 现在来看一下 Transpilation, 这个阶段从应用的入口文件开始, 对源代码进行转译, 解析AST，找出下级依赖模块，然后递归转译，最终形成一个'依赖图':

CodeSandbox 的整个转译器是在一个单独的 iframe 中运行的：

Editor 负责变更源代码，源代码变更会通过 postmessage 传递给 Compiler，这里面会携带 Module+template

• Module 中包含所有源代码内容和模块路径，其中还包含 package.json, Compiler 会根据 package.json 来读取 npm 依赖;
• template 表示 Compiler 的 Preset，例如create-react-app、vue-cli, 定义了一些 loader 规则，用来转译不同类型的文件, 另外preset也决定了应用的模板和入口文件。 通过上文我们知道, 这些 template 目前的预定义的.

基本对象

在详细介绍 Transpilation 之前先大概看一些基本对象，了解这些对象之间的关系：

• Manager 这是 Sandbox 的核心对象，负责管理配置信息(Preset)、项目依赖(Manifest)、以及维护项目所有模块(TranspilerModule)
• Manifest 通过上文的 Packager 我们知道，Manifest 维护所有依赖的 npm 模块信息
• TranspiledModule 表示模块本身。这里面维护转译的结果、代码执行的结果、依赖的模块信息，负责驱动具体模块的转译(调用 Transpiler)和执行
• Preset 一个项目构建模板，例如 vue-cli、create-react-app. 配置了项目文件的转译规则, 以及应用的目录结构(入口文件)
• Transpiler 等价于 Webpack 的 loader，负责对指定类型的文件进行转译。例如 babel、typescript、pug、sass 等等
• WorkerTranspiler 这是 Transpiler 的子类，调度一个 Worker池来执行转译任务，从而提高转译的性能

Manager

Manager是一个管理者的角色，从大局上把控整个转译和执行的流程. 现在来看看整体的转译流程：

大局上基本上可以划分为以下四个阶段:

• 配置阶段：配置阶段会创建 Preset 对象，确定入口文件等等. CodeSandbox 目前只支持限定的几种应用模板，例如 vue-cli、create-react-app。不同模板之间目录结构的约定是不一样的，例如入口文件和 html 模板文件。另外文件处理的规则也不一样，比如 vue-cli 需要处理.vue文件。
• 依赖下载阶段： 即 Packager 阶段，下载项目的所有依赖，生成 Manifest 对象
• 变动计算阶段：根据 Editor 传递过来的源代码，计算新增、更新、移除的模块。
• 转译阶段：真正开始转译了，首先重新转译上个阶段计算出来的需要更新的模块。接着从入口文件作为出发点，转译和构建新的依赖图。这里不会重复转译没有变化的模块以及其子模块

TranspiledModule

TranspiledModule用于管理某个具体的模块，这里面会维护转译和运行的结果、模块的依赖信息，并驱动模块的转译和执行：

TranspiledModule 会从Preset中获取匹配当前模块的Transpiler列表的，遍历Transpiler对源代码进行转译，转译的过程中会解析AST，分析模块导入语句, 收集新的依赖; 当模块转译完成后，会递归转译依赖列表。 来看看大概的代码：

  async transpile(manager: Manager) {
    // 已转译
    if (this.source)  return this
    // 避免重复转译, 一个模块只转译一次
    if (manager.transpileJobs[this.getId()]) return this;
    manager.transpileJobs[this.getId()] = true;

    // ...重置状态 

    // 🔴从Preset获取Transpiler列表
    const transpilers = manager.preset.getLoaders(this.module, this.query);

    // 🔴 链式调用Transpiler
    for (let i = 0; i < transpilers.length; i += 1) {
      const transpilerConfig = transpilers[i];
      // 🔴构建LoaderContext，见下文
      const loaderContext = this.getLoaderContext(
        manager,
        transpilerConfig.options || {}
      );

      // 🔴调用Transpiler转译源代码
      const {
        transpiledCode,
        sourceMap,
      } = await transpilerConfig.transpiler.transpile(code, loaderContext); // eslint-disable-line no-await-in-loop

      if (this.errors.length) {
        throw this.errors[0];
      }
    }

    this.logWarnings();

    // ...

    await Promise.all(
      this.asyncDependencies.map(async p => {
        try {
          const tModule = await p;
          this.dependencies.add(tModule);
          tModule.initiators.add(this);
        } catch (e) {
          /* let this handle at evaluation */
        }
      })
    );
    this.asyncDependencies = [];

    // 🔴递归转译依赖的模块
    await Promise.all(
      flattenDeep([
        ...Array.from(this.transpilationInitiators).map(t =>
          t.transpile(manager)
        ),
        ...Array.from(this.dependencies).map(t => t.transpile(manager)),
      ])
    );

    return this;
  }

Transpiler

Transpiler等价于webpack的loader，它配置方式以及基本API也和webpack(查看webpack的loader API)大概保持一致，比如链式转译和loader-context. 来看一下Transpiler的基本定义：

export default abstract class Transpiler {
  initialize() {}

  dispose() {}

  cleanModule(loaderContext: LoaderContext) {}

  // 🔴 代码转换
  transpile(
    code: string,
    loaderContext: LoaderContext
  ): Promise<TranspilerResult> {
    return this.doTranspilation(code, loaderContext);
  }

  // 🔴 抽象方法，由具体子类实现
  abstract doTranspilation(
    code: string,
    loaderContext: LoaderContext
  ): Promise<TranspilerResult>;

  // ...
}

Transpiler的接口很简单，transpile接受两个参数:

• code即源代码.
• loaderContext 由TranspiledModule提供, 可以用来访问一下转译上下文信息，比如Transpiler的配置、 模块查找、注册依赖等等。大概外形如下:

export type LoaderContext = {
  // 🔴 信息报告
  emitWarning: (warning: WarningStructure) => void;
  emitError: (error: Error) => void;
  emitModule: (title: string, code: string, currentPath?: string, overwrite?: boolean, isChild?: boolean) => TranspiledModule;
  emitFile: (name: string, content: string, sourceMap: SourceMap) => void;
  // 🔴 配置信息
  options: {
    context: string;
    config?: object;
    [key: string]: any;
  };
  sourceMap: boolean;
  target: string;
  path: string;
  addTranspilationDependency: (depPath: string, options?: { isAbsolute?: boolean; isEntry?: boolean; }) => void;
  resolveTranspiledModule: ( depPath: string, options?: { isAbsolute?: boolean; ignoredExtensions?: Array<string>; }) => TranspiledModule;
  resolveTranspiledModuleAsync: ( depPath: string, options?: { isAbsolute?: boolean; ignoredExtensions?: Array<string>; }) => Promise<TranspiledModule>;
    // 🔴 依赖收集
  addDependency: ( depPath: string, options?: { isAbsolute?: boolean; isEntry?: boolean; }) => void;
  addDependenciesInDirectory: ( depPath: string, options?: { isAbsolute?: boolean; isEntry?: boolean; }) => void;
  _module: TranspiledModule;
};

先从简单的开始，来看看JSON模块的Transpiler实现, 每个Transpiler子类需要实现doTranspilation，接收源代码，并异步返回处理结果：

class JSONTranspiler extends Transpiler {
  doTranspilation(code: string) {
    const result = `
      module.exports = JSON.parse(${JSON.stringify(code || '')})
    `;

    return Promise.resolve({
      transpiledCode: result,
    });
  }
}

BabelTranspiler

并不是所有模块都像JSON这么简单，比如Typescript和Babel。 为了提高转译的效率，Codesandbox会利用Worker来进行多进程转译，多Worker的调度工作由WorkerTranspiler完成，这是Transpiler的子类，维护了一个Worker池。Babel、Typescript、Sass这类复杂的转译任务都是基于WorkerTranspiler实现的：

其中比较典型的实现是BabelTranspiler, 在Sandbox启动时就会预先fork三个worker，来提高转译启动的速度, BabelTranspiler会优先使用这三个worker来初始化Worker池：

// 使用worker-loader fork三个loader，用于处理babel编译
import BabelWorker from 'worker-loader?publicPath=/&name=babel-transpiler.[hash:8].worker.js!./eval/transpilers/babel/worker/index.js';

window.babelworkers = [];
for (let i = 0; i < 3; i++) {
  window.babelworkers.push(new BabelWorker());
}

这里面使用到了webpack的worker-loader, 将指定模块封装为 Worker 对象。让 Worker 更容易使用:

// App.js
import Worker from "./file.worker.js";

const worker = new Worker();

worker.postMessage({ a: 1 });
worker.onmessage = function(event) {};

worker.addEventListener("message", function(event) {});

BabelTranpiler具体的流程如下:

WorkerTranspiler会维护空闲的Worker队列和一个任务队列, 它的工作就是驱动Worker来消费任务队列。具体的转译工作在Worker中进行：

Evaluation

虽然称为打包器(bundler), 但是 CodeSandbox 并不会进行打包，也就是说他不会像 Webpack 一样，将所有的模块都打包合并成 chunks 文件.

Transpilation从入口文件开始转译, 再分析文件的模块导入规则，递归转译依赖的模块. 到Evaluation阶段，CodeSandbox 已经构建出了一个完整的依赖图. 现在要把应用跑起来了🏃

Evaluation 的原理也比较简单，和 Transpilation 一样，也是从入口文件开始: 使用eval执行入口文件，如果执行过程中调用了require，则递归 eval 被依赖的模块。

如果你了解过 Node 的模块导入原理，你可以很容易理解这个过程：

• ① 首先要初始化 html，找到index.html文件，将 document.body.innerHTML 设置为 html 模板的 body 内容.
• ② 注入外部资源。用户可以自定义一些外部静态文件，例如 css 和 js，这些需要 append 到 head 中
• ③ evaluate 入口模块

• ④ 所有模块都会被转译成 CommonJS 模块规范。所以需要模拟这个模块环境。大概看一下代码:

  // 实现require方法
  function require(path: string) {
    // ... 拦截一些特殊模块
  
    // 在Manager对象中查找模块
    const requiredTranspiledModule = manager.resolveTranspiledModule(
      path,
      localModule.path
    );
  
    // 模块缓存, 如果存在缓存则说明不需要重新执行
    const cache = requiredTranspiledModule.compilation;
  
    return cache
      ? cache.exports
      : // 🔴递归evaluate
        manager.evaluateTranspiledModule(
          requiredTranspiledModule,
          transpiledModule
        );
  }
  
  // 实现require.resolve
  require.resolve = function resolve(path: string) {
    return manager.resolveModule(path, localModule.path).path;
  };
  
  // 模拟一些全局变量
  const globals = {};
  globals.__dirname = pathUtils.dirname(this.module.path);
  globals.__filename = this.module.path;
  
  // 🔴放置执行结果，即CommonJS的module对象
  this.compilation = {
    id: this.getId(),
    exports: {}
  };
  
  // 🔴eval
  const exports = evaluate(
    this.source.compiledCode,
    require,
    this.compilation,
    manager.envVariables,
    globals
  );

• ⑤ 使用 eval 来执行模块。同样看看代码:

  export default function(code, require, module, env = {}, globals = {}) {
    const exports = module.exports;
    const global = g;
    const process = buildProcess(env);
    g.global = global;
    const allGlobals = {
      require,
      module,
      exports,
      process,
      setImmediate: requestFrame,
      global,
      ...globals
    };
  
    const allGlobalKeys = Object.keys(allGlobals);
    const globalsCode = allGlobalKeys.length ? allGlobalKeys.join(", ") : "";
    const globalsValues = allGlobalKeys.map(k => allGlobals[k]);
    // 🔴将代码封装到一个函数下面，全局变量以函数形式传入
    const newCode = `(function evaluate(` + globalsCode + `) {` + code + `\n})`;
    (0, eval)(newCode).apply(this, globalsValues);
  
    return module.exports;
  }

Ok！到这里 Evaluation 就解释完了，实际的代码比这里要复杂得多，比如 HMR(hot module replacement)支持, 有兴趣的读者，可以自己去看 CodeSandbox 的源码.

技术地图

一不小心又写了一篇长文，要把这么复杂代码讲清楚真是一个挑战, 我还做的不够好，按照以往的经验，这又是一篇无人问津的文章, 别说是你们, 我自己都不怎么有耐心看这类文章, 后面还是尽量避免吧!

• worker-loader: 将指定模块封装为Worker
• babel: JavaScript代码转译，支持ES, Flow, Typescript
• browserfs: 在浏览器中模拟Node环境
• localForage: 客户端存储库，优先使用(IndexedDB or WebSQL)这些异步存储方案，提供类LocalStorage的接口
• lru-cache: least-recently-used缓存

扩展

• Creating a parallel, offline, extensible, browser based bundler for CodeSandbox
• year of CodeSandbox - Ives van Hoorne aka @CompuIves at @ReactEurope 2018
• How we make npm packages work in the browser
• codesandbox/dependency-packager

本文来源于公司内部的一次闪电分享，稍作润色分享出来。主要讨论 React 性能优化的主要方向和一些小技巧。如果你觉得可以，请多点赞，鼓励我写出更精彩的文章🙏。

文章首发于掘金

React 渲染性能优化的三个方向，其实也适用于其他软件开发领域，这三个方向分别是:

• 减少计算的量。 -> 对应到 React 中就是减少渲染的节点 或者 降低组件渲染的复杂度
• 利用缓存。-> 对应到 React 中就是如何避免重新渲染，利用函数式编程的 memo 方式来避免组件重新渲染
• 精确重新计算的范围。 对应到 React 中就是绑定组件和状态关系, 精确判断更新的'时机'和'范围'. 只重新渲染'脏'的组件，或者说降低渲染范围

目录

• 减少渲染的节点/降低渲染计算量(复杂度)

  • 0️⃣ 不要在渲染函数都进行不必要的计算
  • 1️⃣ 减少不必要的嵌套
  • 2️⃣ 虚拟列表
  • 3️⃣ 惰性渲染
  • 4️⃣ 选择合适的样式方案

• 避免重新渲染

  • 0️⃣ 简化 props
  • 1️⃣ 不变的事件处理器
  • 2️⃣ 不可变数据
  • 3️⃣ 简化 state
  • 4️⃣ 使用 recompose 精细化比对

• 精细化渲染

  • 0️⃣ 响应式数据的精细化渲染
  • 1️⃣ 不要滥用 Context
• 扩展

减少渲染的节点/降低渲染计算量(复杂度)

首先从计算的量上下功夫，减少节点渲染的数量或者降低渲染的计算量可以显著的提高组件渲染性能。

0️⃣ 不要在渲染函数都进行不必要的计算

比如不要在渲染函数(render)中进行数组排序、数据转换、订阅事件、创建事件处理器等等. 渲染函数中不应该放置太多副作用

1️⃣ 减少不必要的嵌套

我们团队是重度的 styled-components 用户，其实大部分情况下我们都不需要这个玩意，比如纯静态的样式规则，以及需要重度性能优化的场景。除了性能问题，另外一个困扰我们的是它带来的节点嵌套地狱(如上图)。

所以我们需要理性地选择一些工具，比如使用原生的 CSS，减少 React 运行时的负担.

一般不必要的节点嵌套都是滥用高阶组件/RenderProps 导致的。所以还是那句话‘只有在必要时才使用 xxx’。 有很多种方式来代替高阶组件/RenderProps，例如优先使用 props、React Hooks

2️⃣ 虚拟列表

虚拟列表是常见的‘长列表'和'复杂组件树'优化方式，它优化的本质就是减少渲染的节点。

虚拟列表只渲染当前视口可见元素:

虚拟列表渲染性能对比:

虚拟列表常用于以下组件场景:

• 无限滚动列表，grid, 表格，下拉列表，spreadsheets
• 无限切换的日历或轮播图
• 大数据量或无限嵌套的树
• 聊天窗，数据流(feed), 时间轴
• 等等

相关组件方案:

• react-virtualized
• react-window 更轻量的 react-virtualized, 同出一个作者
• 更多

扩展：

• Creating more efficient React views with windowing
• Rendering large lists with react-window

3️⃣ 惰性渲染

惰性渲染的初衷本质上和虚表一样，也就是说我们只在必要时才去渲染对应的节点。

举个典型的例子，我们常用 Tab 组件，我们没有必要一开始就将所有 Tab 的 panel 都渲染出来，而是等到该 Tab 被激活时才去惰性渲染。

还有很多场景会用到惰性渲染，例如树形选择器，模态弹窗，下拉列表，折叠组件等等。

这里就不举具体的代码例子了，留给读者去思考.

4️⃣ 选择合适的样式方案

如图(图片来源于THE PERFORMANCE OF STYLED REACT COMPONENTS), 这个图片是17年的了，但是大抵的趋势还是这样。

所以在样式运行时性能方面大概可以总结为：CSS > 大部分CSS-in-js > inline style

避免重新渲染

减少不必要的重新渲染也是 React 组件性能优化的重要方向. 为了避免不必要的组件重新渲染需要在做到两点:

1. 保证组件纯粹性。即控制组件的副作用，如果组件有副作用则无法安全地缓存渲染结果
2. 通过shouldComponentUpdate生命周期函数来比对 state 和 props, 确定是否要重新渲染。对于函数组件可以使用React.memo包装

另外这些措施也可以帮助你更容易地优化组件重新渲染:

0️⃣ 简化 props

① 如果一个组件的 props 太复杂一般意味着这个组件已经违背了‘单一职责’，首先应该尝试对组件进行拆解.
② 另外复杂的 props 也会变得难以维护, 比如会影响shallowCompare效率, 还会让组件的变动变得难以预测和调试.

下面是一个典型的例子, 为了判断列表项是否处于激活状态，这里传入了一个当前激活的 id:

这是一个非常糟糕的设计，一旦激活 id 变动，所有列表项都会重新刷新. 更好的解决办法是使用类似actived这样的布尔值 prop. actived 现在只有两种变动情况，也就是说激活 id 的变动，最多只有两个组件需要重新渲染.

简化的 props 更容易理解, 且可以提高组件缓存的命中率

1️⃣ 不变的事件处理器

①避免使用箭头函数形式的事件处理器, 例如:

<ComplexComponent onClick={evt => onClick(evt.id)} otherProps={values} />

假设 ComplexComponent 是一个复杂的 PureComponent, 这里使用箭头函数，其实每次渲染时都会创建一个新的事件处理器，这会导致 ComplexComponent 始终会被重新渲染.

更好的方式是使用实例方法:

class MyComponent extends Component {
  render() {
    <ComplexComponent onClick={this.handleClick} otherProps={values} />;
  }
  handleClick = () => {
    /*...*/
  };
}

② 即使现在使用hooks，我依然会使用useCallback来包装事件处理器，尽量给下级组件暴露一个静态的函数:

const handleClick = useCallback(() => {
  /*...*/
}, []);

return <ComplexComponent onClick={handleClick} otherProps={values} />;

但是如果useCallback依赖于很多状态，你的useCallback可能会变成这样:

const handleClick = useCallback(() => {
  /*...*/
  // 🤭
}, [foo, bar, baz, bazz, bazzzz]);

这种写法实在让人难以接受，这时候谁还管什么函数式非函数式的。我是这样处理的:

function useRefProps<T>(props: T) {
  const ref = useRef < T > props;
  // 每次渲染更新props
  useEffect(() => {
    ref.current = props;
  });
}

function MyComp(props) {
  const propsRef = useRefProps(props);

  // 现在handleClick是始终不变的
  const handleClick = useCallback(() => {
    const { foo, bar, baz, bazz, bazzzz } = propsRef.current;
    // do something
  }, []);
}

③设计更方便处理的 Event Props. 有时候我们会被逼的不得不使用箭头函数来作为事件处理器：

<List>
  {list.map(i => (
    <Item key={i.id} onClick={() => handleDelete(i.id)} value={i.value} />
  ))}
</List>

上面的 onClick 是一个糟糕的实现，它没有携带任何信息来标识事件来源，所以这里只能使用闭包形式，更好的设计可能是这样的:

// onClick传递事件来源信息
const handleDelete = useCallback((id: string) => {
  /*删除操作*/
}, []);

return (
  <List>
    {list.map(i => (
      <Item key={i.id} id={i.id} onClick={handleDelete} value={i.value} />
    ))}
  </List>
);

如果是第三方组件或者 DOM 组件呢? 实在不行，看能不能传递data-*属性:

const handleDelete = useCallback(event => {
  const id = event.dataset.id;
  /*删除操作*/
}, []);

return (
  <ul>
    {list.map(i => (
      <li key={i.id} data-id={i.id} onClick={handleDelete} value={i.value} />
    ))}
  </ul>
);

2️⃣ 不可变数据

不可变数据可以让状态变得可预测，也让 shouldComponentUpdate '浅比较'变得更可靠和高效. 笔者在React 组件设计实践总结 04 - 组件的思维介绍过不可变数据，有兴趣读者可以看看.

相关的工具有Immutable.js、Immer、immutability-helper 以及 seamless-immutable。

3️⃣ 简化 state

不是所有状态都应该放在组件的 state 中. 例如缓存数据。按照我的原则是：如果需要组件响应它的变动, 或者需要渲染到视图中的数据才应该放到 state 中。这样可以避免不必要的数据变动导致组件重新渲染.

4️⃣ 使用 recompose 精细化比对

尽管 hooks 出来后，recompose 宣称不再更新了，但还是不影响我们使用 recompose 来控制shouldComponentUpdate方法, 比如它提供了以下方法来精细控制应该比较哪些 props:

 /* 相当于React.memo */
 pure()
 /* 自定义比较 */
 shouldUpdate(test: (props: Object, nextProps: Object) => boolean): HigherOrderComponent
 /* 只比较指定key */
 onlyUpdateForKeys( propKeys: Array<string>): HigherOrderComponent

其实还可以再扩展一下，比如omitUpdateForKeys忽略比对某些 key.

精细化渲染

所谓精细化渲染指的是只有一个数据来源导致组件重新渲染, 比如说 A 只依赖于 a 数据，那么只有在 a 数据变动时才渲染 A, 其他状态变化不应该影响组件 A。

Vue 和 Mobx 宣称自己性能好的一部分原因是它们的'响应式系统', 它允许我们定义一些‘响应式数据’，当这些响应数据变动时，依赖这些响应式数据视图就会重新渲染. 来看看 Vue 官方是如何描述的:

0️⃣ 响应式数据的精细化渲染

大部分情况下，响应式数据可以实现视图精细化的渲染, 但它还是不能避免开发者写出低效的程序. 本质上还是因为组件违背‘单一职责’.

举个例子，现在有一个 MyComponent 组件，依赖于 A、B、C 三个数据源，来构建一个 vdom 树。现在的问题是什么呢？现在只要 A、B、C 任意一个变动，那么 MyComponent 整个就会重新渲染:

更好的做法是让组件的职责更单一，精细化地依赖响应式数据，或者说对响应式数据进行‘隔离’. 如下图, A、B、C 都抽取各自的组件中了，现在 A 变动只会渲染 A 组件本身，而不会影响父组件和 B、C 组件:

举一个典型的例子，列表渲染:

import React from 'react';
import { observable } from 'mobx';
import { observer } from 'mobx-react-lite';

const initialList = [];
for (let i = 0; i < 10; i++) {
  initialList.push({ id: i, name: `name-${i}`, value: 0 });
}

const store = observable({
  list: initialList,
});

export const List = observer(() => {
  const list = store.list;
  console.log('List渲染');
  return (
    <div className="list-container">
      <ul>
        {list.map((i, idx) => (
          <div className="list-item" key={i.id}>
            {/* 假设这是一个复杂的组件 */}
            {console.log('render', i.id)}
            <span className="list-item-name">{i.name} </span>
            <span className="list-item-value">{i.value} </span>
            <button
              className="list-item-increment"
              onClick={() => {
                i.value++;
                console.log('递增');
              }}
            >
              递增
            </button>
            <button
              className="list-item-increment"
              onClick={() => {
                if (idx < list.length - 1) {
                  console.log('移位');
                  let t = list[idx];
                  list[idx] = list[idx + 1];
                  list[idx + 1] = t;
                }
              }}
            >
              下移
            </button>
          </div>
        ))}
      </ul>
    </div>
  );
});

上述的例子是存在性能问题的，单个 list-item 的递增和移位都会导致整个列表的重新渲染:

原因大概能猜出来吧? 对于 Vue 或者 Mobx 来说，一个组件的渲染函数就是一个依赖收集的上下文。上面 List 组件渲染函数内'访问'了所有的列表项数据，那么 Vue 或 Mobx 就会认为你这个组件依赖于所有的列表项，这样就导致，只要任意一个列表项的属性值变动就会重新渲染整个 List 组件。

解决办法也很简单，就是将数据隔离抽取到单一职责的组件中。对于 Vue 或 Mobx 来说，越细粒度的组件，可以收获更高的性能优化效果:

export const ListItem = observer(props => {
  const { item, onShiftDown } = props;
  return (
    <div className="list-item">
      {console.log('render', item.id)}
      {/* 假设这是一个复杂的组件 */}
      <span className="list-item-name">{item.name} </span>
      <span className="list-item-value">{item.value} </span>
      <button
        className="list-item-increment"
        onClick={() => {
          item.value++;
          console.log('递增');
        }}
      >
        递增
      </button>
      <button className="list-item-increment" onClick={() => onShiftDown(item)}>
        下移
      </button>
    </div>
  );
});

export const List = observer(() => {
  const list = store.list;
  const handleShiftDown = useCallback(item => {
    const idx = list.findIndex(i => i.id === item.id);
    if (idx !== -1 && idx < list.length - 1) {
      console.log('移位');
      let t = list[idx];
      list[idx] = list[idx + 1];
      list[idx + 1] = t;
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []);

  console.log('List 渲染');

  return (
    <div className="list-container">
      <ul>
        {list.map((i, idx) => (
          <ListItem key={i.id} item={i} onShiftDown={handleShiftDown} />
        ))}
      </ul>
    </div>
  );
});

效果很明显, list-item 递增只会重新渲染本身; 而移位只会重新渲染 List， 因为列表项没有变动, 所以下级 list-item 也不需要重新渲染:

1️⃣ 不要滥用 Context

其实 Context 的用法和响应式数据正好相反。笔者也看过不少滥用 Context API 的例子, 说到底还是没有处理好‘状态的作用域问题’.

首先要理解 Context API 的更新特点，它是可以穿透React.memo或者shouldComponentUpdate的比对的，也就是说，一旦 Context 的 Value 变动，所有依赖该 Context 的组件会全部 forceUpdate.

这个和 Mobx 和 Vue 的响应式系统不同，Context API 并不能细粒度地检测哪些组件依赖哪些状态，所以说上节提到的‘精细化渲染’组件模式，在 Context 这里就成为了‘反模式’.

总结一下使用 Context API 要遵循一下原则:

• 明确状态作用域, Context 只放置必要的，关键的，被大多数组件所共享的状态。比较典型的是鉴权状态

  举一个简单的例子:

  扩展：Context其实有个实验性或者说非公开的选项observedBits, 可以用于控制ContextConsumer是否需要更新. 详细可以看这篇文章<ObservedBits: React Context的秘密功能>. 不过不推荐在实际项目中使用，而且这个API也比较难用，不如直接上mobx。

• 粗粒度地订阅 Context

  如下图. 细粒度的 Context 订阅会导致不必要的重新渲染, 所以这里推荐粗粒度的订阅. 比如在父级订阅 Context，然后再通过 props 传递给下级。

另外程墨 Morgan 在避免 React Context 导致的重复渲染一文中也提到 ContextAPI 的一个陷阱:

<Context.Provider
  value={{ theme: this.state.theme, switchTheme: this.switchTheme }}
>
  <div className="App">
    <Header />
    <Content />
  </div>
</Context.Provider>

上面的组件会在 state 变化时重新渲染整个组件树，至于为什么留给读者去思考。

所以我们一般都不会裸露地使用 Context.Provider, 而是封装为独立的 Provider 组件:

export function ThemeProvider(props) {
  const [theme, switchTheme] = useState(redTheme);
  return (
    <Context.Provider value={{ theme, switchTheme }}>
      {props.children}
    </Context.Provider>
  );
}

// 顺便暴露useTheme, 让外部必须直接使用Context
export function useTheme() {
  return useContext(Context);
}

现在 theme 变动就不会重新渲染整个组件树，因为 props.children 由外部传递进来，并没有发生变动。

其实上面的代码还有另外一个比较难发现的陷阱(官方文档也有提到):

export function ThemeProvider(props) {
  const [theme, switchTheme] = useState(redTheme);
  return (
    {/* 👇 💣这里每一次渲染ThemeProvider, 都会创建一个新的value(即使theme和switchTheme没有变动),
        从而导致强制渲染所有依赖该Context的组件 */}
    <Context.Provider value={{ theme, switchTheme }}>
      {props.children}
    </Context.Provider>
  );
}

所以传递给 Context 的 value 最好做一下缓存:

export function ThemeProvider(props) {
  const [theme, switchTheme] = useState(redTheme);
  const value = useMemo(() => ({ theme, switchTheme }), [theme]);
  return <Context.Provider value={value}>{props.children}</Context.Provider>;
}

扩展

• Optimizing Performance React 官方文档，最好的教程, 利用好 React 的性能分析工具。
• Twitter Lite and High Performance React Progressive Web Apps at Scale 看看 Twitter 如何优化的