反应通量/还原态不应该包含计算数据 - 性能问题？

流量的核心原则之一就是让应用在商店中处于最低水平。所有可以基于其他状态数据计算的东西都不应该进入商店。反应通量/还原态不应该包含计算数据 - 性能问题？

当我有一个多重过滤和排序列表不必从一堆的基本状态信息计算出最终名单的想法似乎是一个性能问题。 reselect声称可以在一定程度上解决这个问题，但是对于将状态最终列表保存为状态的说法呢？

来源

2015-12-01 philk

（我假设你的问题是什么，你叫状态实际上是应用程序的状态，即存储/道具，而不是组件状态）

保持列表是与任何缓存性能和

之间的权衡

增加的内存使用
潜在的复杂缓存失效的逻辑，以确定何时该列表是陈旧

作为一般情况下，我会考虑保留任何缓存确实应该做最后的优化（不这样做，不这样做，这样做，也许）

此外，如果组件不（再 - ）安装在每个渲染器上，因此通过componentWillReceiveProps()接收道具更改，有机会决定是否应重新计算列表。如果不需要，返回false在shouldComponentUpdate将保持原样。（该虚拟域是高速缓存）

话虽这么说，有利于高速缓存的一个大因素：避免I/O。如果重建列表涉及I/O并且可以安全地假定列表没有更改，则应该使用缓存。与计算列表

来源

2015-12-01 10:44:59

我的问题没有关系组件。这是关于应用程序状态在一个REDX应用程序。当状态只包含对一组数据进行操作的数据，并且这组数据发生更改时，该状态不会表示当前的数据视图。所以数据通常也保存在状态中。我只是认为，拯救该州所有城市都不是很有用。相反，城市将位于外部，可查询的源代码中，并且查询参数将保存在应用程序状态中。 – philk

好吧....组件（道具）通过选择器与应用程序状态深深联系在一起。将任何东西保持在应用程序状态的唯一原因是因为它必须在组件中显示/使用。那么，为什么要“拯救所有城市......不太可用”。城市的大幅下拉就是：所有城市的缓存。如果它不是'可用'的话，这样的下拉应该根本不存在。如果下拉列表不存在，那么这回到我的第一个评论：为什么保持数据在应用程序状态，因为数据没有被使用？在做I/O /查询？谬误1：网络可靠。移动用户任何人？ –

的一个问题是，他们与“shouldComponentUpdate”是如何相互作用的。如果Redux每次在通量状态中发生任何更改时都重新执行计算，则每次最终都会得到一个不同的列表对象，并且应该ComponentComparation看不到它实际上没有改变（假设它使用某种浅层比较），所以React将最终重新渲染依赖列表的所有组件，以便进行每次更改。对于大量的数据，这可能会使应用程序有些反应迟钝。但是，如果您使用无限滚动技术（即只显示可见的内容），并且没有大量可见组件（例如，不包含1000个小型复选框），则很可能不存在真正的性能问题为每次更改重新渲染（并让React在渲染的JS树上进行差异化处理）。

所有说，重新选择（如果你使用ImmutableJS或类似的话可能会更强大的方法）将通过缓存列表计算的结果给你优化，所以React通常不会最终重新呈现，如果列表没有改变。

但避免了真相，缓存失效问题等多种来源你保持你的应用程序状态的计算清单得到很可能是优选的。如果这样做，所有的地方，那么你最终很复杂的逻辑来应对变化 - 它可能很快就会难以控制，如果你储存器获得的状态了很多，你的应用程序的增长...

来源

2015-12-01 17:12:41 TomW

反应通量/还原态不应该包含计算数据 - 性能问题？

回答

相关问题