這篇文章來記錄一下第一次參加 Laravel x Vue Conf Taiwan 2023 的心得，去年的 Conf 本來就想參加，但因為其他行程而無緣參加，所以今年的活動報名時間一開放就秒搶了兩天議程的早鳥票。

今年比較特別的是邀請到重量級嘉賓 Vue & Vite 的作者尤雨溪，所以在參加前就很期待這次的內容，希望可以吸收到一些新的技術與知識。

以下是今年的議程：

第一天

• 工作坊：使用 Vue3！自己的 UI Framework 自己做 — 成智遠(Mike)

第二天

• 重新發明 Vue：經驗與教訓 — 尤雨溪(Evan You)
• 被 Vue 框架耽誤的構建工具 — Vite — 高見龍
• 從 Vorms 出發的一場開源大冒險 — 劉翰璋(Alex Liu)
• 從MVC到前後端分離的策略 — 吳家瑋(Erik)
• 開發的未來，Nuxt3 重新定義開發體驗 — 成智遠(Mike)
• 成為火影還是航海王!? 踏上升級與重構的冒險 — 陳俞安(Alex)

以下我會挑幾個比較印象深刻的議程心得跟大家分享。

重新發明 Vue：經驗與教訓 — 尤雨溪(Evan You)

這應該是讓各位在場的 Vue 開發者為之興奮的一場議程了，畢竟能見到創世神的機會是非常難得的！！尤雨溪分享了 Vue 的歷史與經驗，在升級中遇到了哪些問題，以及 Vue 未來的發展規劃。

Vue 的發展簡史

• 2013年首次發布帶有VueJS名稱的版本
• 2014年首次公開宣傳
• 2015年10月：1.0版本發布
• 2016年10月：2.0版本發布
• 2018年9月：3.0開始開發
• 2020年9月：3.0軟發布
• 2022年1月：3.x正式成為預設版本

Vue 2面對的問題

• 程式碼架構
• 性能優化空間
• API在大型項目中的可維護性
• 瀏覽器版本限制

1. 程式碼架構

• 當時還在使用 Flow 而不是 TypeScript，類型檢查不完全，IDE 支持不佳
• 需要手動維護 dts 類型聲明文件
• 內部一些模塊界限模糊

2. 性能優化空間

• 幾乎是純虛擬 DOM，很多 overhead
• 編譯器結構過於簡單，能夠進行的分析有限
• 組件實例化開銷較大

3. API在大型項目中的可維護性

• Options API 雖然易用，但限制了代碼的可重構性，在大型、長期的項目中，可維護性展現出問題
• Options API 對類型推導不友好，邊界情況多，類型實現維護難度高
• 邏輯抽取複用依賴 mixin，容易導致屬性來源不清晰

4. 瀏覽器版本限制

• 最低支持 IE9
• 無法使用不能被 polyfill ES2015+ 的新語言特性
• 為了避免 polyfill 的性能影響或是 babel 生成程式碼對打包尺寸的影響，維護時有很多額外的心智負擔 Vue3 的目標

5. 代碼架構

• 遷移到 TypeScript + 自動生成類型聲明
• 重新設計內部模塊分層
• 為以後的長期維護打好基礎

6. 性能

• VDOM 算法重構
• 結合編譯器對虛擬 VDOM 進行優化
• 優化組件實例化開銷

7. API

• 引入對重構、複用、類型推導更友好的新 API

8. 瀏覽器

• 語言支持最低要求 ES2015+

開發 Vue 3 遇到的挑戰

1. 尋找性能優化突破點

• 徹底重構 VDOM 算法
• 花費了比較久的時間才找到並驗證了編譯 + 運行時結合的優化模式

2. 探索新的 API 設計

• 嘗試 Class API：因為過於依賴還在 stage 2 的 decorators 提案而放棄
• Composition API：因為風格迥異引發爭議、<script setup> 穩定前 DX 欠佳

3. 周邊配套設置工作量巨大

• 文檔
• 構建工具 (Vue CLI / Vite)
• Vue Router
• Vuex -> Pinia
• Devtools
• IDE 支持 (Vetur -> Volar)
• SFC type check (vue-tsc)
• Lint (eslint-plugin-vue)
• Unit testing (@vue/test-utils)

社區遷移的痛苦

• 2 到 3 的升級難度不低
• 許多用戶仍然卡在 Vue 2

一些錯誤決定與反思

失誤 #1：太多微小的 Breaking Change

• 大部分的破壞性改動，單獨看都不難處理
• 然而在實際應用中需要同時面對所有改動的時候，複雜度就指數上升

經驗:

• 不要一次性發布大量破壞性改動，將小的破壞性改動分批慢慢發布
• 在保證可運行的基礎上，采用 deprecate -> opt-in -> remove 的策略

失誤 #2 低估了對生態中依賴的影響

• 大部分的破壞性改動在討論時都只關注了對應用層程式碼的影響
• 許多大型依賴用到了私有 API，在 Vue 3 中改動較多
• 庫升級困難，導致依賴這些庫的項目也升級困難

經驗：

• 生態中的庫是框架升級的重要考量 — 破壞性改動應該優先考慮對庫的影響
• 引導用戶避免使用私有 API

失誤 #3 低估了對生態中依賴的影響

2020 年 9 月 Vue 3 core 發布 3.0，但配套設施尚未完善

• 臨時文件比較粗糙，缺乏 Composition API 作為一等公民的學習流程
• Router / Vuex 還在 beta / rc
• Migration Build 尚未提供
• 瀏覽器調試插件尚未支援
• <script setup> 還未穩定
• 單獨發布 core 是希望能鼓勵 library 作者和 early adopters 開始適配升級，但對一般開發者而言是比較令人困惑的體驗

經驗：

• 第一印像很重要，寧可推遲，不要發布半成品
• 在正式發布前積極向社區庫的維護者尋求協作，幫助他們提前適配

一些正確的決定

1. 擁抱 TypeScript

   1. 良好的類型支援已經是現代框架必須的功能
   2. Vue 本身的可維護性也大大提升，為後續的迭代打下了堅實的基礎

2. 堅持 Composition API

   1. <script setup> 提升開發體驗後，使用者接受度大為提高
   2. 切實提升了可重構性和可維護性
   3. 邏輯復用：社區湧現出如 VueUse 這樣的優秀項目

3. 對開發體驗持續投入

   1. 在 Vite 上的投入雖然超出預期，但值得
   2. Vue 3 新文件對現有內容進行了大量的重寫和結構調整
   3. Volar：大幅提升 Vue SFC 的 TypeScript 支持

總體來說 Vue3 確實更好更強大。

未來近期到中期目標

1. 過渡尚未完成，穩定優先
2. 不再會有 2 到 3 這種程度的破壞性升級
3. 短期內不會推動 “徹底改變現有範式” 的新 API
4. 專注於不影響現有程式碼的改進
   • Vapor Mode：新的編譯策略，同樣的模版，更優化的渲染效能
   • 元件層級的 opt-in，不影響現有程式碼。
   • computed 計算效率最佳化
   • parser 效能優化
   • SSR hydration 優化

未來長期目標

1. 框架之間逐漸形成底層 primitive（原語） 的共識，並有合作進行標準化推進的可能

   • Reactive 狀態管理：Signals
   • DOM Parts
   • Native CSS @scope

2. Vue 會積極跟進並關注這些標準化努力的進展，並在未來利用平台原生能力簡化內部實現和提升效能

總結：

在框架開發中，勢必會有捨有得，對於升級上，會遇到必須瞻前顧後的情境，盡量顧慮到開發者對於生態系的依賴程度，以一小步一小步的更新才不會讓開發者體驗變得糟糕。

在下午茶時間，看到尤大開放合照，就跑去跟他合照，畢竟也不知道還有沒有機會在見到他。

從 Vorms 出發的一場開源大冒險 — 劉翰璋(Alex Liu)

Alex 是跟我同公司的前端主管，這是他第一次在技術大會上的公開演講，雖然他是第一次演講，但談吐非常的穩健，簡報也準備的很有巧思，能夠很清楚他的邏輯與脈絡，是很好的一場議程。

Vorms 是一個基於 Vue3 Composition API 開發的表單驗證與狀態管理工作。講者介紹了此套件的基礎與進階用法，另外分享了如何參與開源專案，怎麼提交一個好的 PR，俗話萬事起頭難，但只要有心再小的 PR 也是能對開源專案產生貢獻的。他說：平均一個專案有 28% 的貢獻是隨意且偶然的，像是修正錯字、調整格式或翻譯。這句話是真的，因為我也有對開源專案 Nextjs 提交過修正錯誤的PR，我真的就是偶然的情況下發現的，開發團隊也同意了我的 PR，所以也鼓勵大家可以參與開源專案的貢獻。

我司的 Vue3 專案皆有導入，平常開發體驗上確實很好，除了使用很容易之外，也整合一些第三方的驗證工具像是 Zod、Yup、Valibot，能夠讓開發表單更為得快速，也能更專注於邏輯上的開發，所以很推薦大家使用看看！

簡報連結：簡報內有實際可以使用的 Vue 元件，很酷！

點下去就對了 -> Vorms 官網

從MVC到前後端分離的策略 — 吳家瑋(Erik)

來自加坡商鈦坦科技的senior product developer 分享公司產品重構的經驗，從 MVC 架構改為使用前後端分離的經驗。我印象很深刻的是他提到他們怎麼跟 PO, PM 解釋重構是有價值的事，議程重點如下：

重構會有價值的幾個重點

• Reduce story point：未來的 story point 可以降低
• Improve UX：改善使用者體驗
• Reduce server cost：減少 server 負擔
• Bringing business impact (較難)：帶來商業經營的好影響

必要需求會有以下兩項，要確實做到才不會導致出現 Bugs

• Quick Rollback
• Ab testing

重構的好處：區塊性翻新、能快速地得到使用者反饋、複雜組件可以更快開發、可以本地開發

重構的壞處：維護成本會隨時間提高、SEO （因為採 CSR）

結論：要重構的話，要了解想解決的痛點是什麼，且要說服 PO 重構會對公司帶來什麼影響、好處是什麼？且要想出重構的做法以及解決 SSR 的問題。

工作坊：使用 Vue3！自己的 UI Framework 自己做

今年的工作坊的活動是教如何實作自己的 package 並發布到 npm 上，講者講完發布套件的流程後，就讓我們自行分組，一組五人為單位，並且推派一名組長做統合資源與引導討論，而我很幸運的猜拳猜輸，所以我就成為了我們這組的組長 xD 一開始我也不知道我們要做什麼項目，所以我就請大家自我介紹且稍微描述一下目前工作上有接觸到哪些工作項目，稍微討論後，我們決定實作一個 toast 彈跳通知的功能，那因為有時間上的壓力，所以我迅速的將工作分派給組員們，分成兩組，一組實作 UI，另一組實作元件的邏輯，我們還使用 live share extension 共同在其中一名組員的電腦上的 main 分支共同開發，最後還真的把它做出來並且發布到 npm 上！而我們套件叫做 vue3-noti ，但因為時間不夠的關係與遇到一點點的技術障礙，所以下載下來會是壞的。總之過程中很有趣，雖然彼此不太熟悉，但我們卻能有默契一起討論與即時實作這個小專案。

以下是我的筆記：

初期的規劃

• framework 的定位 (例：高度客製化 or 後台)
• framework name
• UI 提供的種類 (樣式)

開發的規劃

• 支援框架的版本
• 是否要向下相容
• 是否支援其他框架
• 是否依賴其他套件

Release 的準備

• 文件的撰寫
• 範例的準備
• 測試的項目
• 如何宣傳?!

剖析一個開源專案

人物

• 作者： 專案發起者。
• 擁有者：主要核心成員，有權限修改專案的管理員。
• 維護者：維護專案與開發，同時參與專案的方向與組織的管理。
• 貢獻者：只為專案作出貢獻的人，包含抖內。
• 社群成員：積極參與專案討論的使用者，表達他們對專案的看法。

說明文件

• 許可協議(LICENSE)：根據開源定義每個專案都必須有個開源選可協議 (例：MIT)。
• README：說明書，解釋專案有何用處，為何發起，快速入門。
• 貢獻(CONTRIBUTING)：幫助人認識與使用專案，貢獻 這個文件是針對想對專案貢獻的人寫的指南。
• 行為準則(CODE_OF_CONDUCT)：這份文件裡頭設立了基本規範來約束參與者的行為(非必要)。
• 其他文件：例如教學，專案導覽。

社群

• 問題追蹤(Issue tracker) ： ㄧ些專案討論過程。
• 請求提取(PR)：給人們檢查程式碼，以及相關問題的討論。
• 即時在線聊天。

Library 打包格式

• lib.cjs.js: CommonJS

• lib.esm.js: ES Module

• lib.iife.js: 即時調用函數表達式 IIFE 版本

發布準備

README 的撰寫

• 項目名稱和ㄧ行簡介
• 詳細描述
• 重點功能介紹
• 安裝指南
• 使用範例
• 授權條款
• 聯絡方式和支援
• 感謝

精美的 icon 服務

• Shield.io
• Badgen
• NodelCO
• ForTheBadge

GITHUB README Status

產生專案參與者頭像：contrib.rocks

文件網站開發 VitePress

準備上傳 npm…

NPM

登入：npm adduser & npm login

上傳：npm publish

每次上傳版本號都不能一樣，建議使用 主版本號. 子版本號. [修正版本號]

major.minor.[revision]

主版本號的異動：發生在重大更新，架構的全局改變，照成舊版好無法向後兼容

子版本號：也可以有重大更新，但不同於主版本，他的異動是有顧到向後兼容

修正版本號：顧名思義， bug 的修復或小部分改善，就會歸在這個版次

總結：

很開心能夠參加到這次的大會，認識了一些前端新朋友，在技術內容的理解上也比以往參加其他技術大會時更知道講者在講什麼，是一次不錯的體驗，而且還能夠跟尤雨溪大大合照！我覺得已經值回票價了！