几个月后第一个发布vue2已经3年了，而vue的作者尤雨熙也在去年年底发布了vue3.0的计划。见证Vue3.0在这个时间点的发布。虽然我们在前几天的文章《StateOfJS: 2018年JavaScript生态圈趋势报告》中看到，Vue的用户数远不及React，但是Vue在Github上的star数已经超过了React。可见用户对Vue的喜爱，那么即将到来的Vue3有哪些新特性呢？我们一起来看看！Vue3.0已经处于原型设计阶段，我们已经实现了一个与2.0具有几乎相同功能的运行时。下面列出的许多项目要么已经实施，要么已确认可以实现。那些还没有实现或者还在探索阶段的条目会被标上“*”Performanceimprovement一句话介绍：更小，更快；支持tree-shaking优化；支持Fragments和跨组件渲染；支持自定义渲染器。更小：新的代码库是从头开始设计的，以支持tree-shaking友好。内置组件（、）、运行时检测指令（v-model）等功能将按需导入，因此也是“tree-shakable”。对于这个新的运行时，它的大小将始终保持在10kb以下。此外，通过使这些功能“tree-shakable”，如果不使用这些功能，我们可以在不增加网络负载的情况下提供更多内置功能。treeshakingoptimization是一种在打包时去除无用代码的优化方法。谷歌有一个教程可以学习：ReduceJavaScriptPayloadswithTreeShakingisfaster：在之前的基准测试中，我们看到整体性能有所提高。虚拟DOM挂载和修补速度提高了一倍（我们从Inferno学到了一些技巧——Inferno是目前最快的虚拟DOM实现），以及组件实例化速度和数据监控的性能。在3.0中，您的应用程序的启动时间将减少一半。对Fragments和Portal的支持：虽然更小，但3.0也将内置对Fragments（即允许组件具有多个根节点）和Portal（即允许在DOM的其他地方渲染，而不是在组件内部渲染）的支持.关于Portal，可以理解为跨组件渲染或者异地渲染。vue-portal是第三方实现，可以了解一下；Fragmentsfeature还有一个第三方库，不过译者觉得这个库内部实现还不完善，叫Vue-fragments，有兴趣的可以找找看。增强的插槽机制：编译器生成的所有插槽都会以函数的形式出现，在调用子组件的render函数时调用，而父组件的渲染正在进行中）。这使得slot中的依赖（即data—annotation）会被用作子组件的依赖，而不是当前的父组件；也就是说：1）当slot的内容发生变化时，只会重新构建子组件Rendering；2）父组件重新渲染时，如果子组件的内容没有变化，则子组件不需要重新渲染。这种机制上的变化可以提供更准确的变化检测并消除不必要的重新渲染。支持自定义渲染器（Renderer）：该API可用于创建自定义渲染器，它将以“一等公民”的身份出现，无需通过修改fork一段Vue代码来实现自定义。该API的到来将使Weex和NativeScript等“呈现为原生应用程序”的项目更容易与Vue保持更新。此外，对于那些为各种目的创建自定义渲染器的人来说，这将变得非常容易。编译器相关的改进*如果您使用支持“摇树优化”的打包器，模板中使用的可选功能将通过生成代码中的ES模块语法导入；而在打包文件中，那些没有用到的可选特性会被“抖掉”。由于新的虚拟DOM实现带来的改进，我们可以进行一些更高效的编译耗时优化，比如静态树提升（statictreehoisting）、静态道具提升（staticpropshoisting）；编译器提示避免子组件的子规范化过程；提供VNode快速创建路径；等等。我们计划重写解析器，以便在编译模板时发生错误时，它可以提供有关错误位置的信息；此外，它还可以为模板带来sourcemap支持；它还可以支持第三方工具，例如eslint-plugin-vue和IDE的语言服务功能。API变化一句话：除了渲染函数API和scoped-slot语法，其余不变或通过另建兼容包兼容2.x。99%的模板语法将保持不变。除了可能对作用域插槽语法进行一些调整外，我们没有计划对模板进行任何其他更改。3.0版本将原生支持基于类的组件，无需任何编译和各种stage特性，提供良好的编写体验。许多现有的（组件）配置项都会有对应的合理的API类版本。仍然可以选择使用各种舞台功能，例如类静态字段和装饰器，以增强创作体验。此外，整个API的设计将考虑到TypeScript的类型推断功能。3.x代码库本身将使用增强型TypeScript支持的TypeScript编写。（也就是说，TypeScript的使用仍然完全是可选的。）2.x系列的基于对象的组件格式仍将受到支持，但会在内部转换为相应的类。仍然支持混合。*为了避免在安装插件时对Vue进行运行时修改，顶层API可能会进行大修。届时，插件的范围将被限制在一个特定的组件树中，可以更方便地测试依赖于某些特定插件的组件，也可以使用不同的方式挂载多个插件。同一页面上的插件——但使用相同的Vue运行时——Vue应用程序成为可能。*函数式组件将支持纯函数的书写形式——然而，在这种情况下，异步组件需要通过辅助函数显式创建。最大的变化将是渲染函数中虚拟DOM的格式。我们目前正在收集主流第三方库作者的反馈。在我们对这些变化更有信心之后，我们会公开更多的细节；虽然变化比较大，但只要你不是在你的应用程序中适度大量使用手写渲染函数（不是指JSX），那么变化后的升级应该会更容易一些。一句话介绍代码重构：更好的内部模块解耦；打字稿；更容易贡献代码库。在从头开始编写3.0之初，“实现更清洁和更易于维护的架构，尤其是让代码贡献更容易”是我们的目标。为了隔离复杂性，我们将一些内部功能拆分为单独的包。例如，观察者模块将是一个单独的包，有自己的外部API和自己的测试用例；但是，请注意，这不会影响框架级别的API——您不需要手动导入许多小块模块就可以使用Vue，而是Vue的最终包会预先连接这些内部包。此外，代码库现在是用TypeScript编写的；虽然这会使“TypeScript熟练程度”成为为新代码库做出贡献的先决条件，但我们认为将类型信息与IDE支持相结合对于新贡献者来说是必不可少的。也就是说，做出有意义的贡献实际上更容易。将observer和scheduler解耦成两个独立的包后，我们还可以使用一些替代实现对这两个包进行替换实验。例如，我们可以实现一个兼容IE11且具有相同API的观察者；或者实施另??一个调度程序，该调度程序使用requestIdleCallback在长期更新期间为浏览器生成工作结果。重写虚拟DOM（VirtualDOMRewrite）通过重写虚拟DOM，我们可以期待更多的编译时（compile-time）提示来减少运行时（runtime）开销。重写将包括更有效的代码来创建虚拟节点。OptimizedSlotsGeneration（优化插槽生成）在当前版本的Vue中，当父组件重新渲染时，其子组件也必须重新渲染（11月20日更新：这句话不严谨，非常容易误导，我觉得有必要说明一下：2.0组件的重新渲染是在组件粒度上，除非修改的数据是子组件的props，才会触发子组件的重新渲染。引用自:https://juejin.im/pin/5bf28dd...)。使用Vue3，可以独立重新渲染父组件和子组件。StaticTreeHoisting使用静态树提升，这意味着Vue3的编译器将能够检测到什么是静态组件然后将其提升，从而降低渲染成本。它将能够跳过修补整个树结构。StaticPropsHoisting此外，我们可以期待StaticPropsHoisting，其中Vue3将跳过不更改节点的修补过程。基于代理的观察者机制目前，Vue的反应式系统使用Object.definePropertygetters和setters。但是，Vue3将使用ES2015Proxy作为其观察者机制。这消除了先前存在的警告，速度加倍，并将内存开销节省了一半。为了继续支持IE11，Vue3将发布一个支持旧观察者机制和新Proxy版本的构建。兼容IE11*一句话：IE11会被支持，但是会以另一种构建的形式支持，但是这个版本会有和Vue2.x响应机制一样的限制。新的代码库目前只针对主流浏览器，我们假设它们都支持ES2015。但是，嘿，我们也知道在可预见的未来，许多用户仍然需要支持IE11。除了Proxy之外，大多数ES2015功能都可以在IE11中使用转译器或填充程序使用。我们的计划是单独实现一个具有相同API的替代观察者，但基于老式的Object.definePropertyAPI；Vue的版本在变更检测方面仍然存在Vue2.x的问题，所以不是一个完全兼容3.x的版本。我们也意识到这会给第三方库作者带来一些不便，因为他们需要考虑两个不同版本之间的兼容性问题，但是当我们确实推进到那个阶段时，我们一定会确保提供明确的指南.监测机制一句话介绍：更全面、更准确、更高效；更可调试的响应跟踪；以及可用于创建响应对象的API。3.0将带来基于Proxy的观察者实现，可以提供覆盖语言（JavaScript—annotation）的全方位响应能力，消除了目前Vue2系列中Object.defineProperty的一些局限性，例如：的属性监控添加和删??除操作。基于下标的数组修改。监控.length修改。支持Map、Set、WeakMap和WeakSet。此外，这个新的观察者还具有以下特点：公开用于创建可观察对象（即响应式对象-注解）的API。这为管理中小型应用程序的组件状态提供了一个轻量级且极其简单的解决方案。（译注：在此之前，我们可以通过另一个newVue({data:{...}});在这里创建所谓的observable；另外，其实vuex内部也是这样实现的）默认是lazy监控（LazyObservation）。在2.x版本中，任何反应数据，无论其大小，都将在启动时被监控。如果您的数据量很大，这会在应用程序启动时造成相当大的性能开销。在3.x版本中，只会监控应用程序最初可见部分使用的数据，更不用说监控解决方案本身实际上更快了。更准确的更改通知。例如：在2.x系列中，通过Vue.set添加一个新的属性，会导致所有依赖这个对象的watch函数执行一次；而在3.x中，只有那些依赖于这个特定属性的watch函数才会被通知。不可变的可观察对象：我们可以创建一个对象的“不可变”版本以防止修改它——包括它的嵌套属性——除非系统在内部暂时解除这个限制。这种机制可用于冻结传递给组件props的对象和突变范围之外的Vuex状态树。更好的可调试性：通过使用新的renderTracked和renderTriggered钩子，我们可以准确地跟踪组件重新渲染发生的时间、完成时间以及原因。发布时间不用太担心，至少可以推迟半年。参考来源：PlansfortheNextIterationofVue.js[[翻译]游于溪：Vue3.0计划](https://juejin.im/post/5bb719...
