Vue 组件解耦实践：用回调函数模式替代枚举类型传递

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();}

问题分析

1. 父组件依赖子组件内部细节：父组件需要导入并理解CodeLoginEnum
2. 违反开闭原则：子组件新增按钮时，父组件也需要修改
3. 职责不清：子组件的业务逻辑分散在父子两个组件中
4. 可测试性差：父组件的逻辑依赖子组件的枚举定义

解决方案：回调函数模式

核心思想

子组件不告诉父组件"我是谁"，而是告诉父组件"确认后请通知我"

将"后续要执行的操作"封装为回调函数，保存在子组件内部。父组件只需要在适当时机通知子组件执行即可。

重构后的实现

// 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 └─────────┘ (不传类型) (不传参数)

方案对比

适用场景

回调函数模式适用于以下场景：

1. 异步确认流程：如本文的协议确认、二次确认弹窗等
2. 多入口单出口：多个触发点，但后续处理由同一个组件负责
3. 子组件业务自治：子组件的业务逻辑不应该泄露给父组件

注意事项

1. 回调清理：执行完回调后记得置空，避免重复执行
2. 错误处理：回调执行可能失败，需要考虑异常情况
3. 状态同步：确保回调执行时，相关状态（如isAgree）已更新

总结

组件解耦的核心原则是让每个组件只关心自己的职责。当发现父组件需要了解子组件的内部实现细节时，就是重构的信号。

回调函数模式是一种简单有效的解耦手段，它将"做什么"的决策权留给子组件，父组件只负责"何时做"的协调。这种控制反转的思想，在很多设计模式中都有体现，值得在日常开发中灵活运用。