Vue 组件解耦实践：用回调函数模式替代枚举类型传递
前言
在 Vue 组件开发中，父子组件通信是一个常见场景。当子组件需要触发父组件的某个操作，而父组件又需要根据触发来源执行不同逻辑时，很容易写出耦合度较高的代码。本文通过一个真实的登录模块重构案例，介绍如何使用回调函数模式来解耦组件。
问题场景
业务背景
在登录页面中，验证码登录组件有两个操作入口：
- 点击"获取验证码"按钮
- 点击"登录"按钮
两个操作都需要检查用户是否同意服务协议。如果未同意，需要弹出协议确认弹窗。用户确认后，根据触发来源执行不同的后续操作。
原有实现
// codeLogin.enum.ts - 子组件定义枚举exportconstCodeLoginEnum={CODE_BTN:'code-btn',// 获取验证码按钮LOGIN_BTN:'login-btn'// 登录按钮}asconst;// codeLogin.vue - 子组件constgetCode=()=>{if(!isAgree.value){emit('changeCodeAgreeDisplayType',CodeLoginEnum.CODE_BTN);// 告诉父组件是哪个按钮emit('toggleAgreeDialog',true);return;}// ...}// login.vue - 父组件consthandleAgreementConfirm=()=>{if(codeAgreeDisplayType.value===CodeLoginEnum.LOGIN_BTN){// 登录按钮触发的，需要校验验证码if(!verifyKey.value){ElMessage.warning('请先获取验证码');return;}}codeLoginInstance.value?.doGetCode();}问题分析
- 父组件依赖子组件内部细节：父组件需要导入并理解
CodeLoginEnum - 违反开闭原则：子组件新增按钮时，父组件也需要修改
- 职责不清：子组件的业务逻辑分散在父子两个组件中
- 可测试性差：父组件的逻辑依赖子组件的枚举定义
解决方案：回调函数模式
核心思想
子组件不告诉父组件"我是谁"，而是告诉父组件"确认后请通知我"
将"后续要执行的操作"封装为回调函数，保存在子组件内部。父组件只需要在适当时机通知子组件执行即可。
重构后的实现
// codeLogin.vue - 子组件typePendingCallback=(()=>void)|null;constpendingCallback=ref<PendingCallback>(null);constgetCode=()=>{if(!isAgree.value){// 保存回调：协议确认后执行获取验证码pendingCallback.value=()=>{executeGetCode();};emit('toggleAgreeDialog',true);return;}executeGetCode();}constcodeLogin=()=>{if(!isAgree.value){// 保存回调：协议确认后执行登录pendingCallback.value=()=>{emit('codeLogin',mobileValue.value,areaCodeValue.value,verifyCodeArg.value);};emit('toggleAgreeDialog',true);return;}emit('codeLogin',mobileValue.value,areaCodeValue.value,verifyCodeArg.value);}// 供父组件调用constonAgreementConfirmed=()=>{pendingCallback.value?.();pendingCallback.value=null;}defineExpose({onAgreementConfirmed});// login.vue - 父组件consthandleAgreementConfirm=()=>{toggleIsAgree(true);toggleAgreeDialog(false);if(isAccount()){doLoginFn(loginTempData);}else{// 简单通知子组件执行回调，无需知道具体是什么操作codeLoginInstance.value?.onAgreementConfirmed();}}数据流对比
重构前：
┌─────────┐ 发送按钮类型 ┌─────────┐ 根据类型判断 ┌─────────┐ │ 子组件 │ ─────────────→ │ 父组件 │ ─────────────→ │ 子组件 │ └─────────┘ └─────────┘ └─────────┘重构后：
┌─────────┐ 保存回调 ┌─────────┐ 通知执行 ┌─────────┐ │ 子组件 │ ─────────────→ │ 父组件 │ ─────────────→ │ 子组件 │ └─────────┘ 请求显示弹窗 └─────────┘ onConfirmed └─────────┘ (不传类型) (不传参数)方案对比
| 维度 | 枚举类型传递 | 回调函数模式 |
|---|---|---|
| 耦合度 | 高，父组件依赖子组件枚举 | 低，父组件只调用方法 |
| 扩展性 | 差，新增类型需改两处 | 好，只改子组件 |
| 职责划分 | 模糊，逻辑分散 | 清晰，子组件自治 |
| 代码量 | 需要枚举文件 | 无额外文件 |
| 可测试性 | 差，依赖外部枚举 | 好，逻辑内聚 |
适用场景
回调函数模式适用于以下场景：
- 异步确认流程：如本文的协议确认、二次确认弹窗等
- 多入口单出口：多个触发点，但后续处理由同一个组件负责
- 子组件业务自治：子组件的业务逻辑不应该泄露给父组件
注意事项
- 回调清理：执行完回调后记得置空，避免重复执行
- 错误处理：回调执行可能失败，需要考虑异常情况
- 状态同步：确保回调执行时，相关状态（如
isAgree）已更新
总结
组件解耦的核心原则是让每个组件只关心自己的职责。当发现父组件需要了解子组件的内部实现细节时，就是重构的信号。
回调函数模式是一种简单有效的解耦手段，它将"做什么"的决策权留给子组件，父组件只负责"何时做"的协调。这种控制反转的思想，在很多设计模式中都有体现，值得在日常开发中灵活运用。
