打造開發者友善的錯誤處理方式（feat. Java, Go, Rust, TS）
錯誤處理是所有程式都會遇到的問題，特別是在複雜的網頁開發中更是如此。本文將研究不同方法模式與語言探討如何「打造開發者友善的錯誤處理方式」。推薦演講：Unexpected Monad. Is Safe Error Handling Possible in JS/TS?
錯誤處理是所有程式都會遇到的問題，特別是在複雜的網頁開發中更是如此。本文將研究不同方法模式與語言探討如何「打造開發者友善的錯誤處理方式」。推薦演講：Unexpected Monad. Is Safe Error Handling Possible in JS/TS?
近期在遷移舊的 Element Plus 專案是必要找到另一款客戶端表單驗證方案，而在使用 Shadcn Vue 過程中發現 VeeValidate 是一款針對 Vue 製作的無頭表單驗證工具，你可以攜帶自己的 UI 整合，使用原生表單元件也不是問題。
對於「多型 Polymorphism」的概念理解像是「要做一件事，但這件事對不同對象來說實踐的方式不同」。具體來說像是各種「形狀」都可以「算面積」，但背後實踐的方法卻不同，而在 Go 當中 interface 就是方法的集合。
第一次看到 Go 的 Receiver 函式會覺得這是啥怪語法，函式名前面還能接收參數？Go 語言提倡「Composition over inheritance」（組合優於繼承），並極力追求程式碼的簡潔性，以此迴避 class-based OOP 所帶來的複雜性。
Go 設計上一切數值都是直白的「Passing by value」，會有「Passing by value」的效果原因是因為 Reference Types 帶有指標，複製時是複製指標值。要讓 Value Types 有 Passing by Reference 的效果要顯式的使用 Pointer。
前端生涯中遇到無數攸關資料呈現的需求需要解決，而 TanStack Table 是一款第一眼看起來很多餘複雜但實際上能省下無數時間的一個優質套件，如果有任何「大量表單、中大型表單應用」我會強烈推薦。在實際工作中我透過導入 TanStack Table 在幾天時間內就能把現有表單大多複雜功能重現。
使用 TypeScript 確保程式型別安全以維持大型前端專案的品質和維護性已經是很成熟且常見的做法，但有一項最常見的破口會讓程式變得脆弱且混亂：「程式間 API 溝通」。TypeScript 本身雖然能靜態檢查程式內部的型別正確性，但只能在程式執行階段驗證資料格式才能真正確保型別安全。
如果翻閱 Shadcn 元件集的元件會發現大量使用到一個輔助函式 cn，背後使用 twMerge(clsx(inputs))，它其實是兩套函式庫的組成，用於更方便建構元件當中 Tailwind 的樣式。為什麼會需要額外的庫和方法來建構元件樣式呢？
不少網站登入時都有關於「Single Sign-On」的選項，像是只要登入 Google 帳號，就可以橫跨不同服務如 YouTube、Gmail，從痛點了解 SSO 如何解決多個服務間登入造成的潛在問題與相關流程，打造更方便與安全的登入體驗。
UI 通常仰賴設計者與前端耗費大量時間精力進行組織與維護，近期工作上進行前端翻新也遇到大量陳舊代碼需要翻皮的作業，問題是誰有時間一個一個重新替換？嘗試串上 Figma MCP 與 Shadcn MCP Server 讓我們透過與 AI 聊天就能精準打造前端介面。
渲染永遠是網頁運算中極度耗費效能的一塊瓶頸之一，而在像是儀表板應用或是大量資料清單如社群媒體版面很容易會遇到前端渲染效率上的問題，透過「只渲染看得到的東西」來減少效能負擔。這種模式通常稱作 List Virtualization（虛擬化看不到的東西）或 Windowing（只渲染視窗內的東西）。
AI 解決一些上下文清晰的小題目如 LeetCode 會發現它通常有驚人的效率與準確率，然而在真實情境下 AI 通常沒有這麼厲害，因為環境上下文和需求是模糊的，如何更好的讓 AI 看清與外部世界互動能夠達成更有效率的產出，而 MCP 是一種大型語言模型的統一協定幫助達成該目標。
先前文章提到：如何優雅的於 Vue 正確的處理資料載入點出了一些獲取外部資料延伸帶來的問題與實際解方，這次我想透過 TanStack Query 的視角挖掘怎麼建構更好的前端資料獲取體驗。本篇教學繼續延續使用 Vue 框架，不過概念對主流框架基本相通。
TypeScript 型別定義檔案通常就是在全局創個 type.ts 檔案並把所有型別丟裡頭，隨處都能引用很方便，但很多專案初期沿用的習慣到了一定規模就會開始混亂，近期也遇到相關的問題因此研究一下一般有哪些方式管理型別檔案。
還記得之前參與某個專案使用 Git Flow 的方式管理產品發布，但隨著時間過去它與持續進行中的主支線差距越來越大，也是在那次問題之後我更認可 Trunk Based Development 流程的概念，其中提到 Feature Flag 是一種很好的技巧用來降低推送功能的風險與控制程度。