大型應用程序中的拆分減速器

我嘗試在我的應用程序中通過不同的邏輯部件來組織我的reducer（combineReducers）。大型應用程序中的拆分減速器

例

user: ..., 
app: ..., 
news: ..., 
etc.

但有一些問題的。我構建了一個類似社交媒體應用程序（不完全），我只有2個減速器，如app和user，應用程序中的所有邏輯在用戶附近工作（消息，遊戲，朋友..），我不知道如何拆分它們。

這將是偉大的，如果任何人有一個經驗，並可以告訴我的東西。謝謝。

來源

2016-08-25 nl pkr

你讀過[redux docs]（http://redux.js.org/docs/api/combineReducers.html）嗎？您只需要分別定義2個reducer函數，將它們合併，並使用創建商店的組合版本。 – Igorsvee

如果你問如何分割appReducer和userReducer，則：

//appReducer.js 
export default() => { 
    ...logic 
} 

//userReducer.js 
export default() => { 
    ...logic 
} 

//your store 
import appReducer from './appReducer'; 
import userReducer from './userReducer'; 
const store = createStore(combineReducers({ app: appReducer, user: userReducer}));

如果你問如何分割你的userReducer，因爲你覺得reducer變得太大了，那麼你必須從userReducer中取出它們並製作messagesReducer，friendsReducer等等......僅僅因爲你覺得它們是「用戶」對象的一部分，這並不意味着你必須把它們放在同一個userReducer中。這就是您的動作類型，以及flux/redux數據流可以幫助您。

來源

2016-08-25 09:30:30 goldbullet

是的，我的意思是第二部分。但是如何選擇User reducer中的內容以及哪些不是。我知道這是「非常好的問題」，但有關這方面的文章？ –

我還沒有看到任何全面的，但具體在你的情況下，我會說任何關於「用戶」，如電子郵件地址，用戶名，id，profileImageURL等應直接在userReducer和其他用戶「擁有」像消息一樣，朋友，遊戲可以擁有自己的減速器。我知道你可以爭辯說，一切都是「有」，但我會考慮數據的預期大小和複雜性，包括數據隨時間變化的頻率以及會話期間可能影響數據的方式的數量該應用程序，看看是否值得自己的減速器。 – goldbullet

謝謝你。好答案。 –

，只要你想

userReducer.js

export default combineReducers({ 
    messages, 
    games, 
    friends 
});

appReducer.js

export default combineReducers({ 
    ...otherStaff 
});

mainReducer.js您可以將盡可能多的減速

import user from './userReducer'; 
import app from './appReducer'; 

export default combineReducers({ 
    app, 
    user 
});

但它是一個很好的做法，讓您的狀態標準化，避免深度嵌套

來源

2016-08-25 09:25:41

你想要什麼，我認爲你的代碼是可以維護的。將一個新功能添加到代碼的特定部分，或者查找困擾用戶的錯誤應該很容易。

拆分你的reducer是一個好辦法。你知道如果你知道如何命名reducer並確切知道哪種邏輯是在那裏的話，你已經將代碼分開了。這有助於未來開發人員輕鬆找到修復錯誤時需要修改的文件。

您還沒有給我足夠的信息來幫助您決定如何分割它，但這裏有一些經驗法則。

認爲你的組件的。如果映射整個「用戶」意味着顯示消息的組件還必須消化該減速器中的「朋友」屬性，那麼可能應該將其分爲messageReducer和friendsReducer。這對你很有好處，因爲對消息的更改不需要影響訂閱該減速器的組件以外的任何組件。
想想你的動作。如果1個reducer監聽100個動作，那麼您的代碼將難以遵循，因爲您已經爲您的商店構建了一個耗盡的API。另外，如果您只有一個偵聽器執行1個操作，那麼您無法正確使用操作，您只需構建一個長的命令堆棧。你想要的是幾個減速器在聽同樣的動作。例如：ajax請求已完成，這是修改列表的好時機;將網絡進度狀態切換到完成狀態;發送額外的分析事件;等3個完全獨立的行動，其餘的不關心。
認爲你的AJAX的 - 你的服務器響應要麼包含許多不同類型的數據，或單條信息的大的有效載荷。讓「朋友」減速器處理「朋友」API將很容易遵循，比「用戶」減速器遵循整個服務器API要容易得多。
想想你的複雜性。如果用戶減速器處理所有動作的5％，其餘的只是「朋友」動作，那麼也許你需要將朋友動作分爲「建議好友」，「添加好友」等。這是你會聽到的地方很多不同的意見 - 我個人寧願有兩個減速器，都聽「添加朋友」事件，並且每個人都在做他們的事情（在本節中，建議的朋友需要篩選出添加的朋友和「添加」需求添加好友「），這是乾淨多了那麼長的事件處理函數，其中這兩個事情發生。在一個錯誤‘推薦的朋友’顯然是在‘建議朋友們減速’。

無論如何，這是我的2美分，祝你好運

來源

2016-08-25 19:18:19 NiRR

大型應用程序中的拆分減速器

回答

相關問題