React/Redux 概念与服务器调用请求答案

【问题标题】：React/Redux concept Vs server call requestsReact/Redux 概念与服务器调用请求
【发布时间】：2017-06-15 19:16:20
【问题描述】：

我想知道在数据库中使用大状态（存储）和 sql 请求之间的最佳设计方法是什么。假设您有一个 Todo CRUD 应用程序。你可以在 Redux 实现中将 Todos 列表保存在 store 中。如果您想对这些 TODO 进行复杂的统计，最好的方法是什么：Reducer 或 sql 请求？

例如，您想获取当月的所有待办事项：

【问题讨论】：

【解决方案1】：

假设您有一个 Todo CRUD 应用程序。你可以在 Redux 实现中将 Todos 列表保存在 store 中。如果您想对这些 TODO 进行复杂的统计，最好的方法是什么：Reducer 或 sql 请求？

通常，您使用 Redux 执行的实际应用程序是中型或大型的。简单的 CRUD 应用程序，无论哪种方式都可以。

我猜当您提到数据库（SQL 请求）时，您认为是 Restful 编程。

对于非常简单的应用程序，Redux 模式没有那么大的意义，除非你需要高级的视觉效果。

但是，小型应用程序确实会随着时间的推移而增长，并且可以通过添加更多组件快速发展为中等规模。

在我们有大量交互的应用程序组件的情况下，Redux 的想法非常出色。在 Redux 中，这些将被称为 容器组件，它们不同于 简单的展示组件，也称为无状态功能组件。

拥有 2 个组件 A 和 B，您只有几个可能的更新链。

A 将更新 B，B 将更新 A，或自行更新（此处不包括来自应用程序外部的可能更新）。

只需三个组件交互，我们就有更多可能的链。

组件越多越复杂。我们使用 Redux 模式消除了可能的指数交互复杂性。 Redux 模式类似于IDispatch、IObservable，如果您使用其他一些编程语言的这些接口。

一个用于发送动作，另一个用于进入 store 中存在的侦听器链。

我们与 GUI 应用程序中的事件驱动方法非常相似——当您移动鼠标时，您会得到事件。

在 React 组件中创建动作。有时动作很多。事实上，在某些情况下，您可能会执行很多操作，因此如果您的设计不好，应用程序将冻结。

通常组件应该限制操作，React 中有很好的解决方案。

那么 React Redux 中的组件是什么？一方面，组件是动作调度器，另一方面，它们获取道具、可能的上下文、可能的应用程序状态甚至本地状态。最后，组件可能具有渲染逻辑。有时组件只是容器。

我写这个只是为了代表 Redux 模式的初始复杂性，而 Restful 应用程序设计简单。

我认为这是您应该考虑的主要因素。可能不需要将 Redux 用于不会增加复杂性的琐碎 TODO 应用程序，因此您可以使用 Restful 应用程序。

【讨论】：

感谢您的回答。只是为了澄清我的问题，商店包含待办事项列表（由 redux 创建）但是如果在同一应用程序的其他页面中我想为用户做一些报告怎么办。我是否需要“查询”商店（待办事项列表）并事后过滤或服务器端的请求（使用 sql）？
不需要服务器端调用，您可以从其他页面访问商店（待办事项列表）。
没错，我能做到。在使用 redux 模式时，我只是在性能、客户端业务逻辑暴露和复杂统计方面检查每种方法的优缺点。
这不是你需要解决的简单方程，更进一步说，Redux 模式目前还没有被牢固地确立为标准。创建它的 Dan Abramov 是一位才华横溢的人，我提供的参考资料会有所帮助。最后，您可能还有至少一个 Dan 为 egghead.io 创建的教程。享受@altruistlife。