javascript - Redux（使用 React） - 调度设置加载等的请求操作会导致额外的渲染

Question

相当直截了当的问题。（我是一位老开发人员，正在构建一个需要高性能的 React 应用程序并继承了一个旧的 repo）。

我看到的大多数应用程序，在发送 API 请求时首先提交 1) 请求，然后提交 2) 成功或失败

问题是，当您分派 REQUEST 时，它会更改状态并导致任何连接的组件重新渲染。

当我试图找出为什么我的 puppeteer 测试如此糟糕时，我发现了这一点。（使用带有渲染动画/动作就绪问题等的材质 ui）

所以，

为什么在 Redux 中使用修改状态的 REQUEST 操作是正常/良好的做法？（例如清除它，设置加载：真，时间戳，等等）等。如果是这样，为什么要执行此请求操作？为什么不跳过 REQUEST 操作，只更新 SUCCESS / FAILURE 以防止重新渲染？

或者，使用非修改减速器提交请求？

显然，有一些用例可以清除 REQUEST 上的状态，但是当获取类别页面之类的内容时，更新 REQUEST 上的状态？

有什么我想念的吗？

谢谢

标签： javascriptreactjsreduxstatedispatch

Answer 1

为什么在 Redux 中使用修改状态的 REQUEST 操作是正常/良好的做法？（例如清除它，设置加载：真，时间戳，等等）等。如果是这样，为什么要执行此请求操作？为什么不跳过 REQUEST 操作，只更新 SUCCESS / FAILURE 以防止重新渲染？

一个例子：假设您有一个组件需要从 API 中获取的数据。在前端，您喜欢有一个加载条指示器。如果您知道您请求了呼叫，您将只能显示该加载栏。

想象一下，我们在没有 REQUEST/LOADING 指示符的情况下执行此操作：如果用户已经在该页面上使用调用请求的组件并再次访问，则状态 (FAILURE/SUCCESS) 将已经设置。这意味着，如果之前的状态为“FAILURE”并且您正在根据此状态渲染组件，它将首先显示您的“FAILURE”渲染。然后，它可能正在更新您的 SUCCESS 渲染。对于用户而言，这将导致从错误消息/页面闪烁到结果页面，或者反过来说确实不是好的用户体验。