Vue项目采用smart/dumb模式 仅单页使用的UI组件是否需要单独封装

仅在单个页面调用的组件（如登录页专属的login-form）是否需要单独封装？ #

非常有必要，哪怕该组件只会在一处调用，拆分逻辑依然有明确收益：

• 组件拆分的核心价值不只是复用，更是逻辑解耦、降低单文件代码复杂度。将登录表单专属的校验规则、提交状态管理、错误提示逻辑全部收拢在login-form内部，父级登录页只需要处理登录成功后的跳转、权限更新等上层逻辑，代码可读性会高很多。
• 后续维护迭代时，所有登录表单相关的修改都可以直接定位到该组件，不需要在登录页的大量业务代码中筛选逻辑，排查问题、调整需求的效率会高很多。
• 这类单页专用的组件也可以按dumb组件的标准开发，只通过props接收加载状态、提交回调等外部参数，内部不耦合当前项目的业务接口逻辑，后续如果有其他同类型的登录场景，可以直接复用样式、校验逻辑，改造成本极低。

什么场景下需要创建smart components？ #

smart components的核心定位是业务逻辑容器，本身不做具体的UI渲染，只负责处理和当前项目强绑定的业务逻辑、数据流转。符合以下任意场景都可以创建smart组件：

• 需要发起业务接口请求，并且要将请求返回的数据传递给下层组件做渲染时，接口请求、异常处理逻辑可以全部收拢在smart组件中，下层dumb组件只需要接收props渲染，不需要感知数据的来源。
• 组件逻辑需要和全局状态（Pinia/Vuex存储的用户信息、权限配置、全局配置项等）交互时，将全局状态的读写逻辑放在smart组件处理，下层dumb组件完全不需要感知全局状态的存在，复用性更强。
• 某块业务逻辑高度内聚，比如商品列表的筛选、排序、分页逻辑完全绑定，就可以将这部分逻辑封装为smart组件，内部处理参数拼接、接口请求，只把最终需要渲染的列表数据传递给下层的通用列表dumb组件即可。
• 需要给下层UI组件提供大量业务相关的事件回调时，将回调的具体实现放在smart组件中，只把绑定好的方法传递给下层组件，避免父页面堆积大量冗余的业务逻辑。

你可以用一个简单的规则判断组件类型：把当前组件复制到另一个同技术栈的项目中，如果不需要修改就能直接用，就是dumb组件；如果因为依赖当前项目的接口、全局状态无法直接运行，就是smart组件。

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