现实生活中的 Redux 方式答案

【问题标题】：Redux-way in the real life现实生活中的 Redux 方式
【发布时间】：2017-03-31 03:55:21
【问题描述】：

我想向社区询问一个意识形态问题。让我们想象一下 react/redux 上的 todo-list，你有一个单一的状态来提供 todoItems 数组。但是现在让我们想象一下，我想在页面上使用一些组件来渲染具有不同 UI 的 todoItems。我需要在 todoItems 的 CRUD 上更新每个这些组件。您对这个问题的架构方法是什么？不要忘记我们有一个大型数据库，我们只能通过分页获取 todoItems。

更新：

让我们说清楚。当我们使用这个 UI 实现 redux 生命周期时，我们有 2 个选项：

1) 将一组 todoItems 提供给单例 redux 状态对象。优点：我们所有的组件都会随着对象的变化而更新。问题：我们无法从数据库中获取所有数据，但必须显示不同的分页/过滤数据，因此我们无法在前端实现分页/过滤。我们有几个不同的组件，并且必须渲染不同的对象集合。所以不合适。

2) 我们可以使用不同的键进入我们的全局 redux 状态。优点：我们可以独立获取每个组件的数据问题：当其中一个对象发生变化时，其他组件不会感觉到。在这种情况下，我们必须编写自定义代码。

我只是想知道也许我遗漏了一些东西，我们还有其他选择，或者也许有人对这个问题有很好的架构方法。

【问题讨论】：

你在redux方式中看到的问题是什么？你仍然有单个状态树，可以根据需要更新，所以你可以组织缓存等等，所以如果数据很大或分页，那根本不是问题。
我已经更新了问题

标签： reactjs redux

【解决方案1】：

我敢打赌，您的复杂情况来自不幸的是在redux 社区中很常见的观点：试图使redux 形状尽可能接近 UI 形状。

尽量不要将redux 状态视为Component 状态的替代品。 redux 应该知道的只是实际的待办事项（id、标题、创建日期等）。让Component 特定的数据（例如分页内容）处于Components 状态。当用户以Components 之一进入下一页时，应该更新的是Component 状态（pageNumber、from、to、amount 等）。 redux 应仅在必要的待办事项丢失的情况下更新。

有用的类比是将您的 redux 视为良好的旧 SQL 数据库：redux 存储状态是数据本身，selectors 和 actions 是查询和存储过程，React Components 是选定的视图数据。

更新：好的，您正在寻找的似乎是状态规范化。从ids 的列表中分离todos 详细信息。这样todo 字段的更新将被所有Components 感知。另一方面，您可以将todos 的单独集合保存在不同的Components 中。即使状态看起来像这样：

{
   funnyTodos: [ 'id1', 'id2' ],
   boringTodos: [ 'id3', 'id4' ],
   recentlyDoneTodos: [ 'id1' ],
   todos: {
     id1: { name: .... },
     id2: { name: .... },
     id3: { name: .... },
     id4: { name: .... },
   }
}

在这种情况下实现分页只需从后端获取下一页的todosids 列表，然后为给定的ids 加载缺少的todos。

【讨论】：