重構脂肪減少者

Question

我正在使用類似React的方法處理我的項目，我的問題是我的減肥者非常「平坦」，但他們需要處理不同狀態樹區域中的許多更新，以便他們獲得更多並且更復雜。

例如，在分派動作'DO_SOMETHING'後，首先我需要在3 LOC內更新我的狀態，但是當項目增長並且需要處理其他功能時，有人希望看到基本結果+額外的東西執行相同的操作後。所以你可以想象，花了數週時間後，減速器變得「變胖」，它們以同樣的方式觸及同一棵樹的許多不同區域，但是很難在它們中正確構造代碼（一個狀態樹和一個商店）。

在大多數教程我只能找到特定情景的：

• 調度「ADD_TODO」
• 更新狀態，增加新的待辦事項到待辦事項的陣列

，而在我的情況下，它就像：

case SELECT_FILTER: 
    return Object.assign({}, state, { 
     oneProperty: ..., 
     anotherProperty: null, 
     nextProperty: false 
     // and the logic is getting bigger and bigger 
    }) 

• DISPA TCH「SELECT_FILTER」
• 更新應用的過濾器部（施加濾波器的UI摘要），其將被用來獲取從服務器數據
• 清除此
• 複製
• 更新查詢
• 下個月此過濾器應還...

：/

我試圖打造 「臺減速器」 - 篩選減速器，減速名單，等等但問題在於我在同一頁面上工作，並且傳入的功能引入了交叉更改。在較小的應用程序中，簡單的分組是可以的，但是現在每個縮減器似乎都對我的狀態的許多部分感興趣。

所以我的問題是如何適當地構建我的減速器？也許我把過多的「本地狀態」放入狀態樹？或者是其他東西？我期待着看到你的解決方案與組成和構造減速器相關。

Answer 1

方便的是，去年我寫了一個名爲"Structuring Reducers" :)的Redux文檔。它演示了幾種用於組織和編寫減速器邏輯的有用技巧。尤其是，您可能對"Beyond combineReducers"和"Reusing Reducer Logic"中的部分感興趣。

我的"Practical Redux" tutorial series也演示了一些更先進的減速機結構，特別是後Practical Redux, Part 7: Form Change Handling, Data Editing, and Feature Reducers。

也可能需要考慮調度多個「原始」動作，這些動作可以按順序分派以形成更大的行爲。例如，您可能有一個thunk，連續發送BASIC_UPDATE，SPECIFIC_EXTRA_UPDATE_1和SPECIFIC_EXTRA_UPDATE_2。有關於性能需要注意的問題，但這是一種有效的方法（並且可以使用各種批處理策略來解決性能問題）。有關更多信息，請參閱我的Redux插件目錄中dispatching multiple actions和reducing store notification events的Redux FAQ條目，我的博客文章Idiomatic Redux: Thoughts on Thunks和Store#Store Change Subscriptions部分。