Redux、本地状态、React Query实现用户组件的方案对比及选型咨询

• 状态滥用：大量仅单页面使用的非共享数据存入全局store，会导致全局状态树越来越臃肿，后续维护时定位状态归属、排查状态变更问题的成本会指数级上升，且无意义的全局状态订阅还会带来额外的重渲染性能开销。
• 模板代码冗余：为了实现简单的接口请求，需要额外编写action、reducer、异步thunk逻辑，相比其他方案多出近一倍的模板代码，增加了不必要的开发成本。
• 原生能力缺失：原生Redux没有内置接口缓存、重复请求去重、失败重试、后台刷新这些常用能力，要实现同类需求需要自己额外手写逻辑，开发效率低。

方案1：Redux #

仅适合明确需要用户列表、用户资源数据在多组件/多页面跨路由共享的场景，如果没有确定的跨组件共享需求，完全没必要硬套Redux开发模式。

方案2：本地状态 #

适合极小的、确定后续不会扩展的独立组件，优势是无额外依赖、逻辑直观。但请求相关的loading、错误处理、缓存都需要手动实现，业务规模上来之后重复代码会非常多，维护成本高。

方案3：抽离逻辑后的React Query版本 #

优先推荐该方案，优势非常突出：

• 自动处理请求的loading、错误状态，不需要手动维护大量请求相关的状态变量
• 内置缓存、请求去重、后台刷新能力，后续如果其他组件需要用到用户列表数据，直接复用同一个query key就能拿到缓存结果，不需要额外做状态同步
• 接口请求逻辑已经抽离到独立文件，组件内部仅保留最基础的交互逻辑，职责拆分清晰，后续维护、扩展都非常方便
• 既规避了Redux全局状态臃肿的问题，也解决了纯本地状态请求逻辑重复、耦合度高的问题，是当前这类数据展示类场景的最优解。

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