我觀察到使用Redux 儲存的開發人員有一個常見模式:當面對新的但略有不同的需求時,他們經常創建新功能並重寫通用樣板程式碼,包括減速器、thunk、動作和中間件。這可能會導致程式碼庫中出現大量重複。
我們不能完全責怪開發人員,因為標準化和團隊最佳實踐通常是由團隊領導完成的...
但是,當 API 或微服務標準化時(其中刪除、建立、放置和獲取等端點遵循可預測的結構),可以建立可以動態產生 Redux 減速器和操作的高階函數。這減少了冗餘並鼓勵更具可擴展性的架構。以下是如何實現這一點的範例:
https://gist.github.com/ARAldhafeeri/1ad10710bee110b9a88013984272fbbd
它有 200 行程式碼,這裡有一個範例用法,它的作用是:
-
動態 Redux 切片建立: 函數 createEntitySlice 為實體(如預訂或使用者)產生 Redux 切片,讓開發人員可以使用最少的樣板程式碼輕鬆建立、讀取、更新和刪除任何實體的資料。
-
可自訂參數:函數接受可自訂參數,例如entityName、endpoints、extraReducers、extraThunks和extraActions,為不同實體和特定需求提供彈性。
-
基本 CRUD thunk: 它為獲取、建立、更新、刪除和搜尋等常見操作提供基本非同步 thunk,這些操作根據提供的端點與 API 進行互動。這些 thunk 管理必要的 API 呼叫並處理錯誤。
- 用於狀態管理的Reducers:切片包含用於管理載入狀態、儲存取得的資料、處理錯誤以及執行搜尋和重置狀態等操作的Reducers。
-
中介軟體整合:程式碼整合了偵聽器中間件來處理副作用,例如根據 CRUD 操作的結果顯示成功或錯誤訊息。它還增強了中間件,使其能夠自訂狀態變更的行為,例如在滿足某些條件時觸發其他操作。
-
最佳化的程式碼可重用性:透過使用這種高階函數方法,開發人員可以避免重複的樣板程式碼,並為不同的實體建立可重複使用的動態切片,而無需每次手動編寫操作和化簡器。
-
可擴展和模組化: 高階函數從redux 儲存中產生某個功能所需的功能,我們也可以將其中的所有內容從減速器擴展到初始狀態,因此當自訂端點到達時,它不會完全融入我們創建的通用基礎中,我們可以簡單地添加它。
最好的,
艾哈邁德,
以上是我如何在不破壞應用程式的情況下用 Just in Redux Store 替換程式碼行!的詳細內容。更多資訊請關注PHP中文網其他相關文章!