在開發需求上,也許你聽過「換皮」這兩個字。但你知道怎麼設計一個容易維護的多主題架構嗎?這裡分享一個我自己團隊常用的方式給大家參考看看。
綱要
本篇係基於這篇的Scss Library的內容做架構設計:
https://hackmd.io/@FortesHuang/SJ9DhgTGn
實際上Style配置和打包設定請以當下的需要為主
使用Global Scss來管理每個頁面和組件的樣式,需要按照以下結構配置
由於 @style/themes/theme.scss 這隻檔案會指定 base.scss 位置來命名一個叫做base的樣式組件引入,也就是 @use '@style/base.scss' as base 這段。
而main.scss、base.scss中,是不會引入 themes 裡面任何檔案來使用的。
通常在 Vite Config 也會設定 alias 來連結指定的自定義 path
所以你也可以放心的將 style/themes 拆到其他路徑下,再透過 CI/CD 來分開部署
如果你的專案是將PC版和Mobile版本放在同一包專案以不同 vite config 打包、再用package.json定義dev、build、preview各自指向的環境,那建議更應該將themes搬移到外面來,像這樣:
@style/main.scss
@style/base.scss
@style/themes/theme-1/theme.scss
創建loadTheme.js
路徑:src/plugins/loadTheme.js
設定main.js
創建loadTheme.ts
路徑:src/plugins/loadTheme.ts
設定main.ts
我們都知道CSS本身是易學難精的東西,大多時候都會因為時間有限、團隊成員知識領域不一定相等,協作上必須選擇妥協,只能透過硬擠出的時間來Review和重構。但實際上寫作風格的養成其實可以減少很多不必要的麻煩。
假設你的團隊有 QA使用Selenium做E2E自動化測試 。
前端寫TailwindCSS的習慣並非在global class name上 @apply
,而是直接在Template上大量的疊加 flex align-center justify-between w-full ...
這情況下QA只有XPATH可以定位的到DOM元素,沒辦法判別CLASS_NAME或NAME、ID,也不能使用CSS_SELECTOR尋找v-for產生的元素集合。
那麼一旦畫面有更動UI的需求出現,測試腳本就會因為XPATH定位被更新了,勢必得重寫元素定位。
除此之外,前端維護程式碼若是註解沒好好寫,也很難理解這個區塊的<template>程式碼是幹什麼用的。
為了自己團隊好之外,也想想日常需要緊密配合的其他部門同僚,假如有E2E自動化需要,那建議還是在撰寫TailwindCSS、Scss時都盡量以 可辨識的BEM命名 為主,以及加上 name="something" 的 attribute,你好,我好,大家就都會好。
假如有個navigator我們希望長這樣的結構:
建議的寫作方式:
可以的話,盡量避免的寫作方式:
乍看下你可能會認為第二種寫法相對較短,但這個例子卻很常出現在落落長的 global scss 或者某個 component 下的 scoped style。
如果能在前面100行就把組件換好樣式,何必滾動數十、甚至數百行去找樣式對象呢?
你或許會有疑慮,這樣寫久了幾乎都是透過 @each 產生CSS,不會使打包後的檔案過大嗎?
實際上還真的不會,如下圖所示,除了Element+ (已經按需引入)這個肥仔以外,專案中指定的主題多達30個Component,打包起來也才這麼點,移除一些for迴圈產生的預設變數甚至還可以降到120KB以下。
主要是避免使打包容量過大,這種做法很容易產生過多根本用不到的規則:
除了另外定義class name來做特定狀態,比如is-disabled
in-xxx-mode
的命名用來判別套用那些CSS規則之外,有時候你不會想要為了很瑣碎的事情去修改class中的margin/padding 值,那乾脆就直接交給Tailwind處理。
比如已經做好一個用來放置卡片排版的元素card-container
,底下所有card
元素都有10px左右的gap間隔。
但現在出現需要做例外的情形,你不得不將這個gap改設為8px來符合Figma設計稿、或者預料外的情形,那建議不要直接修改來源的CSS,疊個gap-[8px]就行了。
雖然選擇正確的工具和開發框架對於確保專案的成功至關重要,每個工具都有其獨特的優點,重要的是,視覺設計細節的完整呈現,對比功能快速迭代,還是值得思考如何去取得平衡點。
技術領域總是在不斷變化和進化。並非用了Tailwind你就不再需要SCSS強大的模組化功能,多數時候你仍會看到混用,這很需要看每個需求的建構複雜度,如果你的專案不需要考慮「即時更換主題」這檔事,那麼依照目前你的團隊所熟悉的習慣應該都是夠用的。
但如果已經是個中大型專案的規模,要考慮的就已經不是「快不快」的問題,還需要可維護性和取得視覺設計、使用者體驗、功能性的平衡,畢竟在企劃、開發、設計等不同角度的工作者眼裡會有不同的解讀。