一、研究動機
希望節省手動傳遞全域性資料 / 函式所需的人工,例如:
- 處理未登入 / 權限不足 / api 逾時的函式,需要傳遞給所有會用到 api 的 components
- 多個不同 api 回傳的資料,各自需要傳遞給多個會取用該資料的 components
- 將來可能會需要支援的 theme 設定,也會需要傳遞給所有樣式受影響的 components
二、研究材料
- [看完] react context 課程
- [看完] react hooks 文件
- [看一半] react hooks 課程(基礎)
- [還沒開始] react hooks 課程(進階)
- [完成] 拿 toy project 試寫
三、研究心得
Context
- 新版 react 內建一種特殊的 component 叫 context,被它包起來以後,底下的 component 不管隔了幾層,都可以自動拿到它的 value,也就是不用手動傳遞上面說的那些 functions 或 data
- 缺點是它的 value 有任何改變,底下被包住的 component 全部會 re-render,產生效能問題。可以用 react 的 memo 功能讓 props 沒更新的 component 不會 re-render
Hooks
- 新版 react 內建一種特殊的 function 叫 hook,可以讓 functional component 變得跟 class component 一樣擁有自己的 state,也可以處理 api call 之類的 side effect,基本上 react 未來方向是用 functional component 完全取代 class component,不過 class component 的支援不會在未來的 react 中拿掉,因為 facebook 自己並沒打算全部重寫以前的 code XD
Context + Hooks
- react hook 也支援 context 功能,以後使用 context 可以少包幾層 component 的皮,程式也會變瘦ㄛ
- 原本全域性的 state 都可以放到 context hook 裡面單獨管理,以後不需要全部塞在 root component 裡面了
- context hook 硬要說缺點的話,就是 context 很多的話 provider 要包很多層吧 XD
上上週做完研究後,上週花了一個禮拜的時間大重構,把 create react app 升到 3.0,然後最根部的 class component 轉換成 funtional component + hooks + context,總共動了四千多行程式碼、橫跨 59 個檔案,工程不可謂不浩大。經歷了這件事,讓我不禁深深地反思...
是不是該增加測試覆蓋率了?率了?率了?率了?...(回音)
加了之後要改的程式碼就會從 4k 變 8k XD
回覆刪除