iT邦幫忙

2021 iThome 鐵人賽

DAY 1
4
Modern Web

Vue.js 進階心法系列 第 1

這是一趟把 Vue 從需求、觀念到功能貫串起來的旅程

其實去年就想這一系列,但是就怕寫完變成別人的線上課程,所以沒有寫 (想太多了)
想了一年之後,還是覺得不要留什麼招在自己的內心,這樣才是對自己有信心的表現
因為工程師的價值並不是做了什麼,而是為什麼這麼做,對吧!

從需求、觀念到功能

在學習 Vue.js 的路上,我從語法開始學習,從傳遞、更新資料的方式,也有拿來做過去 jQuery 常做的抽換 class。

但是初學一開始,比起用 jQuery 很難從頭寫一個頁面,不知道存在 data 中的值如何使用,只是跟著官網的範例寫了一個 count++

Object-oriented programming

過往寫過一陣子的 C++,所以對於 OO 有著一種執著,但是自從寫了 JS 之後就不再這樣了。
對於 OO 還是有著一定的觀念。

封裝 + 繼承 + 動態連結 = 物件導向

這也是 JS 很不 OO 的由來,不過後來 JS 有導入 private variable 了,所以,應該也算是補齊了最後一塊拼圖了。

Private class features - JavaScript | MDN

這些觀念用在 Vue 上依然非常好用。

functional programming

在學習 Vue 的過程,也有學習一些 React,所以會跟 React 的框架學習一些觀念。
只是認識這些觀念的過程,總是會遇到一些「λ狂熱信徒」,不過也是因為這些信徒的熱情介紹,讓我認識許多關鍵字,有助於我對 Vue 框架使用。

  • immutable: 資料不更新,只有替換資料
  • pure function: function 的輸出只跟輸入有關
  • higher order function: function 當參數傳遞進來 HOF,會產生新的 function
  • currying: 可以執行到一半的 function

這些是我用在 Vue 上面的 functional programming,也許還有其它的...

達到 MVVM 效果的自動化魔法 computed 和 watch

當需求裡面有資料同步連動並更新畫面時,第一個反應就是這兩個選一個上場!方便又有效!
但真的是這樣嗎?

Computed Properties and Watchers — Vue.js

學習 Vue 的過程,第一個關卡就就是要認識 computed 和 watch 這兩個新東西,總是讓人混亂不已,總覺得 watch 就是 computed + data ,不知道要選哪一個比較適合當下面對的問題。

watch API — Vue.js

對 watch 的更新,如果物件太深,就會失效,也不知道多深才會出問題,但總是用 deep: true 似乎也不是辦法?

切分 component 切太多記不住?!

不知道什麼樣的需求,要切分 component,還是畫面太複雜時,就切一下。
究竟是要怎麼切才是合理的,component 的 component 太深怎麼每一次都會吃掉我大部份的認知負擔,是不是 component 不可以太深?還是有其它的問題?

表單綁定神器: 魔法 attribute v-model 但省了什麼 code

需求提到表單填寫時,就會想用 v-model,似乎是表單麻煩事的必備良方。

Form Input Bindings — Vue.js

v-model 似乎可以讓 template (html) 的寫法變得簡潔,但是 v-model 加上 computed 的時候,會讓 get/set 的寫法一直反覆出現,卻又不能合併,好像也是無法改變的事情。

Two-way Computed Property, Form Handling | Vuex

在 vuex 中有提到使用了 v-model 和 computed 的做法,可以讓畫面直接綁到 state,但這樣寫會讓 code 變多!閱讀失去了魔法的 v-mode 就覺得很多贅 code!

失控 component 與暴量的 attribute, event

需求的畫面很複雜時,就是要切分 component,但是每個 component 之間的溝通就是讓人頭大,每次有 bug 時就不知道在哪一層出現問題,用了 Vue 好像和用 jQuery 沒什麼差別只是換了一個工具,開發的麻煩性也沒有變少。

v-bind Shorthand, Template Syntax — Vue.js
Props — Vue.js

v-on Shorthand, Template Syntax — Vue.js
Custom Events — Vue.js

有了 component ,進入了一個可以自己定義 html 的標籤的夢幻自由國度,什麼都可以抽出來,又什麼都可以傳出來。

Custom Events — Vue.js
.sync Modifier, Custom Events — Vue.js

必要時每個 prop 都可以雙向綁定成 v-model, prop.sync(v2), v-model:prop(v3) 這樣做用起來很清爽,不用看見成對的 prop/event。
但是當我的 component 有二十個欄位難道我要一個一個綁嗎?(累!)
不可以傳入之後,直接在 component 裡面修改值就好了嗎?一定要傳出來?

頓時間讓自己無所適從,每次寫 vue 要切 component 都不知道要怎麼做 prop/event 才會真正讓自己覺得省下一些工夫,而不是每一次都在做苦工。

我的 component 不是我的 component

用 Vue 更換畫面等同於更換 component 只是這個 component 的畫面比較大。那要用哪個技術抽換呢?這個有一定嗎?還是不管是什麼,通通用 vue route 就對了?是嗎?

Conditional Rendering — Vue.js
keep-alive with Dynamic Components, Dynamic & Async Components — Vue.js
Getting Started | Vue Router

在 vue 中換 component 有幾種方式

  1. 用 v-if 和變數
  2. <component :is=""> 和變數
  3. <router-view> 和 router

這幾種方式和需求之間的距離有多遠?
好像選哪一種都沒差 component 都會抽換

vue-router

等到拿來做專案時,就配合不同的需求、畫面,試著分類 component 並且透過 axios 取得資料,從這開始就出現了一些混亂的情況,API 呼叫混亂,axios 引入的位置也沒有一定的規則

API 收到 403 時,要怎麼優雅的請畫面跳轉到登入頁

vuex

使用 vuex 管資料,一開始就覺得只是將 data 移到 state 而已。mutate 和 getters 似乎也沒有什麼特別的用途,若資料沒有要改變,似乎也不用特別寫。

邏輯寫在 aciton 和 mutation 好像也沒有什麼差別。也許只要寫 action 和 state 就好。

以上,如果你已經寫了一段時間的 vue ,而且有任何一個一樣的想法,請一定要追這一個連載,以上這些覺得沒有差別的想法,就會造成一些 random coding 的產出

從需求判斷資料讀寫需求

從現代前端工程師該如何聆聽需求,請務必在需求訪談時,特別注意「資料讀寫」的情境。這些情境就是我們要處理的條件判斷。
「資料讀寫」這個角度去探討,畫面元件設計與資料編輯權限的相關性,配合其它程式設計的理論,建構出一個前端框架使用的思考流程。

如果你有上述的困難,請訂閱這一系列。這一系列會 (希望可以) 帶著你的思緒思考,運用技術的過程,如何寫出好維護、自我文件化、縮小 bug 範圍、好追縱錯誤的程式碼 (希望看完的人不會覺得我在胡說八道。哈哈)。


下一篇
捨棄偽雙向綁定 v-model
系列文
Vue.js 進階心法30

尚未有邦友留言

立即登入留言