鐵人檔案
「別重複造輪子」是效率的建議，不是學習的建議。三十天，我挑六個 React 每天都會碰到的設計問題，每個問題找幾個成熟函式庫當作不同的答案，寫最小的臨摹實作、用同一組測試逼出分歧，再探問：為什麼它們選得不一樣？
我希望的不是透過這個主題介紹函式庫，而是重建其中的設計判斷。
昨天我們用選擇器告訴 React 元件在乎哪一塊，ThemeLabel 從此不再跟著購物車重新渲染。但 store 的通知方式沒有變：每一次寫入，每個選擇器還是...
過去兩天，不管是選擇器還是節點，我們都是先把依賴寫下來。store 不會自己知道誰在乎什麼，所以呼叫端需要先告訴它。 可是 Valtio 看起來不是這樣。 它既...
探索共享狀態的那四天，每一次寫入都是按一下按鈕：加一件、改名字、改內容。一次點擊，一次通知，誰該被通知，我們可以一個一個比對。 但表單不是這樣。使用者在欄位裡打...
昨天我們把表單的狀態從 SignupForm 身上搬了出去，放進一個活在 React 外面的 form control。表單本體不再重新渲染，但在姓名欄打一個字...
昨天的實驗裡，姓名欄只打了兩個字：先打 L，再打 e。兩種訂閱方式都讓送出按鈕只在 isDirty 變了的時候重新渲染。 如果是一次按鈕點擊，通知錯了人，也許只...
過去三天，我們一直在回答同一個問題：每次擊鍵，誰該被通知？Day 12 把狀態從表單本體搬進 control；Day 13 看了訂閱關係的兩種寫法，RHF 讀了...
💡 命名微調通知：從今天起，我會在標題標注各領域探索的進度，方便用來文章導航 從「遠端世界」、「共享狀態」，再到「使用者輸入」領域探索的過程中，有沒有發現我...
昨天我們從 useLocalStorage 這個 Hook，來看 react-use、usehooks-ts 與 @react-hookz/web 的實作概念，...
在昨天，我們透過 react-use、usehooks-ts 與 @react-hookz/web 三個函式庫，看到同樣封裝瀏覽器 localStorage 的...
過去三天，我們從 localStorage 出發，探索了三個問題：兩個元件用同一個 key，為什麼一邊改、另一邊不知道；把它包成 Hook 之後，呼叫端還需要知...
