打破混亂循環：Redux 循環依賴之旅

最近，我在 Redux 程式碼庫中偶然發現了一個讓我摸不著頭緒的錯誤。如果您曾經在測試套件拋出毫無意義的錯誤時感到突然的混亂，您就會知道這種感覺。這是發生的事情以及我最終如何發現（並解決）問題的。

循環依賴到底是什麼？

當兩個或多個模組直接或間接相互依賴時，就會發生循環依賴，從而在依賴鏈中創建無限循環。換句話說，就像兩個朋友說：“你先走”，但沒有人行動。在 JavaScript 中，這可能會導致未定義的模組或不完整的數據，從而導致難以追蹤的錯誤。

罪魁禍首：一個例子

想像兩個 JavaScript 文件，moduleA.js 和 moduleB.js：

// moduleA.js
import { functionB } from './moduleB.js';
export function functionA() {
  console.log('functionA called');
  functionB();
}

// moduleB.js
import { functionA } from './moduleA.js';
export function functionB() {
  console.log('functionB called');
  functionA();
}

在這裡，兩個模組相互依賴。當 JavaScript 嘗試載入它們時，它會感到困惑，因為如果對方沒有先準備好，則兩者都無法完全載入。這會導致諸如未定義的函數或不完整的模組之類的問題——基本上是一團糟。

那麼，我是如何找到我的循環依賴的呢？

啊，可怕的錯誤開始了這次冒險：

Error: `reducer` is a required argument, and must be a function or an object of functions that can be passed to combineReducers.
 ❯ Module.configureStore node_modules/@reduxjs/toolkit/src/configureStore.ts:98:11

我的第一個反應？ 「等等，什麼？！」—這不是我最好的時刻。我確信我的減速器已就位，所以這個錯誤似乎是無中生有的。經過一番挖掘，我意識到這不是一個缺少減速器的問題，而是一個循環依賴潛入我的 Redux 設定中。當然，弄清楚這一點並不容易！

真正的英雄：dpdm

就在那時我找到了我的救星：npm 包 dpdm。這個 gem 分析您的依賴關係樹，並向您顯示那些偷偷摸摸的循環依賴關係所在的位置。運行以下命令給了我一個清晰的視圖：

dpdm --no-warning --no-tree ./src/index.tsx

瞧！以下是它在我的專案中發現的內容：

• Circular Dependencies
  01) src/stores/store.ts -> src/stores/rootReducer.ts -> src/stores/slice/authSlice.ts -> src/utilities/api.ts
  02) src/stores/rootReducer.ts -> src/stores/slice/bookingSlice.ts -> src/hooks/redux.tsx -> src/stores/types.ts -> src/stores/setUpStore.ts
  03) src/stores/types.ts -> src/stores/setUpStore.ts
  ...

解決方法：重構時間！

報告很清楚：我的 Redux 檔案中存在大量循環依賴項，主要在 store.ts、rootReducer.ts 和一些切片中。在拆分了一些邏輯、打破了不必要的依賴關係並重構了程式碼之後，我終於恢復正常了。

經驗教訓

• 循環依賴是偷偷摸摸的：它們通常直到運行時或單元測試期間才會出現，這使得它們很難追蹤。
• 像 dpdm 這樣的工具是救星：不要浪費時間手動搜尋導入。讓工具來完成繁重的工作。
• 重構是你的朋友：有時循環依賴是糟糕架構的標誌。良好的重構不僅可以解決眼前的問題，還可以讓您的程式碼庫更乾淨且更易於維護。

所以，下次當你遇到這些討厭的錯誤時，喝杯咖啡，開懷大笑，打破這個循環！

調試愉快！ ？