公平直截了当的问题。 （我是一个老开发人员，正在构建需要高性能的React应用程序，并且继承了旧的回购协议。）
我看到的大多数应用程序在分发API请求时首先提交1）请求，然后提交2）成功或失败
问题是，当您调度REQUEST时，它会更改状态并使所有连接的组件重新呈现。
当我试图找出为什么木偶测试如此出色时，我发现了这一点。 （将材质ui与渲染动画/动作就绪问题等配合使用）
所以
为什么在Redux中使用修改状态的REQUEST动作是正常/良好做法？ （例如清除它，设置loading：true，时间戳等）等。如果是这样，为什么要执行此REQUEST动作？为什么不跳过REQUEST操作，而仅对SUCCESS / FAILURE进行更新以防止重新渲染？
或者，使用非修饰的reducer提交请求？
很明显，有一些用例可以清除REQUEST上的状态，但是在获取诸如类别页面之类的内容时，是否要更新REQUEST上的状态？
有什么我想念的吗？
谢谢
答案 0 :(得分：0)
为什么在Redux中使用修改状态的REQUEST动作是正常/良好做法？ （例如清除它，设置loading：true，时间戳等）等。如果是这样，为什么要执行此REQUEST动作？为什么不跳过REQUEST操作，而仅对SUCCESS / FAILURE进行更新以防止重新渲染？
一个例子： 假设您有一个组件，该组件需要从API提取数据。在前端，您希望有一个加载栏指示器。如果您知道请求了呼叫，则只能显示该加载栏。
想象一下我们没有REQUEST / LOADING指示符的情况： 如果用户已经在该页面上并且组件正在调用请求并再次出现，则状态（FAILURE / SUCCESS）将会已经设置。这意味着，如果以前的状态为“ FAILURE”，而您正在根据此状态渲染组件，则它将首先显示“ FAILURE”渲染。然后，可能会随着您的SUCCESS渲染进行更新。对于用户而言，这将导致从错误消息/页面到结果页面的闪烁，或者相反，这实际上是没有好的用户体验的结果。