Pi's Blog
0%

發表於

最近的一些小小心得

前幾天設計師同事說他從沒想過Figma讓design跟dev走得這麼近。

Figma相較於過去的UI設計工具，引入了很多工程思維，元件化、auto layout、variable這些概念可以讓排版、出畫面變得更快更一致也更好管理。

但我相信這些功能對沒有太多UI經驗的設計師來說除了不好理解以外也不知用意何在。幾個月前同事問我Figma Token的問題，我剛好有稍微研究過記得大概的用法，基本上就是json的運用，但對方還是容易不解為什麼要這樣做。設定了一大堆東西卻‘看似’只能用來切換深色模式，另外token的mapping(alias)、variants也是設計領域相對陌生的東西。

後來她離職了，公司剩另一位更不熟Figmaㄉ設計師。出圖永遠現場拉，連frame都常常沒包，沒元件化的結果導致UI總是不一致，畫面一改就全都得重拉。雖然有想排整齊卻很難做到，也缺乏對齊方式等RWD資訊。同時我們也欠缺一個有效管理Figma檔案的方式，我們永遠找不到最新的畫面，都是三百年前的頁面配新的UI，還常害校稿的同事改到舊的文案。

在獲得允許可以實驗性的大改Figma file後，我開始研究要怎麼妥善管理元件、頁面、spec，幫忙補 UI，教怎麼用 auto layout 處理 resizing。

也畫了架構圖向設計師說明元件庫、專案、畫面之間的關係，解釋為什麼這麼做能改善迭代的效率。但就像前面說的，工程思維滿類似寫程式時的 design pattern，對工程師來說相對熟悉，卻對設計師而言很陌生，問了不少次「為什麼要這麼麻煩」。但我不認為這是一個只適用於程式面的技巧，只要是需要迭代、管理、量產，就一定會受用。

當這些工程思維被建立起來後，除了能提升效率，也多了一些共通語言，不會一直有種設計跟工程兩個世界的感覺。我覺得前端(至少在我這)就是同時存在在這兩個世界的角色，沒有非常隸屬於任何一邊，但我感覺有一點點責任去把這兩個世界拉近一點。

發表於

前言

說到 React 的狀態管理工具
之前只有在線上課程學到 Redux
但由於之前的專案只需要用到 global state 而已
甚至不需要 useReducer 的功能
加上 Redux 在設定上還蠻複雜的
有 store, action, reducer, slice 等概念
讓我一直覺得大材小用的感覺
每次要用到新專案
基本上都要把 doc 從頭讀一遍ＸＤ

直到後來在公司接手外包前端的專案
發現他用了 Recoil 這個狀態管理工具
起初還有一點小排斥
但當我理解用法後
簡直開闢了新天地

Recoil

facebook 開發的 React 狀態管理工具
採用 atom 的架構，跟 Redux 的 flux 架構不同

相較於 Redux 輕量很多
很多時候我們只是想要單純使用 global state
而不打算用到 middleware 或是 reducer, actions 來管理狀態變化。
這時 Recoil 就非常方便。

初始化

要使用 Recoil 前置作業非常少
npm install recoil 安裝之後
用 RecoilRoot 包住整個 app
這樣就好ㄌ

1
2
3
4
5
6
7
import {RecoilRoot} from 'recoil'

...

<RecoilRoot>
  <App/>
</RecoilRoot>

Atom

狀態的最小單位，初始化時需給予一個唯一的key以及初始值。
元件可利用 useRecoilState 或 useRecoilValue 來 subscribe 任一 atom
當這個 atom 發生變化時
所有 subscribe 它的元件都會更新。

1
2
3
4
5
6
const nameState = atom({
	key: 'nameState',
	value: ''
})

const [name, setName] = useRecoilState(nameState)

Selector

一個 pure function
傳入值可以是 atom 或是別的 selector。

Selector 用來處理 derived data
根據 state 計算而得的值。讀值時使用 useRecoilValue。

1
2
3
4
5
6
7
8
9
10
const fontSizeLabelState = selector({
  key: 'fontSizeLabelState',
  get: ({ get }) => {
    const fontSize = get(fontSizeState);
    const unit = 'px';
    return `${fontSize}${unit}`;
  },
});

const fontSizeLabel = useRecoilValue(fontSizeLabelState)

心得

Recoil 實在是很方便
包上 <RecoilRoot>，建立 atom，立刻就能用

官網：https://recoiljs.org

發表於

前言

老闆總是覺得前端很簡單，總以為套套版三天就可以上線了
但我能理解，因為國中時我也常把任何事情想得很簡單
沒做過的事都不會知道有什麼難處
所以我並不會對國中生要求太多

但如果能把事情快速做完有何不可？
無奈這間公司的每個網站都是前輩們趕鴨子上架
缺乏一個有系統的管理方式
因此我想來試試看

用 Group 來管理專案

我想做的主要有三件事情

  1. 整合公司 GitLab 內的所有前端專案
  2. 將每個專案中會共用的元件、函式提出來，變成 library
  3. 建立 template

Group 是 GitLab 中的一個功能
你可以把相關的專案放在同一個 group 當中
此時專案的 namespace 就會從

變成

除了一目了然，一下就知道這是前端專案，或是前端模板
最大的優點就是權限控制了

我們試想一個情境
公司內有老闆、PM、RD、Dev Leader、QA
就算每個人都能看到每個專案
每個人應賦予的權限也不一樣
RD 要能編輯，QA 要能開 issue，老闆動口不動手
只要有用 Group 將各個專案進行分類
就不需要對每個專案都設定一次
而是以 Group 為單位來給予權限

  • Owner: 權限最大，掌管專案的生死
  • Maintainer: 通常為資深工程師，負責處理 branch 的異動
  • Developer: 開發人員，專心寫 code
  • Reporter: 測試並回報問題，所以要能開 issue
  • Guest: 只能看，老闆就在這了啦

用 Group 來管理專案

目前公司只有我一個前端，所以權限這件事目前還不需要煩惱
我只要先整理好 Group 的架構就好

首先建立一個名為 Frontend 的 Group
只要是前端的專案都放進來
接著 Frontend Group 底下再建立兩個 sub-group
Templates 和 Shared

Templates 裡面會放一些做好初始設定網站作為模板
包括常用的套件也都會安裝進去
未來要開發新網站就只要從這些模板開始就好
因此我先做了兩個模板
如果需要 SEO，就用 Nextjs 的模板
如果不需要 SEO，或是一次性的網站，就用 Vite 的模板

Shared 裡面放的就是跨專案共用的檔案啦
我分別建立了 component, stylus, utils 三個專案
並以 submodule 的形式加進 template 當中
這樣的好處是，可以維持網站間的一致性
例如每個網站都有一樣的 footer
那我就只要修改 Shared/components 這個 submobule
再打開每個專案更新 submodule，重新跑一次 CICD
就不用怕忘了改(或改錯)某個網站的 footer 了

大至上的架構是這樣，中括號代表 group，其他的就是 repo：

1
2
3
4
5
6
7
8
9
10
11
[Frontend]
  [Templates]
    Nextjs-web3-template
    Vite-web3-template
  [Shared]
    component
    stylus
    utils
  Website 1
  Website 2
  Website 3

結論

利用 Group，我們便能將各個 repo 分類
光看 namespace 就知道專案的類型
也能用更方便的方式管理專案權限