React传递根组件实例实现全局状态：是简易方案还是反模式？

这种写法的核心弊端如下： #

• 更新逻辑存在隐形缺陷
  你觉得和Context一样有全量重渲染问题，但实际坑更大：如果你的子组件使用了React.memo/PureComponent做性能优化，浅比较props时会发现传入的app根实例引用永远不变，直接跳过渲染，导致子组件拿不到最新的状态值。要是不用性能优化，根组件任何状态变更都会触发所有子组件全量重渲染，应用规模稍微大一点就会出现明显的卡顿。
• 组件耦合度极高，完全无法复用
  所有子组件都强依赖根组件的实例结构，你写的Header、Page这些组件根本没法抽离复用，哪怕是同一个项目里要复用一个小组件，也必须传入根实例，甚至你修改根组件的state字段名、方法名，所有用到对应字段的子组件都要同步修改，维护成本随项目规模指数级上升。
• 无任何封装和权限控制，调试成本极高
  等于把根组件的所有内部能力完全暴露给所有子组件，任何子组件都可以直接调用app.setState跳过你封装的funcs方法直接修改状态，出问题时你根本没法追踪状态是被哪个组件改的，React DevTools也没法清晰展示状态变更的调用链路，排查bug的成本会非常高。
• 违反React单向数据流的设计范式，生态兼容性差
  React的设计原则是只读的props自上而下传递，状态变更只能由持有状态的组件触发，你这种写法直接打破了这个规则，后续如果要接入SSR（比如Next.js）、状态管理工具、React新特性（比如Server Components）都会遇到大量兼容问题，基本没有演进空间。

关于你提到的Context重渲染问题补充 #

Context的全量重渲染是可以通过技术手段解决的：你可以拆分多个独立的Context（比如用户Context、配置Context、路由Context），也可以用useMemo拆分组件树，或者用selector类的库实现按需订阅，只有真正用到对应状态的组件才会触发重渲染，灵活度远高于你这种硬传根实例的写法。

内容的提问来源于stack exchange，提问作者Axel Productions 86