React Context与组合模式处理全局用户数据的最佳实践选择疑问

官方文档的描述不存在矛盾，只是针对两种不同场景给出了对应解法，两者不是非此即彼的互斥关系。

什么时候优先选组合模式？ #

• 消费数据的组件集中在某一个子树的末端，且中间层完全不需要用到这些数据
  比如官方举例的场景：只有最底层的Avatar和Link需要用户数据，中间的Layout、侧边栏、导航栏等组件根本不需要感知用户相关的任何属性，直接在Page层把组装好的Avatar组件通过props.children或者具名插槽传给下层即可，中间层只做透传不需要感知任何参数，这种场景完全没必要用Context，代码更简洁，组件复用性也更高。
• 你需要在同一个父组件下渲染多个不同数据的同类型子组件
  比如后台的用户列表页，每一行都要渲染对应用户的头像、个人主页链接，这种场景不可能为每一行的用户单独创建Context，直接用组合模式传组件灵活度要高得多。

什么时候优先选Context处理用户数据？ #

• 用户数据需要在组件树的多个不相关子树里被消费
  举个典型场景：顶部导航要显示当前登录用户的头像和名称，评论发布框要校验用户的发言权限，路由守卫要判断用户登录状态，个人中心页要展示用户完整信息，这些组件分散在完全不同的组件树分支里，不可能每个分支都层层透传用户数据或者对应组件，这时候Context的全局共享优势就会凸显，只需要在根组件包裹一层UserProvider，所有需要的组件直接调用useContext就能拿到数据，不需要写冗余的透传代码。
• 数据更新需要触发全局多组件同步渲染
  比如用户切换账号、退出登录，所有消费了用户数据的组件都需要同步更新状态，用Context直接修改Provider的value即可，自动通知所有消费组件更新，不需要自己额外实现事件订阅逻辑。

你认为用户场景不属于数据不明确的情况，其实Context的复用性问题体现在两个很实际的层面：

• 直接消费Context的组件必须被包裹在对应Provider的组件树内才能正常运行，脱离Provider就会报错或者拿到不符合预期的默认值。比如你写了一个<UserAvatar>组件，内部直接通过useContext(UserContext)拿全局当前用户数据，现在你要把这个组件挪到另一个没有全局用户体系的项目里复用，或者在同一个项目的评论区渲染其他用户的头像，要么得给它单独套一层对应数据的Provider，要么就得修改组件逻辑支持props传参，反而更麻烦。
• 隐式依赖导致组件逻辑不透明。只看组件的props你完全不知道它依赖了全局的用户数据，后期维护时如果修改了Context的结构，你很难快速定位到哪些组件会受影响，如果是通过props传参，组件依赖的参数一眼就能看清楚。

两种方案完全可以混用，不需要非黑即白：全局的当前登录用户数据可以用Context存储，但建议封装自定义Hooks限制消费入口，同时给消费Context的组件加一层兜底，支持props传参覆盖Context的默认值，示例代码如下：

const UserAvatar = ({ user, size = 'md' }) => {
  // props传了用户就用props的，否则用Context里的全局当前用户
  const contextUser = useContext(UserContext);
  const finalUser = user || contextUser;
  // 后续渲染逻辑
}

这种写法既享受到了Context全局共享的便利，又保留了组件的复用性，需要渲染其他用户的头像时直接传user参数即可。另外如果只是要解决props透传问题，优先尝试用组合模式解决，实在解决不了再上Context，不要上来就把所有全局数据都塞到Context里。

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