Jeff的隨手筆記

前言

在最近的專案重構過程中，我遇到了一個關於 Race Condition（競爭條件）的問題。當我找到解決方案後，分享給團隊成員時，發現這個處理方式對他們來說都是相對陌生的。這激起了團隊的興趣，他們邀請我在技術分享會上深入探討這個主題。

身為團隊的新成員，能有機會貢獻自己的經驗是很寶貴的。為了準備這次分享，我研究了相關資料，希望能夠完整地呈現這個議題。在這篇文章中，我將分享我的發現以及實務上的解決方案。

前言

這是我在翻新舊版專案到新架構時遇到的問題，因為是第一次接觸反向代理，所以特別記錄下來，藉此加深理解。過程中，我發現反向代理在分流請求、提高安全性和優化效能方面發揮了重要作用。
透過這次經驗，我學習了其基本概念，也清楚如何在專案中正確配置與應用。這篇文章將整理我的學習過程與心得，希望能幫助有相同需求的開發者更快上手。

後記：一路以來的心路歷程

從決定要開始寫這個系列到結束，花了大概兩個多月的時間，還好趕在農曆年前完成了全部的文章。

前言

在前端開發的路上，隨著專案規模逐漸擴大，總是會遇到需要在不同元件中重複使用某些邏輯的情況。還記得以前遇到這種狀況時，我常常會直接複製貼上相關的程式碼，導致後續維護變得非常困難。後來接觸到了 React 的自訂 Hook 這個概念，才發現原來我們可以用更優雅的方式來處理這個問題。

今天就讓我分享一下自訂 Hook 的使用心得，看看它如何幫助我們寫出更好維護的程式碼。

前言

還記得我一開始學習 React 時，總是習慣性地調整依賴陣列來解決問題，想當然爾地認為：「反正只要控制好依賴，Effect 就會按照我想要的次數執行」。但隨著開發經驗的累積，漸漸明白到這樣的思維其實不太正確。

這種做法雖然在短期內看似解決了問題，但往往會埋下一些難以發現的 bug。今天就讓我來分享一下，在實務上我們該如何處理 Effect 的依賴問題。

前言

最近在優化專案時，我深深體會到正確使用事件處理（Event Handler）和 Effect 的重要性。記得之前在處理一個即時聊天功能時，我把所有的邏輯都放在 Effect 裡面，結果不只效能變差，連除錯都變得特別困難。這個經驗讓我意識到，雖然這兩種機制都是用來處理副作用，但它們的使用時機和行為模式其實有著根本的差異。

今天就讓我分享一下這兩種機制的關鍵差異，以及在實務上如何選擇合適的工具。

前言

在專案開發的過程中，處理副作用一直是個重要的課題。記得剛接觸 React 時，總是把 useEffect 跟傳統的生命週期掛鉤，導致寫出來的程式碼既複雜又難以維護。直到後來深入了解了 Effect 的本質 - 同步機制，才發現原來我們一直用錯了方向。今天就讓我分享這個重要的觀念轉變，以及在實務上如何正確運用 Effect。

前言

雖然之前就知道 JavaScript 浮點數的問題，想不到居然在今天遇到了。這次的問題是因為專案中使用了 .toFixed() 這個 JavaScript 原生的方法，導致在進位時出現了一些問題。還好之前上課有認真，看到問題的第一時間就知道可能會是這樣，就往這方面去查，結果也如我預期的。

前言

還記得在學習 React 的過程中，一開始接觸到 useEffect 時，總是很興奮地想要把它用在各種地方。特別是當遇到任何跟資料處理或狀態更新相關的邏輯時，第一個反應就是：「啊！這裡要用 useEffect！」。但隨著開發經驗的累積，漸漸發現到並非所有情況都適合使用它。今天就讓我分享一下這些實務經驗。

前言

在開發 React 專案的過程中，我常常遇到需要處理 API 請求、訂閱外部資料、或是直接操作 DOM 的情況。一開始總是搞不清楚這些邏輯應該放在哪裡，直到認識了 useEffect 這個強大的 Hook，才發現原來 React 早就為我們準備好處理這些「副作用」的解決方案。今天就讓我分享一下使用 useEffect 的心得。