Vue组件封装方案对比——v-if方式与内置component方式

近期在准备搭建一个通用组件库，而公司现有的各个系统也已有自己的组件库只是没抽离出来，但是目前有两套不同的组件封装方案，所以对于方案的选择比较困惑，于是对两种方式进行了对比，结合网上找到的一些开源组件库进行分析。记录一下子叭！~

一、现有系统的组件设计思路

目前，A系统和B系统两个项目中各自有设计自己的组件库，但由于底层封装方案不同，使用时的配置信息也有一些差别，可以通过比较常见的表格、表单组件作为例子直观感受一下。

二、组件封装的方式选择

每个组件都有其特定的属性(props)、插槽(slots)和事件(events)，这些构成了组件的 API。

props	子组件接收的参数，最好用对象的写法，这样可以针对每个属性设置类型、默认值或自定义校验属性的值，还可通过type、validator、required等方式对输入进行验证
slot	可以给子组件的特定位置动态插入一些内容或组件(模板)
event	子组件可以通知父组件其内部状态的变化或用户的交互行为，使得父组件可以据此更新状态或执行其他操作(子组件在特定的情况下触发事件，父组件监听这些事件并作出响应)

组件封装的方式选择

第一种，先设置好各种类型的组件，使用v-if逐个判断渲染（例子：A系统）

<el-form-item>
    <el-input v-if="item.type == $const.FormCompType.input" />
    <el-input-number v-if="item.type == $const.FormCompType.number" />
    <slot v-if="item.type == $const.FormCompType.slot" :item="item" :name="item.slotName" />
</el-form-item>

第二种，利用vue内置的component组件，直接传入Element UI组件（例子：B系统）

<el-form-item>
  <component :is="item.type" />
</el-form-item>

组件封装在实现表单动态渲染、实现表单可视化配置这方面的应用会比较丰富和直观一些，正好以上A系统中就采用了v-if方法，而B系统则采用了内置component的方法。

下面，笔者将通过一个表格，从多个角度分析展示两种方案的区别。

	v-if方式	component方式
封装繁琐程度	封装代码冗长需要全面考虑到各种类型	代码简单直接依靠<component :is="">可以实现任何组件
上手难易	上手简单	需要先学习配置规则
可维护性	因配置结构扁平而更容易定位一些	需要清楚地知道数据结构才能定位
配置方式	层级较少、集中且直观但只能使用预先设计好的类型、或者更新丰富组件	层级较深、不够直观且容易形成套娃但可设置的属性更加全面、无需在有新类型时更新组件，只要elementUI有的组件都能直接实现
扩展性	扩展性较好每次有新的表单控件类型，都必须预先封装、引入并注册才能使用添加或功能时，只需要在已有的框架内进行扩展，增加相应的判断逻辑和组件即可，不需要修改其他部分的代码	扩展性有限当需要添加新的表单控件类型或功能时，可能需要修改多处代码，或依赖于ElementUI的更新对于复杂的表单控件或自定义功能，可能需要重新编写大量代码，难以在现有基础上进行扩展
优势	抽象和重用：提供抽象层，代码更清晰可维护，同时提高了组件的重用性自定义和扩展性：通过type属性可方便地扩展新的控件类型，添加自定义逻辑和样式以满足项目的特定需求易于管理和维护：方便地调整界面结构和行为，需要修改表单控件时，只需修改相应组件，无需在多个地方更改和修改底层的UI组件库组件	灵活性：能够直接利用Element UI提供的丰富组件和特性，无需额外封装，开发效率高减少封装成本：无需投入时间和资源去封装每个表单控件和处理所有可能的边界情况与库保持同步：UI组件库通常会持续更新和修复问题，直接使用库中的组件可以确保应用始终获得最新的功能和修复，降低了维护成本快速集成：直接利用现有的 ElementUI 组件，可以快速集成到项目中，减少开发时间
劣势	封装成本高：需要投入时间和资源去封装每个表单控件，并确保它们能够正确响应传入的配置性能损失：可能会导致不必要的渲染和销毁，可能导致一定的性能损失，尤其是在渲染大型表单时。但是这种损失通常是可接受的，可得到优化的维护性挑战：随着控件类型、数量和复杂度的增加，组件内部逻辑可能会变得复杂，维护起来较为困难代码冗余：使用 v-if 进行条件渲染可能会导致代码冗余，尤其是在控件类型较多时	配置复杂性：对于复杂的表单或界面，直接传入Element UI组件可能需要更复杂的配置和属性管理，增加了开发的复杂性缺乏抽象层：代码更依赖于特定的库实现，缺乏抽象层，代码结构可能不够清晰和易于维护更难以定制：封装组件可根据需要添加额外的逻辑或样式来定制组件的行为或外观。对于需要高度定制化的表单控件，直接使用库中的组件可能不够灵活复用性差：每个表单控件都直接使用ElementUI组件，无法对它们进行统一的封装和扩展维护成本高：随着组件类型的增加，代码变得难以维护，特别是当需要调整表单控件的样式或行为时，可能需要修改多个地方，维护较为繁琐
其它	上传文件场景下配置依然简洁可给各组件添加自定义事件多个表单控件统一样式时，在封装层统一处理就好可在组件中设计好通用的校验规则	上传文件场景下配置较麻烦应该如何给el-xxx添加这些事件呢？多个表单控件统一样式时，需要在JSON配置项里面重复写校验规则需要在每次使用的时候就写一遍