[譯] 尤雨溪：Vue 3.0 計劃

原文：
作者：Evan You（尤雨溪） 發表時間：Sep 30, 2018
轉載請寫明出處：https://blog.lgdsunday.club/2018/10/10/Vue 3.0 plan/

計劃下一次迭代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 實現的許多限制：

1. 檢測屬性新增/刪除（PS：是不是意味著我們不需要再使用Vue.set()了？）
2. 檢測陣列索引的變化和長度length的變化
3. 支援Map，Set，WeakMap和WeakSet

新的觀察者還具有以下特徵：

1. 用於建立可觀察物件（observable響應式物件）的公開API。這為中小規模場景提供了輕量級，簡單的跨元件狀態管理解決方案。
2. 預設惰性監測（Lazy Observation）。在2.x中，任何被動資料，無論其大小，都會在啟動時被觀察到。如果您的資料集很大，這可能會導致應用啟動時出現明顯的效能開銷。在3.x中，只需要觀察用於渲染應用程式最初可見部分的資料，這會讓整個的檢測效能提升很多。
3. 更精確的更改通知。例如：在2.x中，使用Vue.set強制新增新屬性將導致依賴於物件的所有觀察者都被重新計算。在3.x中，只有依賴於該特定屬性的觀察者才會收到通知。
4. 不可變的observables：我們可以建立一個物件的“不可變”版本，即使在巢狀屬性上也可以防止突變，除非系統在內部暫時解鎖它。此機制可用於防止props或Vuex狀態樹以外的變化。
5. 更好的除錯功能：我們可以精確地跟蹤使用新增的 renderTracked和renderTriggeredhook 跟蹤或觸發元件重新呈現的時間和原因：

其他執行時的改進

TL; DR：更小，更快，支援搖樹最佳化，支援 Fragments 和跨元件渲染，自定義渲染器API。

1. 更小：新的程式碼庫從一開始就考慮到對搖樹最佳化（tree-shaking）的友好。現在，可動態按需匯入內建元件（，）和執行時工具性指令（v-model）等功能，所有也是可搖樹的。對於這個新的執行時，它的大小將永遠保持在 10kb 之下。此外，使這些特性變為“可搖樹的”後，我們就可以提供更多的內建特性，同時還不會增加網路負載——如果沒使用到這些特性的話。
2. 更快：在初步基準測試中，我們看到全面的效能提升高達100％，包括原始Virtual DOM安裝和修補（我們從Inferno學到了很多技巧，包括最快的Virtual DOM實現），元件例項初始化和資料觀察。當您的應用程式啟動時，3.0將減少花費一半的JavaScript時間。
3. Fragments 和 Portal：儘管尺寸減小，但3.0內建支援Fragments（返回多個根節點的元件）和Portals（在DOM的另一部分而不是在元件內部渲染子樹）。
4. 改進的插槽(solt)機制：所有編譯器生成的插槽現在都是函式，並在子元件的渲染呼叫期間呼叫。這樣可以確保將插槽中的依賴關係收集為子節點而不是父節點的依賴關係。這意味著：1。當插槽內容發生變化時，只有子節點重新渲染; 2.當父元件重新渲染時，如果其插槽內容沒有改變，則子元件不會重新渲染。此更改在元件樹級別提供更精確的更改檢測，因此會避免很多無用重新渲染！
5. 自定義渲染器（Renderer）API：這個API可以用於建立自定義渲染器，並且不再需要使用自定義修改來分配Vue程式碼庫。這將使像和這樣的“渲染為原生應用”更容易與Vue本身更改保持同步。它還可以輕鬆地為各種其他用途建立自定義渲染器。

編譯器改進*

TL; DR：搖樹友好輸出，更多AOT最佳化，具有更好錯誤資訊和支援source map的解析器。

1. 在使用支援搖樹最佳化的打包器中，使用可選功能的模板將生成使用ES模組語法匯入這些功能的程式碼。因此，未使用的功能將從最終打包的程式碼中刪除（PS：被搖掉）。
2. 由於新的Virtual DOM實現的改進，我們還能夠執行更有效的編譯時最佳化，例如靜態樹提升（static tree hoisting），靜態屬性提升（static props hoisting），以及為執行時提供一些來自編譯器的提示，以此避開子元件的規範過程 (children normalization)，以及VNode建立快速路徑等等…
3. 我們計劃重寫解析器以在模板編譯錯誤中提供位置資訊。並且帶來對模板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專題問答，其中包括：

1. 變更範圍;
2. 改變背後的思考：我們獲得了什麼，以及正在進行哪些權衡;
3. 升級路徑：是採用完全後向相容的形式，還是透過植入一個可移除的相容性層，或者是透過修改程式碼來升級？

我們將期待來自更廣泛社群的公眾反饋，以幫助我們確定這些想法。

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的指南。

7. IE11構建

最終版本之前的最後一個任務是如上所述的IE11相容性構建。

8.最終釋出

說實話，我們不知道這種情況何時會發生，但很可能在2019年發生。再次，我們更關心的是可以穩定執行，而不是為了確定一個確定的時間。雖然有很多工作要做，但是我們確很高興，併為以後的工作感到期待。