重構的技術選型

[s103071049]

嗨以，大家好～

好久不見了，最近公司在進行專案的重構，在技術選型上碰到了左右為難，作為大人果然都好想要，所以想來問問大家，如果是這種狀況，你妳你會想怎麼做呢？

某頁面會經過一連串的資料處裡，整理出至少三包資料，這個頁面至少有七個按鈕點開會呈現出各自的彈窗，不同彈窗畫面複雜度不同，有的會再有 tab 然後底下會再有他的子元件，子元件會再有孫元件，孫元件可能底下還會再有，這是神一般的東西，總之孫元件會需要他父層的那三包資料的某某。但一次也只會點開一個按鈕而已。

這個元件肯定會有一系列 prop drilling 的問題ＸＤ

因為 recoil 用正交的方式傳遞數據，讓 render 的效果更好。但一般情況組件樹不深似乎沒有影響，我不確定我這樣的狀況算不算深。用 context 算不算合適的選擇？但用了 recoil 等於是墊高了維護與開發的難度，無可避免學習成本會增加，我個人是覺得不需我為了用而用，但這樣的情境又讓我在左右為難到底該不該用 recoil ?

怎麼樣的情況你會判斷組件樹算深的？以五層作為標準嗎？

補充個，我發現 Jotai 似乎也不錯，還更簡化 recoil。

越瞭解越多，發現越難抉擇，附上狀態管理的分享文章：https://medium.com/%E6%89%8B%E5%AF%AB%E7%AD%86%E8%A8%98/a-comparison-of-react-state-management-libraries-ba61db07332b

[aszx87410]

我不是很喜歡 recoil 那種以單個單個狀態（atom）分割的形式，有看過這樣的專案，維護到後面很亂，因為 atom 沒管理好的話可能來自於各處，超難追蹤

要狀態管理的話我推核心概念跟 redux 很像（相信我們都很熟 redux 了）的 zustand，但使用上簡單方便，以你提問的這個情境來說，就專門開一個 store 給這些狀態用，追蹤起來也方便

不過狀態管理我主要用的地方是底下的元件不只要讀，還需要寫，就會直接上狀態管理，只讀的話往下傳個三層我還可以接受，再下去應該就要想其他方式來簡化了，狀態管理是一種

[s103071049]

謝謝老師ＸＤ兩個都摸索了一陣子，的確 zustand 資料流由上到下會比較好追，jotai 會需要寫一些文件跟畫流程圖，維護到後面可能會有
很亂的風險。