React中使用两个各持独立状态的类组件是否属于不良开发实践？

先纠正你的几个核心认知错误 #

• 你完全搞混了React组件的「组合包含关系」和面向对象的「类继承关系」：你提到的“商品模块子组件继承自Product类、setState沿继承链访问父类state”是完全错误的理解。React的父子组件是嵌套渲染的包含关系，不存在类继承关联，每个类组件的state都属于当前组件实例本身，调用setState只会修改当前组件自己的state，和父组件、子组件的state都完全独立，不会互相干扰。
• React官方明确推荐「组合优于继承」，不要自定义业务基类让组件继承，所有类组件正常继承React.Component即可，公共逻辑抽成独立工具函数复用就够了。

核心疑问解答 #

你当前场景下用两个持有独立状态的类组件完全是合理的，不属于不良实践，理由如下：

• 你自己也提到两个模块没有需要共享的数据，状态拆分到独立的控制器组件符合「单一职责」原则，每个组件只管理和自己业务相关的状态，比把所有状态堆在一个顶层大组件里更易维护，也不会出现修改商品状态意外影响日程模块的问题。
• 如果强行把所有状态都放到顶层组件，反而会引入额外问题：一是顶层状态会越来越臃肿，后续迭代很难维护；二是每次修改任意模块的状态，整个应用的所有组件都会触发不必要的重渲染，性能更差。
• 也完全不需要把日程模块调整为Product Controller的子组件，两个平级的控制器组件直接放在最顶层的App容器下渲染即可，App甚至可以做成无状态的函数组件，不需要持有任何状态。

额外优化建议（符合你练习原生React的需求） #

你为了避免prop drilling把所有商品相关组件都做成Product Controller的直接子组件，这个做法其实会让控制器组件的渲染逻辑非常冗余，原生React本身就提供了Context API解决跨层级传参问题，不需要引入任何第三方库，完全符合你练习原生能力的需求，可以直接用它来传递商品相关的状态和操作方法，不需要把所有子组件都写成直接子级。

内容的提问来源于stack exchange，提问作者Drew Peterson 7671