[译]尤雨溪：Vue3的设计过程

今日凌晨三点半左右，尤雨溪在他的微博上发表了一篇文章。
固然大佬是在另外一个时区，我们这的凌晨对应的应该是那个疫情最严重的时区的下午。

原文连接： https://increment.com/fronten...

重构新版Vue.js的经验教训

在过去的一年中，Vue团队一直在研究Vue.js的下一个主要版本，咱们但愿在2020年上半年发布该版本。（在撰写本文时，这项工做仍在进行中）。 Vue的主要版本于2018年末造成，当时Vue 2的代码库已有两年半的历史了。在通用软件的生命周期中听起来可能并不长，但在此期间，前端环境发生了巨大变化。

有两个主要的考虑因素使咱们开发了Vue的新主要版本（并重写了它）：首先，主流浏览器广泛提供了新的JavaScript语言功能。其次，随着时间的推移，当前代码库中的设计和体系结构问题已经逐渐暴露了出来。

为何要重构

利用新的语言功能

随着ES6的标准化，JavaScript（正式称为ECMAScript，缩写为ES）得到了重大改进，主流浏览器终于开始为这些新功能提供不错的支持。特别是一些新特性为咱们提供了极大提升Vue功能的机会。

其中最值得注意的是Proxy，它容许框架拦截对象上的操做。Vue的核心功能是可以监听对用户定义状态所作的更改并以数据驱动更新DOM的能力。Vue 2经过使用getter和setter替换状态对象上的属性来实现这种能力。切换到代理将使咱们消除Vue的现有限制，例如没法检测到新的属性添加并提供更好的性能。

可是，代理是本机语言功能，不能在旧版浏览器中彻底填充。为了利用它，咱们知道咱们必须调整框架的浏览器支持范围，这是一个重大突破，只能在新的主要版本中发布。

解决架构问题

要在当前的代码库中解决这些问题，将须要进行大量风险较大的重构，这几乎等同于彻底重写了一遍 。
在维护Vue 2的过程当中，因为现有架构的局限性，咱们积累了许多难以解决的问题。例如，模板编译器的编写方式令源映射的支持很是困难。一样，虽然Vue 2从技术上容许构建针对非DOM平台的更高级别的渲染器，但咱们必须派生代码库并复制大量代码才能实现这一点。要在当前的代码库中解决这些问题，将须要进行大量风险较大的重构，这几乎等同于彻底重写 。

同时，咱们以各类模块的内部与浮动代码之间隐式耦合的形式积累了隐患，而浮动代码彷佛并不属于任何地方。这使得孤立地理解代码库的一部分变得更加困难，而且咱们注意到，贡献者不多会对重要的更改充满信心。重构将使咱们有机会根据这些注意事项来从新考虑代码组织。

初始原型阶段

咱们于2018年末开始对Vue 3进行原型设计，其初步目标是验证这些问题的解决方案。在此阶段，咱们主要为进一步发展奠基坚实的基础。

切换到TypeScript

Vue 2最初是用纯JS编写的。在原型开发阶段以后不久，咱们意识到类型系统对于这种规模的项目将很是有帮助。类型检查极大地减小了在重构期间引入意外错误的机会，并有助于贡献者更自信的进行重要的更改。咱们经过Facebook的Flow类型检查，由于它能够逐步添加到现有的JS项目。Flow在必定程度上有所帮助，可是咱们没有从中得到太多收益。特别是不断变化的变化使升级变得很痛苦。与TypeScript和Visual Studio Code的深度集成相比，Flow对集成开发环境的支持也不理想。

咱们还注意到，用户愈来愈多地同时使用Vue和TypeScript。为了支持它们的用例，咱们必须与使用不一样类型系统分开创做和维护TypeScript声明。切换到TypeScript将使咱们可以自动生成声明文件，从而减轻了维护负担。

解耦内部封装

咱们还采用了monorepo，其中的框架由内部软件包组成，每一个内部软件包都具备本身的单独API，类型定义和测试。咱们但愿使这些模块之间的依赖关系更加明确，从而使开发人员更容易阅读，理解并进行全部更改。这是咱们努力下降项目贡献壁垒并提升其长期可维护性的关键。

设置RFC流程

到2018年末，咱们有了一个使用新的数据驱动视图系统和虚拟DOM渲染器的工做原型。咱们已经验证了咱们想要进行的内部体系结构改进，可是只包含了面向公众的API更改的草案。如今是将它们变成具体设计的时候了。

咱们知道咱们必须尽早而仔细地作到这一点。Vue的普遍使用意味着突破性变化可能致使用户大量迁移成本和潜在的生态系统碎片化。为了确保用户可以提供有关重大更改的反馈，咱们在2019年初采用了RFC（征求意见）流程。每一个RFC遵循一个模板，其中侧重于动机，设计细节，权衡和采用策略。因为此过程是在GitHub仓库中进行的，提案是做为请求请求提交的，所以讨论会在注释中天然展开。

该RFC的过程已经证实了极大的帮助，做为一个思想框架，它迫使咱们要充分考虑潜在变化的方方面面，让咱们的社区参与设计过程，并提交深思熟虑出来的功能要求。

更快更小

性能对于前端框架相当重要。尽管Vue 2具备出色的性能，但经过尝试新的渲染策略，重构提供了进一步发展的可能。

克服虚拟DOM的瓶颈

Vue有一个至关独特的呈现策略：它提供相似于HTML的模板语法，但将模板编译为可返回虚拟DOM树的呈现函数。该框架经过递归遍历两个虚拟DOM树并比较每一个节点上的每一个属性来肯定实际DOM的哪些部分须要更新。因为现代JavaScript引擎执行了高级优化，所以这种有点野蛮的算法一般很快，可是仍然涉及许多没必要要的CPU工做。当您查看包含大量静态内容且只有少许动态绑定（整个虚拟DOM）的模板时，效率低下，尤为仅有一点改变却仍然须要递归整个虚拟DOM树，以了解发生了什么变化。

幸运的是，模板编译步骤使咱们有机会对模板进行静态分析并提取有关动态零件的信息。Vue 2经过跳过静态子树在某种程度上作到了这一点，可是因为过于简单的编译器体系结构，难以实施更高级的优化。在Vue 3中，咱们使用适当的AST转换管道重写了编译器，这使咱们可以以转换插件的形式编写编译时优化。

有了新的体系结构，咱们但愿找到一种渲染策略，以尽量减小开销。一种选择是放弃虚拟DOM并直接生成命令式DOM操做，但这将消除直接编写虚拟DOM渲染功能的能力，咱们发现这对高级用户和库做者很是有价值。另外，这将是一个巨大的突破性变化。

其次，最好的方法是消除没必要要的虚拟DOM树遍历和属性比较，这在更新过程当中每每会带来最大的性能开销。为了实现这一点，编译器和运行时须要协同工做：编译器分析模板并生成带有优化提示的代码，而运行时将拾取提示并在可能的状况下采用快速路径。这里有三个主要的优化工做：

首先，在树的层面上，咱们注意到，节点结构在没有模板指令的时候是彻底静态的（例如，v-if和v-for）。若是咱们将模板分为动态的和静态的“块”，每一个块内的节点结构再次变得彻底静态。当咱们更新一个块内的节点时，咱们再也不须要递归遍历树-能够在平面数组中跟踪该块内的动态绑定。经过将咱们须要执行的树遍历量减小一个数量级，此优化可避免虚拟DOM的大部分开销。

其次，编译器会主动检测模板中的静态节点，子树甚至数据对象，并将其提高到生成代码中的render函数以外。这样能够避免在每一个渲染上从新建立这些对象，从而大大提升了内存使用率并减小了垃圾回收的频率。

第三，在元素级别，编译器还会根据须要执行的更新类型为具备动态绑定的每一个元素生成一个优化标志。例如，具备动态类绑定和许多静态属性的元素将收到一个标志，指示仅须要进行类检查。运行时将获取这些提示并采用专用的快速路径。

综上所述，这些技术已显著提升了咱们的渲染更新，运行Vue 3有时甚至会比Vue 2快上个十倍。

极小的尺寸

框架的大小也会影响其性能。这是Web应用程序的重要关注点，由于须要动态下载资产，而且在浏览器解析必要的JavaScript以前，该应用程序将是交互式的。对于单页应用程序尤为如此。尽管Vue一直是相对轻量级的（Vue 2的运行时大小压缩为23 KB），但咱们注意到了两个问题：

首先，并非每一个人都使用框架的全部功能。例如，从未使用过渡组件的应用仍会下载与过渡相关的代码和而且花时间去解析它。

其次，当咱们添加新功能时，该框架会无限的变大。当咱们考虑新功能添加的时候，不得不考虑到尺寸的问题。所以，咱们倾向于框架仅包含大多数用户会使用的功能。

理想状况下，用户应该可以在构建时删除未使用的框架功能的代码-也称为“Tree Shaking” -只打包他们使用的代码。这也将使咱们可以发布一部分用户会以为有用的功能，而不会增长其他用户的有效下载成本。

在Vue 3中，咱们经过将大多数全局API和内部帮助程序移至ES模块导出来实现了这一目标。这使现代打包工具能够静态分析模块依赖性并删除与未使用的导出相关的代码。模板编译器还会生成Tree Shaking友好的代码，若是该功能实际上在模板中使用，则该代码仅导入该功能的帮助程序。

框架的某些部分永远不会Tree Shaking，由于它们对于任何类型的应用程序都是必不可少的。咱们将这些必不可少的部分的度量标准称为基础尺寸。尽管增长了许多新功能，但Vue 3的基准尺寸gzip后大约只有10KB ，甚至还不到Vue 2的一半。

知足规模需求

咱们还想提升Vue处理大型应用程序的能力。咱们最初的Vue设计着重于温和的学习曲线。可是随着Vue愈来愈普遍地被采用，咱们了解了更多有关项目需求的信息，这些项目包含数百个模块，而且随着时间的流逝由数十名开发人员维护。对于这些类型的项目，像TypeScript这样的类型系统以及可复用代码的能力相当重要，而Vue 2在这些领域的支持并不理想。

在设计Vue 3的早期阶段，咱们尝试经过提供对使用类编写组件的内置支持来改善TypeScript集成。挑战在于，咱们须要使类可用的许多语言功能（如类字段和装饰器）还是提案，而且在正式成为JavaScript一部分以前可能会发生变化。涉及到的复杂性和不肯定性使咱们怀疑添加Class API是否真的合理，由于它除了提供更好的TypeScript集成以外没有提供任何其余功能。

咱们决定研究其余解决扩展问题的方法。受到React Hooks的启发，咱们考虑过公开较低级别的数据驱动视图和组件生命周期API，以实现一种更自由形式的编写组件逻辑的方式，称为Composition API。无需经过指定一长串选项来定义组件，Composition API容许用户像编写函数同样自由地表达，编写和重用有状态组件逻辑，同时提供出色的TypeScript支持。

咱们对这个想法感到很是兴奋。尽管Composition API旨在解决特定类别的问题，但从技术上讲，仅在编写组件时才可使用它。在该提案的初稿中，咱们暗示咱们可能会在未来的版本中将现有的Options API替换为Composition API。这致使社区成员的大量不满，这为咱们上了宝贵的一课，可使他们清楚地传达长期计划和意图，以及了解用户的需求。在听取了咱们社区的反馈以后，咱们对提案进行了彻底的从新设计，从而明确代表Composition API将是对Options的补充和补充API。收到修改后的提案更加积极，并收到了许多建设性的建议。

寻求平衡

在Vue超过一百万的开发人员中，有只会HTML和CSS的基础知识的初学者，有从jQuery迁移的老程序员，还有从另外一个框架迁移的前端，甚至还有正在寻找前端解决方案的后端工程师、以及大规模处理软件的软件架构师。一些开发人员可能但愿在旧版应用程序上增长交互性，而另外一些开发人员可能须要敏捷开发但维护需求有限的一次性项目。在项目的整个生命周期中，可能不得不处理大型的，多年期的项目和一个波动的开发团队。

在咱们寻求平衡各类折衷方案的同时，Vue的设计不断受到这些需求的影响和启发。Vue号称“渐进式框架”，封装了由此过程产生的分层API设计。初学者可使用CDN脚本，基于HTML的模板和直观的Options API来轻松学习，而高手可使用功能齐全的CLI，渲染功能和Composition API来处理更复杂的项目。

要实现咱们的愿景，还有许多工做要作。最重要的是，更新周边库，文档和工具以确保顺利迁移。在接下来的几个月中，咱们将继续努力，咱们火烧眉毛地想看看社区将经过Vue 3创造什么。