我应该关心 React Redux 应用程序中的状态变化率吗? [英] Should I be concerned with the rate of state change in my React Redux app?

问题描述

我正在使用 React、Redux 和 Websocket 实现/评估实时"网络应用程序.在服务器上，我的数据集发生变化的速度约为每秒 32 次.

I am implementing/evaluating a "real-time" web app using React, Redux, and Websocket. On the server, I have changes occurring to my data set at a rate of about 32 changes per second.

每次更改都会使用 Websocket 向应用程序发送异步消息.异步消息在我的 redux 状态下启动 RECEIVE 操作.状态更改会导致组件呈现.

Each change causes an async message to the app using Websocket. The async message initiates a RECEIVE action in my redux state. State changes lead to component rendering.

我担心状态更改的频率会导致客户端承受不可接受的负载，但我不确定如何根据消息数量、组件数量等来表征负载.

My concern is that the frequency of state changes will lead to unacceptable load on the client, but I'm not sure how to characterize load against number of messages, number of components, etc.

这什么时候会成为问题，或者我会使用什么工具来确定它是否有问题?

When will this become a problem or what tools would I use to figure out if it is a problem?

我的状态的形状"对渲染性能有影响吗?我应该考虑将高变化对象放在一个实体中，而将低变化对象放在另一个实体中吗?

Does the "shape" of my state make a difference to the rendering performance? Should I consider placing high change objects in one entity while low change objects are in another entity?

我是否应该将精力集中在批量更改事件上，以便应用可以响应更改列表而不是每个单独的更改(有效降低状态更改率)?

Should I focus my efforts on batching the change events so that the app can respond to a list of changes rather than each individual change (effectively reducing the rate of change on state)?

我感谢任何建议.

推荐答案

这些实际上是非常合理的问题，是的，这些听起来都是值得研究的好方法.

Those are actually pretty reasonable questions to be asking, and yes, those do all sound like good approaches to be looking at.

作为一个想法 - 您说您的服务器端数据更改每秒发生 32 次.该信息本身可以批量处理吗?你真的需要显示每一个更新吗?

As a thought - you said your server-side data changes are occurring 32 times a second. Can that information itself be batched at all? Do you literally need to display every single update?

您可能对 Redux 常见问题的性能"部分感兴趣，其中包括关于 "缩放" 和减少商店订阅数量更新.

You may be interested in the "Performance" section of the Redux FAQ, which includes answers on "scaling" and reducing the number of store subscription updates.

根据更新频率对状态进行部分分组听起来是个好主意.未订阅该块的组件应该能够根据 React Redux 的内置浅层相等性检查跳过更新.

Grouping your state partially based on update frequency sounds like a good idea. Components that aren't subscribed to that chunk should be able to skip updates based on React Redux's built-in shallow equality checks.

我将添加几个额外的有用链接，以获得与性能相关的信息和库.我的 React/Redux 链接存储库有一个关于 React 性能，我的 Redux 库链接 repo 有关于 存储更改订阅 和 组件更新监控.

I'll toss in several additional useful links for performance-related information and libraries. My React/Redux links repo has a section on React performance, and my Redux library links repo has relevant sections on store change subscriptions and component update monitoring.

这篇关于我应该关心 React Redux 应用程序中的状态变化率吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！