【Vue3源碼分析】講透源碼開篇

作者：一袋米要扛幾樓 2021-09-22 07:57:23

開發前端

組件（Component）是 Vue.js 最強大的功能之一。組件可以擴展 HTML 元素，封裝可重用的代碼。每個 Vue 應用都是通過用 createApp 函數創建的，傳遞給 createApp 的選項用于配置根組件。

[[424925]]

為什么要學源碼

技術是第一生產力
學習 API 的設計目的、思路、取舍
學習優秀的代碼風格
學習組織代碼的方式
學習實現方法的技巧
學習 ES67 新 API、TS 高級用法
不給自己設限，不要讓你周圍人的技術上限成為你的上限
面試加分項
裝逼利器

學習源碼副作用

畫虎不成反類犬(強行上馬 vue3，自己焦頭爛額、項目難以維護、同事苦不堪言)
為了用而用，而不是因地制宜
喜歡炫技寫一下看似高大上，實際沒有可讀性，影響團隊協作的奇技淫巧

vue3 設計動機與目的

更好的邏輯復用與代碼組織

vue2 option api 的代碼風格將同一邏輯點的代碼分散在各處，會導致讀者關注點分離，也不利于代碼的邏輯復用;而 vue3 composition api 將同一業務邏輯的代碼聚合在一起命名為 useXXX 函數，再通過 setup 將不同的邏輯組裝起來并返回給組件 data，明顯更方便邏輯復用。
vue2 mixin 用于邏輯復用的時候容易導致命名沖突和數據來源不清晰;而 vue3 provide/inject 配合 composition api 可以很方便的找到數據來源并通過解構重命名，明顯更方便邏輯復用。

更好的類型推導

在 methods 中 this 指向組件實例而不是 method 本身，不利于類型推導。
例如 this.、store，每個新的插件都會需要向 Vue 追加類型定義。

更新前后對比

優化

打包更小(全局 API tree-shaking)
渲染、更新更快，內存占用減少
使用 proxy 取代 Object.defineProperty
v-model 代替以前的 v-model 和.sync
生命周期變更例如 destroyed beforeDestroy 改為 unmounted beforeUnmount
自定義指令 API 與生命周期保持一致
Diff 算法的提升(靜態標記、靜態提升)

新特性

Template 支持多個根標簽
composition API 實現邏輯模塊化和復用
Teleport 傳送門組件代碼塊掛載到任意位置
Suspense 懸停組件異步加載組件使用(實驗屬性)
使用 @vue/runtime-core 的 createRenderer 自定義渲染器(跨平臺利器)
使用 ts 編寫源碼，更好的類型推導、更好的適配 ts

疑問解答

問題一：compostion api 根本沒有解決任何問題，只是追逐新玩意的東西尤雨溪：不同意這個觀點。Vue 最開始很小，但是現在被廣泛應用到不同級別復雜度的業務領域，有些可以基于 option API 很輕松處理，但是有些不可以。例如下面的場景：

有很多邏輯的大型組件(數百行)
在多個組件可復用的邏輯

對于問題 1，你需要把每個邏輯拆分到不同選項，例如，一段邏輯需要一些響應數據，一個計算屬性，一些監聽屬性還有方法。你去了解這段邏輯時，需要不斷上下移動閱讀，雖然你知道一些屬性是什么類型，但是你并不知道他具體的作用。當一個組件包含多個邏輯，情況就更糟糕了。如果用新的 API，可以將數據和邏輯組合在一起，最重要的是，你可以干凈的把這些邏輯提取到一個函數，甚至一個單獨的文件中。

問題二：使用新 API 導致邏輯分散到不同地方，違背"關注點分離

"尤雨溪：這個問題和項目文件組織方式問題類似。我們很多人都同意按文件類型組織(布局放 HTML，樣式 CSS，邏輯 JS)并不是正確的方式，因為強制把相關代碼分割到三個文件，只是給人一種“關注點分離”的錯覺。這里的關鍵是“關注點”不是由文件類型定義。相反，我們大多數選擇以功能或者職責來組織文件，這正是人們喜歡 Vue 單文件組件的原因。SFC 就是按功能組織代碼的方法，但諷刺的是當首次引入 SFC 時，許多人也是拒絕的，認為它違反了關注點分離。

問題三：新的語法讓 Vue 失去簡單性，導致"意大利面條式代碼"的出現，降低項目維護性。

尤雨溪：正好相反，新的 API 就是為了提高項目長期維護性的。如果我們查看任何 javascript 項目，都會從入口文件開始閱讀，該文件的本質是你的應用啟動時被隱式調用的"main"函數。如果只有一個函數入口，會導致意大利面條代碼，那所有的 js 項目都是意大利面條代碼。顯然不是的，因為開發人員通過代碼模塊化或者較小的函數來組織代碼。另外，我同意新的 API 理論上會降低代碼質量的最低門檻。但是我們可以使用以往防止代碼變成意大利面條的手段緩解這種情況。另一方面，新的 API 可以提升代碼質量的最高上限，相比 option api，你可以重構為質量更高的代碼。而且，基于 Option api 你還得解決類似 mixins 的問題。很多人認為"Vue 失去簡單性"，實際上只是失去組件內代碼類型檢查能力(就是你不知道一個變量是 data、method、還是 computed)。但是用新的 API，實現一個類型檢測器也是非常容易實現以前的特性的。也就是說，你不應該被 option api 限制思維，而更多關注邏輯內聚問題。

源碼調試

安裝源碼及依賴(安裝依賴出錯一般是 npm 淘寶源的問題或者需要梯子)

git clone https://github.com/vuejs/vue-next.git 
yarn install 
yarn dev --sourcemap

對源碼進行打包

yarn dev --sourcemap

新建 packages/vue/examples/index.html 用于測試

<!DOCTYPE html> 
<html lang="en"> 
<head> 
  <meta charset="UTF-8"> 
  <title>Title</title> 
</head> 
<body> 
<div id="app"> 
  <div> 
    <div>test demo {{msg}}</div> 
    <div>test demo {{msgMore}}</div> 
  </div> 
</div> 
<script src="../dist/vue.global.js"></script> 
<script> 
  Vue.createApp({ 
    setup() { 
      const msg = Vue.ref('Hello') 
      const msgMore = Vue.computed(()=>msg.value+' world') 
      return { 
        msg, 
        msgMore 
      } 
    } 
  }).mount('#app') 
</script> 
</body> 
</html>