プログラミング言語
Python、C、C++、Java、JavaScript、TypeScript、Go、R、Haskellのチュートリアル — 入門から上級テクニックまで。
課程導讀
用了三個月的 React 與 TypeScript 之後，多數人會停在一個共同的位置： useState、useEffect、useMemo、useCallback 都會用， 照著公司現有的範例可以把需求做完，但心裡其實有一連串沒有答案的問題
記事を読む →React 的心智模型：UI 是狀態的函數
React 所有的設計——單向資料流、hooks、不可變性、memo—— 都是從同一個核心決定推導出來的。這一章先把這個核心講清楚， 後面每一章遇到「為什麼要這樣」的時候，答案幾乎都能追溯回這裡。
記事を読む →資料流向：單向資料流與狀態的位置
第 1 章講的是單一元件內部：狀態算出畫面。 真實應用有幾十層元件，這一章回答的問題是： 狀態在元件樹裡怎麼流動、應該住在哪裡。 公司程式碼裡那些「為什麼狀態放這層」「為什麼要傳 onXxx 回呼」的疑惑，答案都在這裡。
記事を読む →重新渲染的時機：何時發生、如何控制
「這個元件為什麼一直重新渲染」大概是前端工作裡最常見的效能疑問， 而多數人是靠著口耳相傳的規則在猜。這一章把規則追到源頭： 觸發渲染的來源其實非常少，把它們列乾淨，剩下的行為都能推導出來。
記事を読む →Hooks：為什麼存在、為什麼長這樣
你每天都在用 hooks，但「為什麼 React 要發明 hooks」這個問題的答案， 決定了你會把它們用在對的地方，還是只是照抄範例。 這一章先回到 hooks 誕生前的世界，看清楚它要解決的問題， 再逐一拆解每個 hook 的設計理由。
記事を読む →元件設計：拆分、組合與 API 思維
前四章講 React 的運作規則；這一章開始講設計—— 同樣的需求有很多種寫法都「能動」，差別在半年後好不好改。 元件設計的核心視角轉換只有一句話： 元件是一個 API，props 是它的介面，使用它的同事（包括未來的你）是它的用戶。
記事を読む →TypeScript 型別系統：從「標註」到「建模」
用了三個月 TypeScript 的人，多半把型別當成「寫完程式後補的標註」， 遇到紅線就想辦法讓它消失（必要時 as any）。 這一章要完成一個視角升級：型別是建模工具—— 先用型別把「什麼是合法的資料與操作」描述出來，讓編譯器替你守住這個模型。 第 5 章結尾的「讓不可能的狀態無法表達」就是這個視角的實戰預告。
記事を読む →TypeScript × React：型別的實戰應用
第 6 章建立了型別系統的模型，這一章把它接到 React 上—— 目標是讓你讀懂（並寫出）公司程式碼裡那些型別技巧的「為什麼」。
記事を読む →元件實戰：從零打造一個浮動視窗
前面章節的元件，工作大多是「資料進、畫面出」；浮動視窗是另一種生物—— 它要跟瀏覽器的座標系統、指標事件、疊層順序打交道，還得在高頻互動下保持流暢。 這類元件最容易寫成「能動就好」的一團事件處理器，也因此最能檢驗你對 React 模型的掌握。 這一章從需求開始，完整打造一個 FloatingWindow： 可拖曳、可縮放、可堆疊、支援鍵盤與觸控。 每一步都不是新魔法，而是前七章觀念的落地。 建議打開導讀提到的實驗專案跟著做——這章的程式
記事を読む →綜合實戰：把觀念組裝成一個完整功能
第 1 到 7 章的觀念是零件，第 8 章用它們打造了一個元件，這一章做最後的總裝。 需求選一個幾乎每家公司都有的頁面：使用者管理—— 搜尋框（防抖）、結果表格、分頁、載入與錯誤狀態。 程式碼會完整走一遍，但重點放在每段旁邊的「為什麼」。
記事を読む →附錄：速查表、練習與資源
@XX@ 你的需求 & 工具與依據 值改變時畫面要跟著變 & useState（第 4 章） 值可以從其他 state／props 算出來 & 不要開 state，渲染時用 const 算（第 2 章） 計算昂貴，或需要穩定引用給 memo／依賴 & useMemo／useCallback（第 3 章） 值改變但畫面不需要反應（計時器 id、連線實例、最新值鏡像） & useRef（第 4 章） 需要與外部系統同步（訂閱、連線、DOM
記事を読む →