把炸彈拆完，才有力氣往前走

游標分頁、環境變數與 API 統一大作戰：把炸彈拆完，才有力氣往前走

有些技術債務不會自己消失，換個環境就原形畢露。這兩天我乾脆把 API URL 的處理邏輯整個抽出來，用環境變數統一管理，再加上 trim，免得前後多了空白符號害人抓狂。順手把散落各處的 console.log 清一輪，才發現 ingredient 的 fetching 端點之前居然不一致，害某些成分 ID 會查不到。笑不太出來，只能重構，把 URL 結構對齊、確認每個 ID 都能讀到資料，附帶補上 error handling。下一次出問題至少能快速定位，而不是盯著螢幕問號連發。

API URL 收拾好後，回頭看最近做的游標分頁，總覺得哪裡卡卡。先前只有單向 next，自己測一測發現使用者一點「上一頁」邏輯就亂掉。於是把查詢重新設計，加入 direction 參數，讓前後分頁都能順暢；IngredientsPage 跟 Pagination component 也一起改成完整的雙向游標分頁。體驗確實好很多，但老實說，這套 SQL 邏輯寫起來就是繞，收工前還是會再停一下自我檢查：「這樣真的沒坑嗎？」

下午切到前端，把 IngredientsPage 跟 IngredientSchema 的 UI 結構整理一遍。舊版的成分列表在資料一多時很難讀，這次改成動態載入、加上 loading state，再補一個 detail modal 讓使用者點入看細節。為了讓搜尋更直覺，我在後端模型加了成分別名與翻譯欄位，讓不同語言或常見別名都能對應到正確成分。只是多了幾個欄位，但這類小小的 UX 改善，經常是值得投時間的地方。

同場加映，把 TypeScript 相關設定也更新一輪：package.json、tsconfig.json 調到最新穩定版本，順便清掉過時文件和沒人在看的開發指南。每次整理這些老檔案，難免想到當初寫下它們的用心，不過在快速迭代的節奏下，很多東西確實會失去意義。下一次寫文件之前，還是先想清楚要解決的是什麼問題。

整體進度算順，但心裡仍有幾個問號。游標分頁的複雜度值得嗎？後續維護成本會不會太高？環境變數的統一處理是否還有遺漏？創業與開發本來就伴隨不確定：邊做邊學、邊犯錯邊修正。只要今天的程式碼比昨天更清楚、更穩定，就是向前一步。

我給自己的幾個小結論：

• 能抽象就抽象，環境變數與 URL 統一是長期可維護的關鍵。
• 分頁邏輯要站在使用者操作上思考，方向性要一次設計周全。
• 後端模型多加一點對齊使用情境的欄位，搜尋體驗就會明顯改善。
• 文件要精簡、對齊現況，避免把歷史包袱再背上身。

拆完炸彈，路還長，但腳步更穩。