另有几个月间隔vue2的初次宣布就满3年了，而vue的作者尤雨溪也在客岁岁终宣布了关于vue3.0的设想，假如不出不测，我们将在本年的某个时刻点见证Vue3.0的宣布，虽然头几天在《StateOfJS: 2018年JavaScript生态圈趋向报告》一文中我们看到如今Vue的运用者比React还少了不少，但在Github上Vue的star数已逾越React，可见用户对Vue的喜欢，那行将宣布的Vue3又有什么新特征呢？我们一同来看看吧！

Vue 3.0 已在原型设想阶段了，而且我们已完成了一个与 2.0 的特征近乎相称的运行时了。下文中列出的许多条目，要么已完成了，要么已确承认完成。那些还未完成或许仍在探究阶段的条目会用一个“*”标记

机能提拔

一句话简介：更玲珑，更疾速；支撑摇树优化；支撑 Fragments 和跨组件衬着；支撑自定义衬着器。

• 更玲珑：这份新的代码库在设想之初就斟酌到了对“摇树优化 (tree-shaking)”的友爱。那些如内置组件 (<transition>、<keep-alive>) 、运行时东西性指令（v-model）等特征将变成按需导入，所以也是“可摇树的”。关于这个新的运行时，它的大小将永久坚持在 10kb 之下。别的，使这些特征变成“可摇树的”后，我们就可以供应更多的内置特征，同时还不会增添网络负载——假如没运用到这些特征的话。

摇树优化，是一种在打包时去除没用到的代码的优化手腕，谷歌有一篇教程可以相识下: Reduce JavaScript Payloads with Tree Shaking

• 更快：在前期的基准测试中，我们看到团体机能有了一倍的提拔，包含假造DOM的挂载和打补丁(patching，指更新——译注) 的速率（我们从 Inferno 那边学了好些个技能过来——Inferno 是如今速率最快的假造DOM完成），以及组件实例化速率和数据监测的机能。在 3.0 中，你运用的启动时刻将缩减一半。
• 支撑 Fragments 和 Portal：虽然体积更小了，但 3.0 还将内置对 Fragments (即许可组件具有多个根节点) 和 Portal (即许可在 DOM 的其他位置举行衬着，而不是组件内部) 的支撑。

关于 Portal ，你可以将其理解为跨组件衬着或许异地衬着，vue-portal 是一个第三方完成，可以相识一下；Fragments 特征也有一个第三方库，但译者以为这个库的内部完成不够完美，叫做 vue-fragments，感兴趣可以相识一下。

• 加强的 slot 机制：一切由编译器天生的 slot 都将是函数情势，并且在子组件的 render 函数被挪用历程当中才被挪用 (译注：如今只需 scoped slot 才是函数情势，其衬着的机遇也是在父组件的衬着举行时）。这使得 slot 中的依靠项 (即数据——译注) 将被作为子组件的依靠项，而不是如今的父组件；从而意味着：1）当 slot 的内容发作更改时，只需子组件会被从新衬着；2）当父组件从新衬着时，假如子组件的内容未发作更改，子组件就没必要从新衬着。这类机制的转变，可以供应更准确的更改探测，也就可以消弭没必要的重衬着。
• 支撑自定义衬着器 (Renderer)：这个 API 可以用来建立自定义的衬着器，它将作为“一等国民”涌现，到时不再须要 fork 一份 Vue 的代码来经由历程修正完成自定义。这个 API 的到来，将使得那些如 Weex 和 NativeScript 的“衬着为原生运用”的项目坚持与 Vue 的同步更新变得越发轻易。除此以外，还将使得那些为了种种用处而建立自定义衬着器变得极为轻易。

编译器相干的提拔 *

• 假如采纳的是支撑“摇树优化”的打包器，模板中运用到的那些可选特征，在天生的代码中将经由历程 ES 的模块语法导入；而在打包后的文件中，那些没用到的可选特征就会被“摇掉”。
• 由于新的假造 DOM 完成所带来的提拔，我们可以实行一些越发高效的编译耗时优化，如静态树提拔(static tree hoisting)、静态属性提拔(static props hoisting)；以及为运行时供应一些来自编译器的提醒，以此避开子组件的范例历程 (children normalization)；供应 VNode 疾速建立途径； 等等。
• 我们设想对解析器举行重写，以便在对模板举行编译发作毛病时，可以供应毛病发作的位置信息；除此以外还可以带来对模板的 source map 支撑；还可以支撑第三方东西如 eslint-plugin-vue 和 IDE 的言语效劳 (language services) 特征。

API 更改

一句话引见：除衬着函数 API 和 scoped-slot 语法以外，其他均坚持稳定或许将经由历程别的构建一个兼容包来兼容 2.x。

• 模板语法的 99% 将坚持稳定。除了 scoped slot 语法可以会有一些微调以外，我们还没有任何其他针对模板的更改设想。
• 3.0 版本将原生地支撑基于 class 的组件，而且无需借助任何编译及种种 stage 阶段的特征，以此供应优越的编写体验。许多现有的 (组件) 设置项将有对应的合理的 class 版本的 API。种种 stage 阶段的特征，如 class 的静态字段和装潢器 (decorator) 等依然可以挑选性地运用，以此加强编写体验。别的，团体的 API 在设想时也将斟酌 TypeScript 的范例揣摸特征。3.x 的代码库自身将用 TypeScript 来编写，并供应加强的 TypeScript 支撑。(就是说，TypeScript 的运用与否依然是团体可选的)
• 2.x 系列的基于对象的组件花样仍将受支撑，不过会在内部将其转换为一个相应的 class。
• 依然支撑 Mixins。*
• 为了防止在装置插件时形成对 Vue 的运行时的修正，顶层 API 可以会做一个大的翻修。到时，插件的作用域将只局限到详细的一个组件树，使得对那些依靠于某些详细插件的组件的测试变得轻易，也会使得在同一个页面中挂载多个运用差别插件——但运用同一个 Vue 运行时——的 Vue 运用变成可以。*
• 函数式组件将支撑纯函数的誊写情势——不过，如许的话异步组件就须要经由历程一个辅助性函数来显式地建立了。
• 更改最大的部份将是衬着函数 (render) 中的假造DOM的花样。我们如今正在网络主流的第三方库的作者们的回响反映，在对这些更改有了更多的自信心以后，我们还会将更多的细节暴光；虽然更改较大，然则只需你没在你的运用中重度运用手写的衬着函数 (不是指 JSX)，那末更改以后的晋级应该会比较轻易。

代码重构

一句话引见：更优秀的内部模块解耦；TypeScript；更容易于孝敬的代码库。

在从零最先编写 3.0 之初，“到达越发清楚和更容易保护的架构，迥殊是为了让代码的孝敬变得轻易”就是我们的目的。为了对复杂性举行断绝，我们将一些内部功用拆分为了多个零丁的包。比方，observer 模块将成为一个零丁的包，具有本身对外的 API 和本身的测试用例；不过请注意，这不会对框架级的 API 形成影响——你不须要别的手动从多个包里导入许多小件小件的模块就可以运用 Vue，相反 Vue 的终究包会事前装配好这些内部包。

别的，代码库如今改为了用 TypeScript 编写；虽然这会使得“闇练TypeScript”成为对新代码库举行孝敬的一个前置请求，不过我们置信有范例信息合营 IDE 的支撑，关于一个新的孝敬者来讲，要做出有意义的孝敬，实际上反而会越发轻易。

将 observer 和 scheduler 解耦为离开的两个包后，我们还可以拿一些替换的完成对这两个包举行置换实验。比方，我们可以完成一个兼容 IE11、API 也雷同的 observer；或许完成别的一种应用 requestIdleCallback 来在长耗时的更新中产出工作效果到浏览器的 scheduler。

重写假造DOM (Virtual DOM Rewrite)

跟着假造 DOM 重写，我们可以期待更多的 编译时（compile-time）提醒来削减 运行时（runtime）开支。重写将包含更有用的代码来建立假造节点。

优化插槽天生(Optimized Slots Generation)

在当前的 Vue 版本中，当父组件从新衬着时，其子组件也必需从新衬着（11月20日更新：这句话是不严谨的，异常轻易发生误导，我以为有必要申明一下： 2.0 组件的从新衬着就是组件粒度的，除非修正的数据是子组件的 props，才会触发子组件的从新衬着。援用自：https://juejin.im/pin/5bf28dd…）。 运用 Vue 3 ，可以零丁从新衬着父组件和子组件。

静态树提拔(Static Tree Hoisting)

运用静态树提拔，这意味着 Vue 3 的编译器将可以检测到什么是静态组件，然后将其提拔，从而降低了衬着本钱。它将可以跳过未全部树结构打补丁的历程。

静态属性提拔（Static Props Hoisting）

另外，我们可以期待静态属性提拔，个中 Vue 3 将跳过不会转变节点的打补丁历程。

基于 Proxy 的观察者机制

如今，Vue 的回响反映体系是运用 Object.defineProperty 的 getter 和 setter。 然则，Vue 3 将运用 ES2015 Proxy 作为其观察者机制。 这消弭了之前存在的正告，使速率更加，并节省了一半的内存开支。

为了继承支撑 IE11，Vue 3 将宣布一个支撑旧观察者机制和新 Proxy 版本的构建。

兼容 IE 11 *

一句话引见：IE 11 将遭到支撑，但将会是别的构建一个版本 (build) 的情势支撑，不过这个版本会存在与 Vue 2.x 相应式机制所存在的一样的局限。

新的代码库如今只针对主流浏览器，而且我们假定他们都支撑 ES2015。然则，哎，我们也晓得在可预感的将来另有许多用户依然须要支撑 IE11。除了 Proxy 外，大多数 ES2015 的特征都可以用转译或许垫片的体式格局在 IE11 中运用。我们的设想是别的零丁完成一个具有一样 API 的替换性 observer，不过是基于老式的 Object.defineProperty API；然后再经由历程零丁构建一个运用这个完成的 Vue 3.x 版本 (build) 举行宣布，不过这个零丁的版本照样会有 Vue 2.x 在更改探测方面所存在的题目，所以它实在并非一个完整兼容 3.x 的一个版本。我们也意想到这会给第三方库的作者们带来某些不方便，由于他们须要斟酌两个差别版本之间的兼容性题目，不过当我们真的推进到谁人阶段时，当时我们肯定会确保供应一份清楚的指点。

监测机制

一句话引见：越发周全、精准、高效；更具可调试性的相应跟踪；以及可用来建立相应式对象的 API。

3.0 将带来一个基于 Proxy 的 observer 完成，它可以供应掩盖言语 (JavaScript——译注) 全局限的相应式才能，消弭了当前 Vue 2 系列中基于 Object.defineProperty 所存在的一些局限，如：

• 对属性的增加、删除行动的监测
• 对数组基于下标的修正、关于 .length 修正的监测
• 对 Map、Set、WeakMap 和 WeakSet 的支撑

别的这个新的 observer 另有以下特征：

• 公然的用于建立 observable (即相应式对象——译注) 的 API。这为小型到中型的运用供应了一种轻量级的、极为简朴的跨组件状况治理解决计划。（译注：在这之前我们可以经由历程别的 new Vue({data : {…}}) 来建立这里所谓的 observable；别的，实在 vuex 内部也是用这类体式格局来完成的）
• 默以为惰性监测（Lazy Observation）。在 2.x 版本中，任何相应式数据，不管它的大小怎样，都邑在启动的时刻被监测。假如你的数据量很大的话，在运用启动的时刻，这就可以形成可观的机能斲丧。而在 3.x 版本中，只需运用的初始可见部份所用到的数据会被监测，更不用说这类监测计划自身实在也是越发快的。
• 更精准的更改关照。举个例子：在 2.x 系列中，经由历程 Vue.set 强迫增加一个新的属性，将致使一切依靠于这个对象的 watch 函数都邑被实行一次；而在 3.x 中，只需依靠于这个详细属性的 watch 函数会被关照到。
• 不可变监测对象（Immutable observable）：我们可以建立一个对象的“不可变”版本，以此来阻挠对他的修正——包含他的嵌套属性，除非体系内部暂时解除了这个限定。这类机制可以用来凝结通报到组件属性上的对象和处在 mutation 局限外的 Vuex 状况树。
• 更优越的可调试才能：经由历程运用新增的 renderTracked 和 renderTriggered 钩子，我们可以准确地追踪到一个组件发作重衬着的触发机遇和完成机遇，及其缘由。

宣布时刻

没必要太甚忧郁，最少还能缓半年。

参考泉源：

Plans for the Next Iteration of Vue.js

[[译] 尤雨溪：Vue 3.0 设想](
https://juejin.im/post/5bb719…