Redux与顶层组件通过Props共享状态的方案对比及实践疑问

1. 子组件发起请求后通过回调存顶层state的做法是否属于不良实践？ #

对于你这种100人级别的小型应用，不算严格意义上的不良实践，能满足基本需求且实现成本低。但它有几个潜在问题需要注意：

• 组件耦合：子组件和顶层组件绑定过死，换场景复用子组件时，得重新处理回调逻辑
• 请求逻辑分散：如果多个子组件都有类似请求，代码重复率会很高，后期维护成本上升

如果要优化，建议把API请求逻辑抽离出来：比如写个自定义useFetchData Hook，或者单独的API服务函数，让组件只负责触发请求和处理结果，请求逻辑统一管理。

2. 状态/Props应存储的内容 #

状态（State） #

• 只存应用运行必需的、会变化的核心数据：比如用户登录信息、已加载的业务列表、用户操作偏好（如主题设置）
• 不要存衍生数据：比如从现有state计算出来的过滤列表，应该用useMemo实时计算，而非存在state里
• 不要存冗余数据：比如API请求的URL这类固定值，或者可通过props直接获取的内容，没必要放进state

Props #

• 只传组件直接需要用到的数据或回调：比如子组件只需要展示用户名称，就别把整个用户对象传过去，只传userName即可
• 避免传递冗余数据：减少不必要的组件重渲染，同时降低组件间的耦合度

3. API调用频率的通用原则 #

• 按需触发：只在组件即将渲染、用户触发操作（如点击、输入）时发起请求，不要提前加载用不上的数据
• 防抖/节流：针对用户输入类触发场景（如搜索框输入），用防抖（debounce）减少短时间内的重复请求；针对滚动加载这类场景，用节流（throttle）控制请求频率
• 缓存复用：对请求结果做缓存，只要数据没过期、没变化，直接用缓存无需重新请求。比如可以在顶层state里记录数据更新时间，或者用React Query、SWR这类工具自动处理缓存
• 批量合并：如果多个小请求可以合并成一个接口调用，尽量合并，减少HTTP请求开销

4. 不同组件重复调用同一API是否属于常见做法？ #

这不是推荐的常见做法，除非你的数据是实时性要求极高的场景（如实时监控数据）。重复调用会带来这些问题：

• 浪费服务器带宽和资源
• 可能导致不同组件拿到的数据不一致
• 增加用户端的等待时间

更合理的做法是：

• 把请求后的数据提升到公共父组件，通过props传递给需要的子组件
• 用React Context API做轻量状态共享，不用Redux也能实现跨组件数据复用
• 用缓存工具让多个组件共享同一份请求结果

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