React / Redux概念与服务器调用请求相对应

Question

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

例如，您希望获得当月的所有待办事项：

1. 减速器/存储方法
   您可以从商店获取所有待办事项列表，并按日期过滤待办事项以获取当月的所有待办事项。
   • 优点：
     CRUD操作易于管理，商店中的一个状态发生变化（待办事项列表）
     低客户端/服务器流量
   • 缺点
     客户端的业务逻辑
     大数据处理的客户端开销
2. Sql请求方法：
   数据库中的复杂请求以获取这些待办事项并将状态“currentMonthTodos”保存在商店中。在这种情况下，您可以从currentMonthTodos状态获取当前月份Todos列表
   • 优点：
     服务器端的业务逻辑
     减少大型数据的页面加载时间
   • 缺点
     CRUD行动的国家管理不善
     高网络流量
     商店的规模越来越大

Answer 1

  

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

通常，您使用Redux进行的实际应用程序是中等或大规模的。您可以采用任何一种简单的CRUD应用程序。

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

对于非常简单的应用程序，除非您需要高级视觉效果，否则Redux模式并没有多大意义。

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

如果我们有大量可以交互的应用程序组件，那么Redux的想法非常出色。在Redux中，这些将被称为容器组件，它们与简单的表示组件不同，它们也被称为无状态功能组件。

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

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

只有三个组件相互作用，我们有更多可能的链。

随着更多的组件，它变得复杂。我们用Redux模式消除了可能的指数交互复杂性。如果您使用其他编程语言中的这些接口，则Redux模式类似于IDispatch，IObservable。

一个用于吐出动作，另一个用于进入商店内存在的监听器链。

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

在React组件中创建操作。有时很多动作。事实上，在某些情况下你可能会得到很多动作，所以如果你的设计不好，应用程序就会冻结。

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

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

我刚刚写了这个来表示Redux模式的初始复杂性，而Restful应用程序设计简单。

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

https://egghead.io/lessons/javascript-redux-store-methods-getstate-dispatch-and-subscribe?course=getting-started-with-redux