在React函数式组件中应用OOP模式的可行性探讨

一、避免紧耦合、支持逻辑覆盖的通用方案 #

针对你提到的「不想修改公共组件却允许外部自定义逻辑」的需求，业界常用的方案有以下几种：

1. Props 传递回调（最基础直接） #

将需要自定义的逻辑通过组件props暴露出去，公共组件内部保留默认逻辑，当外部传入自定义回调时优先使用。比如保存按钮的逻辑：

// 公共组件
const SaveButton = ({ onSave = defaultSaveLogic }) => {
  return <button onClick={onSave}>保存</button>;
};

// 默认逻辑
const defaultSaveLogic = () => {
  // 验证→显示错误→处理保存的默认流程
};

其他开发者使用时，直接传入自己的onSave即可覆盖默认逻辑，完全不需要修改公共组件代码。

2. 自定义 Hook（函数式组件首选） #

把组件的通用逻辑抽离成自定义Hook，用户可以直接调用Hook获取默认逻辑，也可以基于Hook扩展或重写部分方法。这种方式完全贴合React函数式生态，灵活度极高。

比如把数据请求逻辑做成Hook，用户可以轻松替换fetchData：

// 基础Hook
const useDataFetcher = () => {
  const [state, setState] = useState({ data: null, loading: false, error: null });
  const urlRef = useRef("");

  const setUrl = (newUrl) => urlRef.current = newUrl;

  const fetchData = useCallback(() => {
    if (!urlRef.current) return;
    setState(prev => ({ ...prev, loading: true }));
    fetch(urlRef.current)
      .then(res => res.json())
      .then(data => setState(prev => ({ ...prev, data, loading: false })))
      .catch(err => setState(prev => ({ ...prev, error: err, loading: false })));
  }, []);

  return { state, setUrl, fetchData };
};

// 用户自定义扩展
const useCustomDataFetcher = () => {
  const base = useDataFetcher();
  const customFetch = useCallback(() => {
    // 加入自定义验证逻辑
    if (!base.state.data) {
      console.log("数据为空，不发起请求");
      return;
    }
    base.fetchData();
  }, [base]);

  return { ...base, fetchData: customFetch };
};

3. 组件组合（Composition） #

将公共组件拆分成更小的原子组件，允许外部替换内部的功能模块。比如把「保存按钮」作为插槽传入公共组件：

// 公共表单组件
const Form = ({ saveButton = <DefaultSaveButton /> }) => {
  return (
    <form>
      {/* 表单内容 */}
      {saveButton}
    </form>
  );
};

// 其他开发者使用时传入自定义按钮
<Form saveButton={<button onClick={customSave}>自定义保存</button>} />

4. 高阶组件（HOC，传统方案） #

把通用逻辑封装成高阶组件，通过包裹目标组件注入默认逻辑，需要自定义时可以扩展HOC或嵌套多个HOC。不过现在HOC已逐渐被自定义Hook替代，除非有兼容旧代码的需求，否则不优先推荐。

二、你的「智能/哑组件+类实例」方案是否有效？ #

你的方案是可行的，本质上是用面向对象的方式实现了逻辑与视图的分离，优点很明显：

• 关注点清晰：哑组件只负责渲染，所有业务逻辑都集中在ComponentState类中
• 扩展性强：其他开发者可以通过继承ComponentState重写方法（比如fetchData），实现逻辑覆盖
• 对OOP背景的开发者友好，学习成本低

但在React函数式组件的生态下，这个方案也存在一些可以优化的点：

1. 与React原生机制脱节：你手动实现了订阅/通知的状态更新机制，还需要用forceUpdate触发重渲染，而React的useState、useReducer已经内置了这些能力，手动实现会增加不必要的复杂度，也容易引入内存泄漏风险（虽然你的代码里做了取消订阅，但仍需额外维护）。
2. 函数式理念契合度低：React函数式组件更推崇用「纯函数+Hook」的方式管理状态和副作用，类的写法显得格格不入，也不利于利用React的内置优化（比如Hook的依赖追踪）。

优化建议：将类逻辑转为自定义Hook #

把你的ComponentState类改写成自定义Hook，既保留原有的逻辑复用能力，又贴合React函数式生态：

// 替代ComponentState类的自定义Hook
const useComponentState = () => {
  const [state, setState] = useState({
    data: null,
    loading: false,
    error: null,
  });
  const urlRef = useRef("");

  const setUrl = (newUrl) => {
    urlRef.current = newUrl;
  };

  const fetchData = useCallback(() => {
    if (!urlRef.current) return;
    setState(prev => ({ ...prev, loading: true }));
    fetch(urlRef.current)
      .then(response => response.json())
      .then(data => setState(prev => ({ ...prev, data, loading: false })))
      .catch(error => setState(prev => ({ ...prev, error, loading: false })));
  }, []);

  return { state, setUrl, fetchData };
};

对应的智能组件可以简化成：

const SmartComponent = () => {
  const { state, setUrl, fetchData } = useComponentState();

  useEffect(() => {
    setUrl("https://jsonplaceholder.typicode.com/todos/1");
  }, []);

  return <MyComponent componentState={state} fetchData={fetchData} />;
};

这样既不需要手动管理订阅和forceUpdate，也能轻松实现逻辑覆盖——用户只需要基于useComponentState封装自己的Hook即可，完全不需要修改原组件代码。

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