跳至主要內容

Redux 常見問題：商店設定

目錄​

商店設定​

我是否可以或應該建立多個商店？我可以直接匯入我的商店，並在元件中自行使用嗎？​

原始的 Flux 模式說明在一個應用程式中有多個「商店」，每個商店都包含不同的領域資料。這可能會造成問題，例如需要一個商店「waitFor」另一個商店更新。在 Redux 中不需要這樣做，因為資料領域之間的分隔已經透過將單一 reducer 分割成較小的 reducer 來達成。

與其他幾個問題一樣，在頁面中建立多個不同的 Redux 商店是可能的，但預期的模式只有一個商店。擁有單一商店可以讓您使用 Redux DevTools，讓資料的持久化和重新整理更簡單，並簡化訂閱邏輯。

在 Redux 中使用多個商店的一些有效原因可能包括

  • 解決由狀態的某些部分過於頻繁更新所造成的效能問題，在對應用程式進行設定檔分析後確認。
  • 將 Redux 應用程式孤立為較大型應用程式中的元件，在這種情況下，您可能想要為每個根元件實例建立一個儲存庫。

但是，建立新的儲存庫不應該是您的第一個直覺，特別是如果您來自 Flux 背景。請先嘗試組合器，並且只有在它無法解決您的問題時才使用多個儲存庫。

類似地，雖然您可以透過直接匯入您的儲存庫實例來參照它，但這不是 Redux 中建議的模式。如果您建立一個儲存庫實例並從模組中匯出它，它將會變成一個單例。這表示如果這有必要，將會更難將 Redux 應用程式孤立為較大型應用程式的元件，或是啟用伺服器呈現，因為在伺服器上您想要為每個要求建立個別的儲存庫實例。

使用 React Redux，由 connect() 函式產生的包裝類別實際上會尋找 props.store（如果它存在），但最好將您的根元件包裝在 <Provider store={store}> 中，並讓 React Redux 負責傳遞儲存庫。這樣元件就不需要擔心匯入儲存庫模組，而且在稍後孤立 Redux 應用程式或啟用伺服器呈現會容易得多。

進一步資訊​

文件

討論

我的儲存庫增強器中可以有多於一個中間軟體鏈嗎？中間軟體函式中的 next 和 dispatch 有什麼不同？​

Redux 中間軟體的作用就像一個連結串列。每個中間軟體函式可以呼叫 next(action) 將動作傳遞給下一個中間軟體，呼叫 dispatch(action) 以在串列開頭重新開始處理，或什麼都不做以停止進一步處理動作。

這個中間軟體鏈是由建立儲存庫時用於 applyMiddleware 函式的引數所定義。定義多個鏈無法正確運作，因為它們會有明顯不同的 dispatch 參照，而且不同的鏈實際上會斷開連接。

進一步資訊​

文件

討論

如何訂閱狀態的某個部分？我可以將已發送的動作作為訂閱的一部分嗎？​

Redux 提供一個單一的 store.subscribe 方法，用於通知監聽器儲存庫已更新。監聽器回呼不會收到目前的狀態作為參數，它只是一個表示某個東西已變更的指示。然後，訂閱器邏輯可以呼叫 getState() 來取得目前的狀態值。

此 API 旨在成為一個低階原語，沒有依賴關係或複雜性，可用於建構高階訂閱邏輯。UI 繫結（例如 React Redux）可以為每個連接的組件建立一個訂閱。也可以撰寫函式，用於智慧地比較舊狀態和新狀態，並在某些部分變更時執行額外的邏輯。範例包括 redux-watch、redux-subscribe 和 redux-subscriber，它們提供不同的方法來指定訂閱和處理變更。

為了簡化實作儲存庫增強器（例如 Redux DevTools），新的狀態不會傳遞給監聽器。此外，訂閱器旨在對狀態值本身做出反應，而不是動作。如果動作很重要且需要特別處理，可以使用中介軟體。

進一步資訊​

文件

討論

函式庫