React useSelector选全量Store与单个值的效率问题及方案选型

这个方案确实存在明显的性能问题，损耗来自两个核心环节：

• 顶层通过const formStore = useSelector(state => state.formStore)直接订阅了整个formStore节点，只要这个节点下任意一个字段更新（哪怕是没有任何组件使用的临时字段变更），GrandparentComponent会首先触发重渲染。
• 把整个formStore对象作为Context的value向下传递时，React Context的默认更新逻辑是：只要value的引用发生变化，所有消费该Context的后代组件都会强制重渲染，完全不会判断组件实际用到了哪个字段。
  在30个字段的表单场景下，用户输入会高频触发字段更新，这套逻辑会导致Grandparent、Parent、ReusableChildFormComponent三层跟着每次输入全量重渲染，如果表单包含复杂联动校验、重型自定义表单项，很容易出现输入卡顿。

两者没有绝对的优劣，完全取决于Prop Drilling的实际写法：

• 如果写Prop Drilling时，每层组件只向下传递自身和直接子组件真正需要的字段，没有全量透传整个store对象，性能会比全量Context方案好很多——只有依赖变更字段的组件会重渲染，中间层不会因为无关字段更新被强制刷新。但这种写法维护成本极高，新增一个字段要顺着组件层级改好几层传参，中间层组件平白接收一堆自己不用的props，后续重构很容易出漏子。
• 如果写Prop Drilling时图省事，每层拿到全量formStore就原封不动往下透传，那性能和全量Context方案几乎没有区别，还多了一堆冗余的传参代码，开发体验反而不如Context方案。

推荐几个落地成本低、兼顾性能和开发体验的方案，按优先级排序：

• 各组件直接独立调用useSelector取数：这是Redux设计的原生用法，完全不需要额外套一层Context做中转。Grandparent组件只选自己要用的少数字段，Parent选自己负责的部分字段，ReusableChildFormComponent选自己依赖的字段即可。每个组件的useSelector只会订阅自己用到的状态，字段更新时只有真正依赖它的组件会重渲染，既没有prop drilling的冗余传参，性能表现也最好。

  注意事项：如果一个组件需要取多个字段，不要在useSelector里返回新组装的对象（比如useSelector(state => ({a: state.form.a, b: state.form.b}))），这种写法每次都会返回新引用导致组件无效重渲。可以拆成多个useSelector拿单个基础类型值，或者给useSelector传入shallowEqual作为第二个参数做浅比较，也可以用Redux Toolkit的createSelector创建记忆化选择器。

• 可复用组件拆分容器层：如果担心ReusableChildFormComponent直接依赖Redux会影响组件复用性，就单独写一层连接Redux的容器组件：容器组件内部用useSelector取全量需要的字段，再把字段作为props传给纯展示逻辑的ReusableChildFormComponent。纯组件本身不依赖任何Redux逻辑，脱离Store环境也能直接传props复用，接Redux的场景直接用容器组件即可，没有额外耦合。
• 如果你确实偏好Context的开发体验，不要传整个store对象，按字段的更新频率、使用范围拆分多个独立Context，比如把用户输入时高频变更的表单值放一个Context，表单配置、校验规则这类低频更新的内容放另一个Context，组件按需消费对应的Context，能大幅减少无效重渲染的范围。

如果你的表单本身是强联动场景，改任意字段都需要全表单重算、重渲染，那你一开始设想的全量Context方案完全可以用，毕竟怎么写都逃不开全量重渲，选开发效率最高的写法就行。

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