Big App 中的 Split Reducer

Split Reducer in Big App

我尝试在我的应用程序中通过不同的逻辑部分来组织我的减速器 (combineReducers)。

例子

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

但是有一些问题。我构建了一个大型社交媒体应用程序(不完全是),我只有 2 个缩减器,如 appuser,应用程序中的所有逻辑都在用户附近工作(消息、游戏、朋友......),我不知道如何拆分它们。

如果有人有这方面的经验并能给我一些建议,那就太好了。谢谢

您可以根据需要组合任意数量的减速器

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
});

但保持状态规范化并避免深度嵌套是一个很好的做法

如果您询问如何拆分 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 等......只是因为你觉得它们是 "user" 对象的一部分并不意味着您必须将它们全部放在同一个 userReducer 中。这就是适合您的操作类型以及 flux/redux 数据流对您的帮助。

我认为您想要的是让您的代码易于维护。将新功能添加到代码的特定部分,或者找到一直困扰您的用户的错误应该很容易。

拆分减速器是解决此问题的好方法。如果你知道如何命名一个 reducer 以及那里到底有什么样的逻辑,你就知道你已经很好地划分了代码。这有助于未来的开发人员在修复错误时轻松找到他们需要修改的文件。

你没有给我足够的信息来帮助你决定如何拆分它,但这里有一些经验法则。

  1. 想想你的组件。如果映射整个 "user" 意味着显示消息的组件还必须消化该减速器中的 "friends" 属性,那么也许您应该将其分为 messageReducer 和 friendsReducer。这对您有好处,因为对消息的更改不需要影响除订阅该减速器的组件之外的任何组件。

  2. 想想你的行为。如果 1 个 reducer 监听 100 个动作,那么你的代码将很难理解,因为你已经为你的商店构建了一个令人筋疲力尽的 API。此外,如果您只有一个侦听器来执行 1 个操作,那么您就无法正确处理操作,您只是在构建一个长命令堆栈。你想要的是几个 reducer 监听同一个动作。例如:一个 ajax 请求已经完成,这是修改列表的好时机;将网络进度状态切换为完成;发送额外的分析事件;等等。 3 个完全独立的动作,对其余动作毫不在意。

  3. 想想你的 ajax - 你的服务器响应要么是包含大量不同类型数据的大负载,要么是单个信息。让 "friends" reducer 处理 "friends" API 将很容易跟踪,比让 "user" reducer 跟踪整个服务器 API 容易得多。

  4. 想想你的复杂性。如果一个 user reducer 处理了所有动作的 5%,剩下的只是 "friends" 个动作,那么你可能需要将朋友的动作拆分为 "suggested friends"、"added friends" 等。 这是你会听到很多不同意见的地方——我个人宁愿有两个减速器,都监听 "add friend" 事件,并且各自做他们的事情(在这个 csae 中,建议的朋友需要过滤掉添加的friend 和 "Added " 需要添加 friend”)。这比发生这两种情况的长事件处理函数要干净得多。"suggested friends" 中的错误显然在 "suggested friends reducer" 中.

无论如何,这是我的 2 美分。祝你好运。