React / Redux概念与服务器呼叫请求 [英] React/Redux concept Vs server call requests
问题描述
假设你有一个Todo CRUD应用程序。您可以在Redux实现中将Todos列表保存在存储中。如果您想对这些TODO进行复杂的统计信息，最好的方法是：减少或sql请求？
例如，要获取当前月份的所有todos：
- 减少/存储方法
您可以从商店获取所有的todos列表，并按日期过滤todos以获取所有todos为当月。
- 优点：
CRUD操作易于管理，商店中的一个状态更改（todos列表）
低客户端/服务器流量 - 缺点
客户端的业务逻辑
用于大数据处理的客户端开销
- 优点：
- Sql请求方法：
在数据库中复制请求以获取这些todos并将状态'currentMonthTodos'保存在商店中。在这种情况下，您得到当前月份Todos列表from currentMonthTodos状态
- 优点：
服务器端的业务逻辑
减少大数据的页面加载时间 - 缺点
CRUD操作的状态管理不佳
高网络流量
商店规模增长
- 优点：
blockquote>
假设你有一个Todo CRUD应用程序。您可以在Redux实现中将Todos列表保存在存储中。如果您想对这些TODO进行复杂的统计：最简单的方法是减少或sql请求？
通常，现实生活中的应用程序你与Redux做大中等规模。简单的CRUD应用程序，你可以做任何一种方式。
我想当你提到数据库（SQL请求）你认为Restful编程。
对于非常简单的应用程序，Redux模式没有什么意义，除非您需要高级的视觉效果。
然而，小应用程序的增长随着时间的推移，可以通过添加更多的组件而变得中等规模。
如果我们有大量应用程序组件进行交互，Redux的想法非常好。在Redux中，这些将被称为容器组件，这些不同于简单的演示组件，也称为无状态功能组件。
有两个组件A和B，你只有几个可能的更新链。
A会更新B和B将更新A或自动更新（不包括在这里从应用程序外部可能的更新）。
只有三个组件交互，我们有更多可能的链条。 p>
与更多的组件一起变得复杂。我们用Redux模式消除了可能的指数交互复杂性。如果您使用其他编程语言的这些接口，Redux模式与 IDispatch ， IObservable 类似。
一个是分发动作，另一个是输入商店内存在的监听者链。
我们非常类似于GUI应用程序中的事件驱动方法;当您移动鼠标时，您将获得事件。
在React组件中创建操作。有时候很多动作。事实上，在某些情况下，您可能会收到如此多的操作，因此如果您的设计不好，应用程序将冻结。
通常，组件应该限制操作，并且有很好的解决方案在这个React中。
那么React Redux中的组件是什么？从一方面，组件是动作调度器，另一方面他们得到道具，可能的上下文，可能的应用程序状态甚至本地状态。最后，组件可能具有渲染逻辑。有时组件只是容器。
我只是写了这个代表初始Redux模式的复杂性，而Restful应用程序通过设计简单。
我认为这是您应该考虑的主要因素。使用Redux可能不需要增加复杂性的微不足道的TODO应用程序，所以您可以使用Restful应用程序。
I am wondering what is the best design approach between using a big state (store) and sql request in database. Let's say you have a Todo CRUD application. You can save the Todos list in store within Redux implementation. What is the best approach if you want to make complex statistics on those TODOs: Reducers or sql requests?
For example, you want to get all todos for the current month:
- Reducers/store approach
You can get all the todos list from the store and filter todos by date to get all todos for the current month.- Pros:
CRUD actions easy to manage, one state changes in the store (todos list)
Low client/server traffics - Cons
Business logic on client side
client overhead for large data processing
- Pros:
- Sql request approach:
Complex request in database to get those todos and save the state 'currentMonthTodos' in the store. In this case you get your current month Todos list from currentMonthTodos state- Pros:
Business logic on server side
Reducing page load time for large datas - Cons
Poor state management for CRUD actions
High network traffic
Size of the store grows up
- Pros:
Let's say you have a Todo CRUD application. You can save the Todos list in store within Redux implementation. What is the best approach if you want to make complex statistics on those TODOs: Reducers or sql requests?
Usually, real life applications you do with the Redux are medium or large scale. Simple CRUD applications you could do either way.
I guess when you mentioned the database (SQL requests) you considered Restful programming.
For the very simple applications, the Redux pattern doesn't have that much sense, unless you need advanced visual effects.
However, small applications do grow over time and can become medium scale fast, by adding more components.
Redux idea is excellent in cases we have a great number of application components that interact. In Redux these will be called the container components, and these are different from the simple presentational components that are also known as stateless functional components.
Having 2 components A and B you have just a few possible update chains.
A will update B and B will update A, or self-update (not including in here the possible updates from outside of the app).
With just three components interacting we have much more possible chains.
And with even more components it gets complicated. We eliminate the possible exponential interaction complexity with the Redux pattern. Redux pattern is similar to IDispatch, IObservable if you worked with these interfaces from some other programming languages.
One would be for spitting the actions, and the other for entering the listener's chain that exists inside the store.
We get very similar to the event driven approach in GUI applications — when you move the mouse you get the events.
In React components create actions. Sometimes a lot of actions. In fact, you may get so many actions in some cases so the application will freeze if you have the bad design.
Typically components should throttle the actions and there are great solutions in React for that.
So what are components in React Redux? From one side components are action dispatcher and on the another side they get the props, possible context, possible the application state or even local state. Finally, components may have the rendering logic. Sometimes components are just containers.
I just wrote this to represent the initial complexity of the Redux pattern while Restful applications are by design simple.
I think that this is the main factor you should take into account. Using Redux for the trivial TODO applications that will never grow the complexity may not be needed, so you may go with the Restful app.
这篇关于React / Redux概念与服务器呼叫请求的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
