我对Redux状态树中的内容感到有点迷失。
我看到了关于在状态树中存储什么的两个相互矛盾的陈述。
产品的原始列表作为道具传递，因此不是州。搜索文本和复选框似乎是状态，因为它们随时间变化并且无法从任何事物计算。最后，过滤的产品列表不是状态，因为它可以通过将原始产品列表与复选框的搜索文本和值组合来计算。
对于我们的待办事项应用，我们希望存储两种不同的东西：
- 当前选定的可见性过滤器;
- todos的实际列表。
您经常会发现需要在状态树中存储一些数据以及一些UI状态**。这很好，但是尝试将数据与UI状态分开。
所以React告诉我们不应该存储数据（我说的是todos的数据），对我来说，Redux反过来说。
根据我的理解，我倾向于React方面，因为React和Redux都旨在通过存储来预测UI状态：
所有无法计算的内容（例如：所有人类输入）并且是UI的一部分：
所有最小数据，可用于构建查询并将其发送到API /数据库，该API /数据库将返回完整的用户个人资料，朋友列表，等等......：
对于我排除所有数据库/ API结果，因为：
那你在这里有什么看法？
答案 0 :(得分：7)
有关查看组件状态的文档，但有关应用程序状态的Redux文档。因此，定义之间没有冲突。
如果我们谈论 Redux - 您可以使所有组件都没有状态（并在react-redux的connect函数的帮助下将无状态根组件转换为有状态）。如果您从服务器获得大量响应并使用分页/过滤器显示数据，则可以将应用程序状态视为您在屏幕上看到的内容，而不是将所有数据放入Redux存储中，只需将render所需的内容（例如，显示页面的100行和显示分页的总行数。 此没有限制。您可以将整个数据放入另一个地方。例如，在 web-worker 中的另一个数据容器中（我在web-worker中发出完整请求，并从那里获取只需要显示的数据）。
编辑完问题后添加：
产品的原始列表作为道具传递，因此不是状态。
在该示例中，产品列表不是状态的原因 - 它已经在props中。这意味着父组件之一将其作为状态。
答案 1 :(得分：0)
我觉得问题在于，最初Redux被推得非常努力，有些人是如此纯粹主义者，他们主张将所有内容分离到Redux并在每次更改时重新呈现整个应用程序。然后我们最终得到了this response的创建者，这实际上只增加了一个混乱，因为redux过去并且仍然是新反应应用程序的事实上的标准，很多教程都假设它。
所以，我觉得人们都受到了各方的压力，而且他们常常在没有真正理解他们应该做的事情的情况下做一些事情（特别是新手创造常数，行动和减少者）。因此，对于那些阅读它的人，请从没有redux开始，并将其保持在本地状态（但尝试保留一些组件，如DataContainer）。
对于那些需要redux的人来说，rule thumb是将所有异步数据（所有请求都通过redux）和独立组件所需的数据放在一起。如果组件显然位于附近，请将其保持在本地状态并作为道具传递。
Redux是一个非常有用的库，但只有在你开始拥有至少几个路由，不同的查询选项和一些复杂的UI之后才需要它。在此之前，你很有可能过度工程（但是，当然，如果你确定你将超过这个规模，请随意从Redux开始）。而且，你真的永远不会想把你的滑块或小的下拉位置放在商店里 - 反应的状态完全适合它。