Vue Amsterdam 2023 于 2 月 8 日至 10 日舉行（Vue Amsterdam 是世界上最大的 Vue.js 會議），這是 Vue.js 作者尤雨溪三年以來首次參加面對面 Vue 活動。在會議中，尤雨溪透露了 Vue 的一些令人興奮的新功能，并提供了 2023 路線圖的更新。

概述：

• Vue 2 將于 2023 年 12 月 31 日結(jié)束支持，達到生命周期結(jié)束（EOL）；
• Reactivity Transform 將從 v3.4 中的 Vue 核心中移除；
• 響應式 props 解構(gòu)；
• Suspense 將于 Q2 確定；
• 更多 SSR 改進，包括懶水合、v-ssr-only；
• Vapor mode：一種可選擇的以性能為導向的編譯模式。

Vue 2 EOL

為了彌補個和主要版本之間的差距，Vue 2.7 添加了內(nèi)置的 Composition API 支持以及 <script setup> 功能。這也是為了減少升級到 Vue 3 的工作量。

最新的 Vue 2.7 是最終的 2.x 版本。這意味著 Vue 2 將不再計劃發(fā)布新功能。但是，直到今年年底，它仍將獲得對錯誤修復和安全修復的必要支持。

2023 年 12 月 31 日之后，Vue 團隊將不再維護 Vue 2。官方文檔[1]中有相關的詳細說明，其中包括如果不打算遷移到 Vue 3 可以怎么做。其中一個選項是查看 HeroDevs[2]，因為它們將支持 Vue 2。

放棄 Reactivity Transform

當使用 ref 使某些對象具有響應式時，可以為其分配一個新值并通過 .value 訪問它：

const count = ref(0)
console.log(count.value)   // 0

本質(zhì)上，Reactivity Transform[3] 允許我們在編寫響應式代碼時省略 ??.value??。默認情況下，它是禁用的，因為它仍然是 RFC 中的實驗性功能。

Vue 團隊已經(jīng)決定在未來幾個月內(nèi)逐步淘汰它。原因之一是 DX 改進非常有限。沒有 ??.value??，響應式變量和非響應式變量之間的區(qū)別就丟失了，這不可避免地引入了另一種心智負擔。

如果你現(xiàn)有的代碼庫中使用了 Reactivity Transfom，將從 v3.3 開始收到棄用警告。到 v3.4 時，它將完全從 Vue 核心包中移除。但是，仍然可以從 Vue macros[4] 中使用它。

注：目前 Vue.js v3.3 已經(jīng)處于 v3.3.0-alpha.4 階段，距離正式發(fā)布又近了一步。

響應式 props 解構(gòu)

盡管 Reactive Transform 沒有通過 RFC，但它還是產(chǎn)生了一些有用的功能，這就是響應式 props 解構(gòu)。

目前，當我們像這樣使用 defineProps 解構(gòu) props 時，響應式會丟失：

const { count } = defineProps<{ count: number }>();

因此，要么需要使用 props.x，要么使用 toRefs：

const props = defineProps<{ count: number }>(); 
const { count } = toRefs(props);

使用響應式 props 解構(gòu)，我們可以忘記這些并以最常見的 JS 方式簡單地解構(gòu)它，甚至可以像這樣分配一個默認值：

const { count = 1 } = defineProps<{ count: number }>();

注： 目前，響應式 props 解構(gòu)是 Reactivity Transform RFC 的一部分，但正如尤雨溪在會議中提到的那樣，它可能會被拆分成一個單獨的功能，并且很可能會作為一個新功能包含在未來的 Vue 版本中。

SSR 改進

在與 Nuxt 團隊的協(xié)調(diào)下，Vue 團隊將在第二季度專注于 SSR 的改進。這包括完成目前仍處于實驗模式的 Suspense 功能。

簡單來說，Suspense 是一個內(nèi)置組件，它提供了一種在等待嵌套異步組件解析時顯示頂層加載/錯誤狀態(tài)的解決方案。沒有它，我們必須分別處理每個異步組件的狀態(tài)。

除此之外，可以期待看到引入懶水合作用。這個想法是讓我們定義自定義策略，以了解我們希望異步組件樹如何水合，例如，僅在某些組件滾動到視圖中時才水合它們。

v-ssr-only 是 Vue 團隊正在探索的另一個新特性。這將允許我們將特定模板聲明為僅服務端渲染。當對一個模板進行動態(tài)綁定時，這會很有用，因為該模板中的數(shù)據(jù)是從數(shù)據(jù)庫中提取的，但在客戶端它永遠不會改變。在這種情況下，當客戶端構(gòu)建完成時，編譯可以以不同的方式完成，忽略所有動態(tài)綁定，這樣它就不必在水合作用期間做任何工作。

Vapor Mode

在此之前，關于 Vue 團隊正在探索的這個看似令人興奮的新功能的信息并不多。今年年初，尤雨溪在他的 2023 新年文章中簡要介紹了 Vapor Mode：

受 solid.js 的啟發(fā)，Vapor Mode 提供了另外一種編譯策略。它將 Vue SFC 編譯成 JavaScript 輸出，與當前基于虛擬 DOM 的輸出相比，該輸出具有更高的性能、使用更少的內(nèi)存并且需要更少的運行時支持代碼。

聽起來很酷，所有這些都可以在不對現(xiàn)有代碼庫進行太多更改的情況下完成。

在 Vue Amsterdam 的演講中，有一些關于如何選擇加入 Vapor Mode 的新細節(jié)。有兩種方法可以做到這一點：

（1）在組件級別通過包含 .vapor? 文件名后綴，例如 Counter.vapor.vue：

<script setup>
import Counter from './Counter.vapor.vue' 
</script>

<template>
  <Counter>
</template>

（2）在應用級別，通過刪除 VDOM interop：

import { createApp } from 'vue/vapor'
import App from './App.vapor.vue'

createApp(App).mount('#app')

使用 Vapor Mode，組件可以被編譯成一個函數(shù)調(diào)用，我們可以不再擔心擁有太多組件和創(chuàng)建這些組件實例所帶來的內(nèi)存開銷。

一開始，Vapor Mode 旨在僅支持 Vue API 的一個子集（<script setup> 和 Composition API）以獲得最佳性能。因此，計劃是使 Vapor Mode 與任何其他現(xiàn)有的非 Vapor Mode 完全兼容。實現(xiàn)自由混合使用（在非 Vapor 組件中使用 Vapor 組件，反之亦然）也是 Vue 團隊的最終目標。我們可能會在第三季度至第四季度看到這一特性。

相關鏈接

[1]官方文檔: https://v2.vuejs.org/lts/。

[2]HeroDevs: https://www.herodevs.com/support/vue。

[3]Reactivity Transform: https://vuejs.org/guide/extras/reactivity-transform.html。

[4]Vue macros: https://vue-macros.sxzz.moe/。