原來分類的坑比想像中還要深

昨天還在那邊糾結軟刪除要怎麼寫，今天一早發現分類功能的坑也沒好到哪去。昨天晚上睡前還在想：「那個分類 API 加了遞迴查詢子分類，前端真的能好好用嗎？」果然，今天實際接起前端的時候，馬上發現了問題。

原先前端分類商品頁面只有一層下拉選單，選完分類就直接撈產品，沒想到後端現在支援子分類了，前端卻還停留在平面結構。看著 API 傳回來的子分類資料，我心裡默默吐槽自己：「是不是又忘記前後端規格了？😅」於是趕緊動手補上第二層分類選擇器，讓使用者可以更直觀地選擇子分類。React 的狀態管理原本用 useState 堆了好幾層，寫到一半突然覺得：「等等，真的需要這麼多 state 嗎？」想了一下，決定直接重構成單個物件的狀態，這樣不但程式碼更乾淨，未來要擴充也比較方便。

前端調整完以後，回頭看 API 文件，又覺得分類 API 的參數設計有點彆扭。一開始只設計了一個 `categoryId` 參數，預設就會把該分類和所有子分類的產品全部撈出來。這樣設計雖然簡單，但後來想想，有些情境使用者可能只想看單一分類的產品，並不需要撈子分類的資料。如果每次都把子分類產品一起傳回去，使用者體驗上可能會覺得「怎麼選了一個分類，結果看到一堆不知道從哪裡冒出來的產品？」於是決定在 API 上新增一個 `includeSubcategories` 參數，讓前端可以明確指定是否要包含子分類的產品。這樣雖然 API 變得稍微複雜一點，但彈性和清晰度提高了不少，使用者體驗也更符合直覺。

另外，今天還順手把分類商品的圖片顯示邏輯給優化了一波。本來圖片是透過 API 動態取得的，但仔細想想，分類頁面上的圖片其實變動頻率很低，每次使用者打開頁面都發一次 API 請求，真的有必要嗎？🤔 為了效能考量，索性改成直接使用靜態圖片，減少不必要的 API 請求，順便讓頁面載入速度快了一些。

整天下來，從 API 的設計到前端的狀態管理，每個細節都忍不住反覆推敲。原本覺得分類功能應該蠻單純的，沒想到一深入就發現處處都是坑。只能慶幸今天踩的坑總算都補好了