前言
工欲善其事，必先利其器 –《论语》
在现在被三大框架摆布的前端畛域，曾经很少有人不晓得 Vue 了。2014 年，前 Google 工程师尤雨溪公布了所谓的渐进式（Progressive）前端利用框架 Vue，其简化的模版绑定和组件化思维给过后还是 jQuery 时代的前端畛域产生了踊跃而深远的影响。Vue 的诞生，造福了那些不习惯 TS 或 JSX 语法的前端开发者。而且，Vue 较低的学习门槛，也让初学者非常容易上手。这也是为什么 Vue 能在短时间内迅速推广的重要起因。从 State of JS 的考察中能够看到，Vue 的知名度靠近 100%，而且整体用户满意度也比拟高。
Vue 既弱小又易学，这是不是意味着 Vue 是一个完满框架呢？很遗憾，答案是否定的。尽管 Vue 的上手门槛不高，灵便易用，然而这种劣势同时也成为了一把双刃剑，为构建大型项目带来了肯定的局限性。很多用 Vue 2 开发过大型项目的前端工程师对 Vue 是又爱又恨。不过，随着 Vue 3 的公布，这些开发大型项目时凸显进去的劣势失去了无效解决，这让 Vue 框架变得十分全能，真正具备了跟“前端框架一哥”React 一争高下的后劲。Vue 3 到底带来了什么重要的新个性呢？本篇文章将对此进行具体介绍。
Vue 概览
Vue 是前 Google 工程师尤雨溪于 2013 年开发、2014 年公布的前端框架。对于 Vue 的具体定义，这里摘抄 Vue 官网里的介绍。
Vue (读音 /vjuː/，相似于 view) 是一套用于构建用户界面的 渐进式框架。与其它大型框架不同的是，Vue 被设计为能够自底向上逐层利用。Vue 的外围库只关注视图层，不仅易于上手，还便于与第三方库或既有我的项目整合。另一方面，当与现代化的工具链以及各种反对类库联合应用时，Vue 也齐全可能为简单的单页利用提供驱动。
渐进式框架
很多人可能不了解渐进式框架（Progressive Framework）的含意。这里简略解释一下。渐进次要是针对我的项目开发过程来说的。传统的软件我的项目开发通常是瀑布流式（Waterfall）的，也就是说，软件设计开发工作通常有明确的工夫线，工作与工作之间有明确的依赖关系，这意味着我的项目的不确定性容忍度（Intolerance to Uncertainty）比拟低。这种开发模式在古代日趋简单而疾速变动的商业情景曾经显得比拟过期了，因为很多时候需要是不确定的，这会给我的项目带来很大的危险。
而渐进式框架或渐进式开发模式则能够解决这种问题。以 Vue 为例：我的项目开始时，性能要求简略，能够用一些比较简单的 API；当我的项目逐步开发，一些公共组件须要形象进去，因而用到了 Vue 的组件化性能；当我的项目变得十分大的时候，能够援用 Vue Router 或者 Vuex 等模块来进一步工程化前端零碎。看到了么，这样一来，开发流程变得十分麻利，不必提前设计整个零碎，只用按需开发，因而能够疾速开发产品原型以及扩大到生产零碎。
框架个性
Vue 是利用模版语法来渲染页面的，这也称做 申明式渲染。Vue 好上手的重要起因也是因为这个，因为它合乎了前端开发者的习惯。例如上面这个例子。
; “ 复制代码 ”)
<div id=”app”> {{message}} </div>
<script>
var app = new Vue({
el: '#app',
data: {message: 'Hello Vue!'}}) </script>
; “ 复制代码 ”)
能够看到，el 指定 Vue 实例绑定的元素，data 中的 message 与 DOM 元素的内容进行绑定。只须要操控 JS 中的数据，HTML 内容也会随之扭转。
另外，Vue 将 HTML、CSS、JS 全副整合在同一个文件 .vue 中，以 组件化利用构建 的形式来组织代码，从语法个性上激励“高内聚、低耦合”的设计理念，让代码组织变得更加正当，晋升了可读性与逻辑性。上面是一个官方网站给出的根底 .vue 文件例子。
; “ 复制代码 ”)
<template>
<p>{{greeting}} World!</p>
</template>
<script> module.exports = {
data: function () { return {greeting: 'Hello'}
}} </script>
<style scoped> p {
font-size: 2em;
text-align: center;} </style>
; “ 复制代码 ”)
组件的骨架（HTML）、款式（CSS）和数据或操作（JS）都在同一个中央，开发者须要思考如何将整个零碎拆分成更小的子模块，或者组件。这对于构建大型项目是十分有帮忙的。
其实，除了上述两个特点，Vue 还有很多其余的实用个性，但限于篇幅的起因，咱们这里不具体解释了。感兴趣的读者能够去[官方网站深刻理解。
框架毛病
没有什么货色是完满的，Vue 同样如此。当 Vue 的知名度和用户量一直减少时，一些前端开发者开始埋怨 Vue 的灵活性太高导致构建大型项目时短少束缚，从而容易产生大量 bug。甚至应用 Vue 生态圈里的状态管理系统 Vuex 也无奈无效解决。对于 Vue 是否适宜大型项目的问题，网上有不少争执，甚至尤大自己都亲自上知乎参加了探讨（吃瓜传送门）。
主观来讲，Vue 尽管具备较低的上手门槛，但这并不意味着 Vue 不适宜开发大型项目。然而，咱们也必须抵赖大型项目通常要求较高的稳定性和可维护性，而 Vue 框架较高的灵活性以及短少足够的束缚让其容易被经验不足的前端开发者所滥用，从而产生臭不可闻的、难以直视的“屎山”代码。其实，代码可维护性并不强制要求较低的灵活性与自由度，只是这种自在可能会对我的项目的整体稳固带来危险。
Vue 作者尤雨溪其实很早就留神到这个问题，因而才会打算从底层重构 Vue，让其更好的反对 TypeScript。这就是 2020 年 9 月公布的 Vue 3。
Vue 3 新个性
Vue 3 有很多实用的新个性，包含 TS 反对、组合式 API 以及 Teleport 等等。本文不是对于 Vue 3 的参考文，因而不会介绍其中全副的新个性，咱们只会关注其中比拟重要的个性，尤其是能增强代码束缚的 TypeScript（简称 TS）。
TS 反对
技术上来说，TS 反对并不是 Vue 3 的新个性，因为 Vue 2 版本就曾经可能反对 TS 了。但 Vue 2 版本的 TS 反对，是通过 vue-class-component 这种糟糕的装璜器形式来实现的。笔者对“糟糕”这个评估深有体会，因为笔者已经迁徙过 Vue 2 版本的生产环境我的项目，最初发现收益并不高：语法有很大的不同，花了大量工夫来重构，发现只晋升了一些代码的规范性，然而代码整体变得更臃肿了，可读性变得更差。
而在 Vue 3 中，TS 是原生反对的，因为 Vue 3 自身就是用 TS 编写的，TS 成为了 Vue 3 中的“一等公民”。TS 反对在我看来是 Vue 3 中最重要的个性，特地是对构建大型前端我的项目来说。为什么说它重要？因为 TS 无效的解决了前端工程化和规模化的问题，它在代码标准和设计模式上极大的进步代码品质，进而加强零碎的可靠性、稳定性和可维护性。对于 TS 的重要性，笔者在该公众号前一篇文章《为什么说 TypeScript 是开发大型前端我的项目的必备语言》曾经做了具体介绍，感兴趣的读者能够持续深刻浏览一下。
Vue 3 定义了很多 TS 接口（Interface）和类型（Type），帮忙开发者定义和束缚各个变量、办法、类的品种。上面就是一个十分根底的例子。
; “ 复制代码 ”)
import {defineComponent} from ‘vue’
// 定义 Book 接口
interface Book {
title: string author: string year: number
} // defineComponent 定义组件类型
const Component = defineComponent({
data() { return {
book: {
title: 'Vue 3 Guide',
author: 'Vue Team',
year: 2020 } as Book // as Book 是一个断言}
}
})
; “ 复制代码 ”)
上述代码通过 defineComponent 定义了组件类型，而在 data 里定义了外部变量 book，这个是通过接口 Book 来定义的。因而，其余组件在援用该组件时，就可能主动推断出该组件的类型、外部变量类型，等等。如果援用方与被援用方的任何一个接口、变量类型不统一，TS 就会抛错，让你能够提前躲避很多谬误。
尽管 Vue 3 在传统定义 Vue 实例形式中（Options API）可能很好的反对 TS，然而咱们更举荐用 TS 配合另一种新的形式来定义 Vue 实例，也就是接下来要介绍的组合式 API（Compositional API）。
组合式 API
https://segmentfault.com/a/1190000039278732?utm_source=tag-newest
https://segmentfault.com/a/1190000039291984?utm_source=tag-newest
组合式 API 的诞生是来自于大型项目中无奈优雅而无效地复用大量组件的问题。如果你曾经理解 Vue，你或者应该晓得之前版本的 Vue 实例中蕴含很多固定的 API，包含 data、computed、methods 等。这种定义形式有个比较突出的问题：它将 Vue 实例中的性能依照类型的不同别离固定在不同的 API 中，而没有依据理论的性能来划分，这将导致一个简单组件中的代码变得十分散乱，就像如下这张图一样。