我应该在 redux 存储中存储高吞吐量、结构化的传感器数据吗？

Question

我最近开始使用 React，到目前为止我已经构建了几个应用程序，包括一个用于操作和可视化传感器数据的实时应用程序。这些数据包含来自 websocket 的 100Hz-200Hz 的高吞吐量、结构化 JSON 帧。

随着我的应用程序的复杂性迅速增长，在通过官方文档和 Dan Abramov 的课程了解 Redux 之后，我发现使用 Redux 来管理应用程序的可视化状态、路由、服务器信息等非常有吸引力。

在我的 React-non-Redux 应用程序中，所有内容都保存在本地状态，但这在架构设计中是有代价的。现在，我想开始重构应用程序以集成 redux。由于我目前的知识有限，我被困在关于在哪里存储传感器流数据以及对应用程序渲染和处理性能的影响的架构决策。

在 redux 文档中，有用于确定应将哪种数据放入 Redux 的经验法则：

• 应用程序的其他部分是否关心这些数据？ [是]
• 您是否需要能够基于此创建进一步的派生数据 原始数据？ [是]
• 是否使用相同的数据来驱动多个组件？ [是]
• 能够将此状态恢复到给定状态是否对您有价值 时间点（即时间旅行调试）？ [是]
• 您是否要缓存数据（即，使用状态中的内容，如果它是 已经在那里而不是重新请求它）？ [可能]

已经有几个线程在讨论这个问题，但没有任何明确的答案。我也无法对此发表评论（这里是菜鸟）：

• Should I be concerned with the rate of state change in my React Redux app?

• Visualizing ImmutableJS data from Redux store in a graph

我发现了许多我需要学习的不同分支，包括中间件、RxJS 等。我想进一步推动开发，但由于所有这些都需要时间来掌握，我想参考社区一些方向。

提前致谢！

Answer 1

我目前正在使用 redux 为小部件提供数据，我会说传入速率在 80-90 赫兹左右，我仍然在小部件画布上获得 60 fps。就像 Dan 在他的帖子中所说的那样，使用 redux 并没有天生的慢。但是每秒更新你的 UI 200 次是完全没有必要的，我至少会添加一些中间件（如果你不想拥有服务器）到 redux 以将更新聚合到每秒最多 60 次。 Redux 可能不会那么慢，但尝试每秒渲染 200 次肯定会。

不过，我要说的是，我最近不得不做出与您相同的决定，将数据流保存在 redux 中使得在我的应用程序中访问它们变得更加简单。

我发现使用网络工作者是将数据合并到单个更新中的好方法。如果您还没有，我会查看https://developer.mozilla.org/en-US/docs/Web/API/Worker。如果您决定朝那个方向发展，那么它可能会对性能有很大帮助，因为工作人员将直接处理 websocket 连接，并以更可控的方式将动作分派到 redux。