zustand 和 jotai 是當下比較流行的react狀態管理庫。其都有著輕量、方便使用，和react hooks能夠很好的搭配，並且效能方面，對比React自身提供的context要好得多，因此被很多開發小夥伴所喜愛。
更有意思的是，這兩個庫的作者是同一個人，同時他還開源了另外一個狀態庫 valtio，並沒來得及研究（表示卷不動了😭），這三個庫的實現思路卻是不同的，號稱是以一己之力攪亂React 狀態庫生態圈的人。
Comparison: https://docs.pmnd.rs/zustand/getting-started/comparison
注：文中如有理解不正確點，可以隨意指出。 圖片如果看不清，可以私信我發。
zustand
zustand的實現原理相對簡單，全域性生成一個store，提供getState,setState以及subscribe，因此天然和React 18提供的useSyncExternalStore配合使用。
大致的原理：當set狀態之後，useStore中會監聽整個store的變化，然後同步元件中的狀態，使受影響的元件重新更新。
BestPractise & 最佳化
透過程式碼分析，如果不想做一些無意義的render，推薦使用selector。使用selector主要有兩個方面的優點：
- 只返回元件自身關注的state，如果state沒有變化，元件不會重新整理，否則一旦store變化，state沒有變化的元件也會隨之重新整理
- 由於
useSyncExternalStoreWithSelector本身提供的getSelection方法帶有快取效果，如果兩次的snapshot相同，則不會進行selector的重複計算，這對於selector中如果本身有複雜邏輯的無疑是有效能最佳化的。 - zustand是基於immutable資料的改變來引起元件重新渲染的，記得不要直接在物件中改值，而是返回一個全新的物件，這點可以配合 immer 使用，zustand也提供了相應的 middleware。
- best parctise
jotai
jotai的理解難度相對而言就難一些，jotai推崇原子化，透過基礎的atom派生出更復雜等級的atom，因此jotai天然支援computed屬性，對於zustand而言，想要實現computed屬性，則需要魔改setState來達到目的。
原理
- 在
readAtom的時候，會順次生成這個原子的依賴，維護在自身atomState的d(depedencies)中，這將形成一個樹形連結串列。 - 在
subscribleAtom的時候，會根據該原子的依賴項，生成dependent，這樣做的目的是當該原子進行重新設值時，能夠根據他的dependent來重新計算依賴它的原子的值，dependent會維護在mountedMap中，只有當sub之後，Atom才會被加入到mountedMap中。 - 在
writeAtom時，會根據mountedMap中的dependent，重新計算收到影響的原子，並且呼叫該原子的以及在mountedMap中受到影響的原子的listeners，這樣會觸發元件中收到影響的原子重新獲取到最新的值。 - 在React部分就相對簡單一些，
Provider維持一個全域性的store，方便各個useAtomValue進行sub。useAtomValue會監聽原子的變化，從而進行rerender，以便獲取到最新的值。useSetAtom呼叫writeAtom。
BestPractise
搜了一圈，官網好像沒有最佳實踐的建議，個人根據一些理解，提出一些：
- atom應該儘量小，每個原子儘量做的事情比較單一，不然全域性一個atom進行subscribe並沒有意義
- 相關的atom原子應該儘量在維護在一個檔案中，避免不必要的上下文切換，使得程式碼變得難以理解
- 對於比較複雜的邏輯，透過派生原子或者組合原子的方式來維護
- 只需要更新atom的時候，只需要呼叫
useSetAtom就好，不subscribe就意味著不需要關心該atom的變化，從而不會引起不必要的更新
總結
沒有總結，卷不動了。