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設計實戰
你可能也想看
