首页手记 [译] 尤雨溪：Vue 3.0 计划

[译] 尤雨溪：Vue 3.0 计划

标签：

JavaScript Vue.js

原文：Plans for the Next Iteration of Vue.js
作者：Evan You（尤雨溪）发表时间：Sep 30, 2018
转载请写明出处：https://blog.lgdsunday.club/2018/10/10/Vue 3.0 plan/

计划下一次迭代Vue.js

上周在Vue.js伦敦，我简要介绍了Vue的下一个主要版本即将发布的内容。这篇文章提供了对计划的深入概述。

为什么要更新主版本？

Vue 2.0 恰好在两年前发布了（时间过得真快！）。在此期间，核心仍然向后兼容五个次要版本。我们已经积累了许多可以带来改进的想法，但一直没有发布它们（3.0），因为它们与现在的版本（2.x）相比，变化很大。与此同时，JavaScript生态系统和语言本身也在迅速发展。有了需要新的工具可以增强我们的工作流程，以及出现了许多新的语言功能，可以解决Vue试图解决的问题。并且有了使它变得更简单，更完整和更有效的解决方案。更令人兴奋的是，我们看到ES2015支持成为所有主流浏览器的标准。Vue 3.0旨在利用这些新的语言功能使Vue核心更小，更快，更强大。

Vue 3.0目前处于原型设计阶段，我们已经实现了与2.x相近的特征基本相同的运行时了。下面列出的许多项目已经实施或确认可行。尚未实施或仍处于勘探阶段的标记为*。

细节

高级API更改

L; DR：除了渲染函数API和作用域插槽语法之外的所有内容都将保持不变，或者你也可以通过兼容性构建使其兼容2.x版本。

因为这是一个新的版本，所以会有一些突破性的变化。但是，我们非常重视兼容性，因此我们希望尽快和大家沟通这些更改。以下是当前计划的公共API更改：

1、模板语法将保持99％相同。在scoped slot语法中可能会有一些小的调整，但除此之外我们没有计划为其他的模板语法更改任何其他内容。
2、3.0将原生支持基于类的组件，而且无需借助任何编译及各种 stage 阶段的特性，以此提供良好的编写体验。大多数当前选项在基于类的API中具有合理的映射。还可以选择使用Stage-x功能（如 class 的静态字段和装饰器 (decorator) 等仍然可以选择性地使用，以此增强编写体验）来增强创作体验。此外，API在设计时考虑了TypeScript类型推断。3.x代码库本身将使用TypeScript编写，并提供改进的TypeScript支持。（也就是说，在应用程序中使用TypeScript仍然是完全可选的。）
3、2.x 系列的基于对象的组件格式仍将受支持，不过会在内部将其转换为一个相应的类
4、仍然支持Mixins。*
5、顶级API可能会大修，以避免在安装插件时导致对Vue运行时的修改。相反，插件将应用并作用于组件树。这样可以更轻松地测试依赖于特定插件的组件，还可以使用不同的插件在同一页面上安装多个Vue应用程序，但它运用在相同的Vue运行时。*
6、功能组件最终会是普通函数 - 但是，现在需要通过辅助函数显式创建异步组件。
7、将获得最多更改的部分是渲染函数中使用的Virtual DOM格式。我们目前正在收集主流第三方库作者的反馈意见，并将分享更多细节，因为我们对这些变化更有信心，但只要您不依赖于应用程序中的手写（非JSX）渲染功能，这个升级应该是一个相当简单的过程。

源代码架构

TL; DR：更好的解耦内部模块，TypeScript和更容易贡献的代码库。

我们正在从头开始重新编写vue 3.0，以使得实现更清晰，更易维护的架构，特别是让对代码的贡献变得更加容易。我们将一些内部功能分解为单独的包，以便隔离复杂性。例如，观察者模块observer将成为单独的包，具有自己的公共API和测试用例。请注意，这不会影响到框架级的API - 您不必手动从多个包导入以使用Vue（导入多个文件）。相反，最终的Vue包将会把这些内部包文件进行组装。

代码库现在也用TypeScript编写。虽然这将使掌握TypeScript成为为新代码库做出贡献的先决条件，但我们相信这些类型信息和IDE支持实际上将使新贡献者更容易做出有意义的贡献。

将观察者（observer）和调度程序（scheduler）分离到单独的包中，还允许我们轻松地尝试这些部分的替代实现。例如，我们可以使用相同的API实现IE11兼容的观察器实现，或者requestIdleCallback在长时间更新期间利用可以为浏览器提供的备用调度程序。*

观察机制

TL; DR：更完整，精确，高效和可调试的反应性跟踪和用于创建可观测的API。

3.0将提供基于代理的观察器（Proxy-based observer）实现，该实现提供具有完整语言覆盖的响应式跟踪。这消除了Vue 2中基于Object.defineProperty 实现的许多限制：

检测属性添加/删除（PS：是不是意味着我们不需要再使用Vue.set()了？）
检测数组索引的变化和长度length的变化
支持Map，Set，WeakMap和WeakSet

新的观察者还具有以下特征：

用于创建可观察对象（observable响应式对象）的公开API。这为中小规模场景提供了轻量级，简单的跨组件状态管理解决方案。
默认惰性监测（Lazy Observation）。在2.x中，任何被动数据，无论其大小，都会在启动时被观察到。如果您的数据集很大，这可能会导致应用启动时出现明显的性能开销。在3.x中，只需要观察用于渲染应用程序最初可见部分的数据，这会让整个的检测性能提升很多。
更精确的更改通知。例如：在2.x中，使用Vue.set强制添加新属性将导致依赖于对象的所有观察者都被重新计算。在3.x中，只有依赖于该特定属性的观察者才会收到通知。
不可变的observables：我们可以创建一个对象的“不可变”版本，即使在嵌套属性上也可以防止突变，除非系统在内部暂时解锁它。此机制可用于防止props或Vuex状态树以外的变化。
更好的调试功能：我们可以精确地跟踪使用新增的 renderTracked和renderTriggeredhook 跟踪或触发组件重新呈现的时间和原因：

其他运行时的改进

TL; DR：更小，更快，支持摇树优化，支持 Fragments 和跨组件渲染，自定义渲染器API。

更小：新的代码库从一开始就考虑到对摇树优化（tree-shaking）的友好。现在，可动态按需导入内置组件（<transition>，<keep-alive>）和运行时工具性指令（v-model）等功能，所有也是可摇树的。对于这个新的运行时，它的大小将永远保持在 10kb 之下。此外，使这些特性变为“可摇树的”后，我们就可以提供更多的内置特性，同时还不会增加网络负载——如果没使用到这些特性的话。
更快：在初步基准测试中，我们看到全面的性能提升高达100％，包括原始Virtual DOM安装和修补（我们从Inferno学到了很多技巧，包括最快的Virtual DOM实现），组件实例初始化和数据观察。当您的应用程序启动时，3.0将减少花费一半的JavaScript时间。
Fragments 和 Portal：尽管尺寸减小，但3.0内置支持Fragments（返回多个根节点的组件）和Portals（在DOM的另一部分而不是在组件内部渲染子树）。
改进的插槽(solt)机制：所有编译器生成的插槽现在都是函数，并在子组件的渲染调用期间调用。这样可以确保将插槽中的依赖关系收集为子节点而不是父节点的依赖关系。这意味着：1。当插槽内容发生变化时，只有子节点重新渲染; 2.当父组件重新渲染时，如果其插槽内容没有改变，则子组件不会重新渲染。此更改在组件树级别提供更精确的更改检测，因此会避免很多无用重新渲染！
自定义渲染器（Renderer）API：这个API可以用于创建自定义渲染器，并且不再需要使用自定义修改来分配Vue代码库。这将使像Weex和NativeScript Vue这样的“渲染为原生应用”更容易与Vue本身更改保持同步。它还可以轻松地为各种其他用途创建自定义渲染器。

编译器改进*

TL; DR：摇树友好输出，更多AOT优化，具有更好错误信息和支持source map的解析器。

在使用支持摇树优化的打包器中，使用可选功能的模板将生成使用ES模块语法导入这些功能的代码。因此，未使用的功能将从最终打包的代码中删除（PS：被摇掉）。
由于新的Virtual DOM实现的改进，我们还能够执行更有效的编译时优化，例如静态树提升（static tree hoisting），静态属性提升（static props hoisting），以及为运行时提供一些来自编译器的提示，以此避开子组件的规范过程 (children normalization)，以及VNode创建快速路径等等…
我们计划重写解析器以在模板编译错误中提供位置信息。并且带来对模板source map的支持，并且新的解析器可以作为第三方工具集成的基础，例如eslint-plugin-vueIDE语言服务。

IE11支持*

TL; DR：IE11将受到支持，但将会是另外构建一个版本 (build) 的形式支持，不过这个版本会存在与 Vue 2.x 响应式机制所存在的同样的局限。

新代码库目前仅针对主流浏览器，并假设浏览器支持ES2015。但是，我们知道很多用户在可预见的未来仍然需要支持IE11。对于IE11，大多数的ES2015功能都可以通过转译或者垫片的方式使用，但Proxies除外。我们的计划是使用相同的API实现另一个观察者，不过是基于以前的 Object.defineProperty API；。将使用此观察器变成一个单独的Vue 3.x版本。但是，此构建将受到Vue 2.x的相同更改检测警告的影响，因此与3.x的“现代”构建不完全兼容。我们知道这给第三方库作者带来了一些不便，因为他们需要了解两个不同版本的兼容性，但是当我们到达那个阶段时，我们将确保为此提供明确的指导。

我们将如何完成这些

首先，虽然我们今天（PS：2018-09-30）宣布，但我们还没有确定的时间表。我们目前所知道的是我们将采取的步骤：

1. 征集运行时原型的反馈

这是我们现在所处的阶段。目前，我们已经有一个可以工作的运行时原型，包括新的观察者，Virtual DOM和组件实现。我们邀请了一组有影响力的社区项目的作者为内部变化提供反馈，并希望在继续开发之前确保他们对变化感到满意。我们希望确保生态系统中的重要库在我们发布3.0的同时准备就绪，以便依赖这些项目的用户可以轻松升级（PS：这个大赞）。

2.征集通过RFC的公众反馈

一旦我们对新设计获得一定程度的信心之后，对于每次重大变更，我们将打开一个专门的RFC专题问答，其中包括：

变更范围;
改变背后的思考：我们获得了什么，以及正在进行哪些权衡;
升级路径：是采用完全后向兼容的形式，还是通过植入一个可移除的兼容性层，或者是通过修改代码来升级？

我们将期待来自更广泛社区的公众反馈，以帮助我们确定这些想法。

3.在2.x和2.x-next中引入兼容功能

我们不会忘记2.x！事实上，我们计划使用2.x逐步使用户适应新的变化。我们将通过opt-in适配器逐步将确认的API更改引入2.x. 2.x-next将允许用户尝试新的基于Proxy的观察器。

2.x中的最后一个次要版本将成为LTS，并在3.0发布时继续接收18个月的错误和安全修复程序。

4.Alpha 阶段

接下来，我们将完成3.0的编译器和服务器端渲染部分并开始制作alpha版本。这些主要用于在小型的应用中进行稳定性测试。

5. Beta阶段

在测试阶段，我们的主要目标是更新支持库和工具，如Vue Router，Vuex，Vue CLI，Vue DevTools，并确保它们与新核心一起顺利运行。我们还将与社区的主要第三方库开发者合作，帮助他们为3.0做好准备。

6. RC阶段

一旦我们认为API和代码库稳定，我们将进入API稳定的的RC阶段。在此阶段，我们还将开发“compat build”：包含2.x API兼容层的3.0版本。此版本还将附带一个标记，您可以打开该标记以在应用程序中为2.x API使用情况发出弃用警告。compat构建可用作将应用程序升级到3.0的指南。