React/Redux应用中后台取数时条件分发Action的正确方式

你的这种实现思路本身是可行的，但确实有可以优化的空间，也可以考虑另一种组件内控制的方案，咱们来具体拆解一下：

当前方案的合理性与潜在问题 #

合理之处 #

• 把「是否展示加载UI」的逻辑封装在action creator中，让组件可以更专注于UI渲染，不用额外处理状态判断逻辑
• 通过shouldFetchInBackground参数控制action分发，能减少不必要的store更新，尤其是后台取数这类不需要触发UI变化的场景，避免了无意义的组件重渲染

需要注意的潜在问题 #

1. 错误状态处理不完整：当前代码中，后台取数失败时不会分发FETCH_POSTS_FAILURE，这会导致无法在store中记录后台请求的失败状态，如果后续需要监控后台请求的健康状况，就没有数据支撑了
2. action creator逻辑复杂化：如果后续新增更多类似的UI控制参数（比如是否展示成功提示），action creator里的条件判断会越来越多，违背单一职责原则
3. 状态一致性风险：虽然当前代码中后台取数不会触发isFetching的变更，但如果后续逻辑调整，比如后台取数前不小心触发了FETCH_POSTS，失败时又没重置isFetching，就会导致加载态一直挂着

组件内控制加载态的方案分析 #

另一种思路是让action creator分发所有action，转而在组件内部用自身状态控制加载动画的显示，这种方案的优缺点如下：

优点 #

• action creator更纯粹：只负责数据请求和同步store状态，不用关心UI层的展示逻辑，后续维护成本更低
• 组件灵活性更高：每个组件可以根据自身需求决定是否显示加载态，甚至可以自定义加载动画的样式和时机，比如有的组件可能需要延迟显示加载态避免闪烁

缺点 #

• 组件状态冗余：每个需要控制加载态的组件都要维护额外的状态（比如showLoading），如果多个组件有类似需求，会产生重复代码
• 全局控制不便：如果需要全局统一控制加载态（比如顶部全局加载条），这种组件内控制的方式就不太容易实现

优化建议 #

针对当前方案的优化 #

如果你的后台取数场景不多，且当前方案已经能满足需求，可以做以下优化：

• 给参数改个更语义化的名字，比如skipLoadingUI，比shouldFetchInBackground更直观
• 后台取数失败时，分发一个专门的FETCH_POSTS_BACKGROUND_FAILURE action，既不影响UI，又能在store中记录后台请求状态，方便后续排查问题
• 用Immer简化reducer的写法，避免繁琐的Object.assign：

  import produce from 'immer';
  
  const posts = produce((state, action) => {
    switch(action.type) {
      case FETCH_POSTS:
        state.isFetching = true;
        break;
      case FETCH_POSTS_SUCCESS:
      case FETCH_POSTS_FAILURE:
      case FETCH_POSTS_BACKGROUND_FAILURE:
        state.isFetching = false;
        break;
      default:
        break;
    }
  }, { isFetching: false });
  

考虑组件内控制的场景 #

如果你的应用中有大量类似的UI控制需求，或者希望action creator更专注于数据逻辑，可以切换到组件内控制：

1. 修改action creator，去掉条件判断，始终分发完整的action：

   const fetchPosts = () => dispatch => {
     dispatch({ type: FETCH_POSTS });
     fetchUserPosts()
       .then(() => dispatch({ type: FETCH_POSTS_SUCCESS }))
       .catch(() => dispatch({ type: FETCH_POSTS_FAILURE }));
   }
   

2. 组件内部维护showLoading状态，调用fetchPosts时根据场景设置：

   const [showLoading, setShowLoading] = useState(false);
   
   const handleFetch = (isBackground) => {
     !isBackground && setShowLoading(true);
     dispatch(fetchPosts()).finally(() => {
       !isBackground && setShowLoading(false);
     });
   }
   

3. 渲染时结合store的isFetching和组件的showLoading控制动画：

   {showLoading && isFetching && <LoadingSpinner />}
   

总结 #

没有绝对正确的方案，核心是看你的应用规模和需求：

• 小型应用或场景单一的话，当前方案足够简单高效
• 大型应用或有大量UI控制需求的话，建议让action creator专注数据逻辑，把UI控制交给组件或专门的UI状态管理层

内容的提问来源于stack exchange，提问作者vs1682