更新於 2024/12/23發佈於 2023/12/24閱讀時間約 6 分鐘

Vue-框架設計思維

七星山

如果前人已經走出一條最佳路徑，我們只顧著欣賞也會到山頂

關注點的改變

一個好的架構都會希望讓開發者能專注在”業務邏輯”的實現，可以提高專案的開發效率、減少開發者非關業務邏輯的事情而煩惱。例如:

開發者A: 請問元件的對話窗如何在確認時控制關閉或開啟狀態?

form validation

這個實際案例是架構師認為對話窗的動作皆會再按下”確定”後關閉視窗，因此由底層自動處理關閉可以讓開發者不用煩惱，也少寫一段 Code 相當方便! 這種設計雖然方便，但缺少了彈性，例如:若檢核失敗必須保持開啟，因此設計時要考慮 :

預設自動關閉對話視窗
可以自由控制關閉或開啟狀態
學習使用元件的成本需小於自己做

若單個需求去看待，我們都能給出一個很好的解決方案，不過要綜合考量時，就必須在要各個解決方案中找出平衡、汲取各項優點，我認為這才是設計的難點，同時也是它有趣之處。因為他不會是一個答案，而有很多可能性，取決於你的角度和思維。

如果架構能解決整體開發上的 80% 問題，我認為已經是很好的結果了。若嘗試把所有問題都能一起處理，很容易變成過度設計(Over-design)

Vue的權衡

會用關注點改變當開頭的原因是初次使用Vue時很明顯感受到這個差異，也讓我被框架的魅力吸引，到後來才知道是「命令式」、「聲明式」寫法帶來的不同

命令式

const btn = document.getElementById('btnEle');
const div = document.getElementById('divEle')
btn.addEventListener("click", (e)=>{
	 div.textContent = 'click!'
})

聲明式

<button @click="()=> divEle.textCotent='click!'">Click</button>

從上述比較，聲明式更關心結果，並把實現的過程隱藏。(兩段程式碼就給了我們不同角度切入思考)

早期將Vue引進公司使用也主要是他有更好的維護性。以前維護過大型專案，滿滿的Javascript，就算切出共用元件、方法，如果沒有良好的開發文件，後續要持續沿用是很不容易的。常以新增 JS 檔案引用，利用Javascript全域特性覆寫以前的元件或功能，最後成了一堆不知道可不可以移除或使用的程式碼。

選擇聲明式之後?

既然聲明式是我們期望的開發方式，那我們考量了什麼? 權衡了什麼?

簡單命令式寫法來說，我們是挑不出多餘的執行負擔，它是效能最好的寫法。

div.textContent = 'click!'
// 命令式只需修改過程
div.textContent = 'hello world!'

聲明式寫法則多出了改變結果的過程，例如:

<button @click="()=> divEle.textCotent='click!'">Click</button>
<!-- click! 改為 hello world! -->
<button @click="()=> divEle.textCotent='hello world!'">Click</button>

因此我們可以得知

聲明式執行成本 = 找出結果差異成本 + 命令執行成本
※聲明式只是封裝命令式

公式中有了一個具體目標 — "找出結果差異成本”最佳化，使效能趨近於命令式。

找出利弊後，將弊處的影響減少到最低就成了架構的目標，而框架本體也若有似無的漸漸浮現

工作上常遇到各種大大小小的需求與專案，以複雜度、流量、專案目標去設計出相對應適合的架構。曾遇過有同事把網路上提供的架構模板Copy/Paste到專案上，前面開發得很開心，後續客戶需求變動後就不敷使用。我們應謹慎的評估每次的需求，設計出相對應適合的框架。

Virtual DOM

最一開始知道Vue使用Virtual DOM技術來實現框架，但直到讀了這本書(參考文末)才了解到，並不是因為這個技術而產生框架，而是權衡利弊後的解決方案可以利用Virtual DOM實現。

Virtual DOM概念很簡單，使用Javascript物件資料渲染出畫面

const root = document.getElementById("#app")
const vdom = {
  tag:"div",
  child:{
    tag:"span",
    child:"Hello Vue!"
  }
}

render(vdom, root)


<body>
	<div id="app">
		<div>
			<span>Hello Vue!</span>
		<div>
	</div>
</body>

前面提及的 “找出結果差異成本”很適合這個概念，因為透過遞迴物件找尋差異一定優於搜尋整個DOM Tree。

實現策略

我們有了夢想(聲明式)、工具(Virtual DOM)，下一步就是實現的策略。聲明式很明顯是Browser無法解析，所以我們需要轉化成可解析的樣子 — 編譯。而編譯後，就是”執行”期間的事情了。

像是現在超商賣的雞胸肉，調味都幫你用好，我們只要微波或煎一下就可以吃了

雞胸肉

Javascript純執行的特性變成 ⇒ 編譯期 + 執行期 (實現策略)

編譯是多出來的成本(開發期間)，也會需要最佳化。不過目前都有工具在處理，例如: Webpack、rollup，身為開發者真的很慶幸有這些工具，開發體驗提升，多出來的成本還不用擔心，調整設定檔就能優雅的使用

結論

使用Vue也有3、4年的時間，直到最近才看了「Vue.js 設計實戰」。中間透過自己摸索框架，心中也有很多疑惑，有些在開發中得到答案，有些則還一直尋找，而這本書給我了這些答案。雖然比較慢才閱讀這本書，但也是一個不錯的時機點，過程中回想到很多的開發情境，透過情境相互印證也讓我更快吸收內容。

玉山指標

理解Vue框架設計思維，找出夢想的樣子，列出實現的方法，權衡方法選出適合的，解決因設計而多出來的成本。吸收完這本書的思維，平日設計專案架構路上如同多了指標，看來我也能邊欣賞邊到山頂了?🤣

參考

Vuejs設計實戰 - 霍春陽著

Vuejs設計實戰

分享至

成為作者繼續創作的動力吧！

Vue3 設計之路

追蹤

從 Google News 追蹤更多 vocus 的最新精選內容

你可能也想看

發表回應

成為會員後即可發表留言