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

二、组件封装的方式选择

每个组件都有其特定的属性(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****方式
封装繁琐程度	封装代码冗长 需要全面考虑到各种类型	代码简单直接 依靠可以实现任何组件
上手难易	上手简单	需要先学习配置规则
可维护性	因配置结构扁平而更容易定位一些	需要清楚地知道数据结构才能定位
配置方式	层级较少、集中且直观 但只能使用预先设计好的类型、或者更新丰富组件	层级较深、不够直观且容易形成套娃 但可设置的属性更加全面、无需在有新类型时更新组件，只要elementUI有的组件都能直接实现
扩展性	扩展性较好* 每次有新的表单控件类型，都必须预先封装、引入并注册才能使用

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

三、采取折中方式

方案一和方案二都有各自的优势和不足，所以也许将两者综合一下，设计出第三种方案。

①先单独封装好各种类型的表单控件小组件，②再通过来动态渲染，保证高度的组件复用性和扩展性，并避开v-if判断；③对配置的数据结构进行调整使其更扁平化，降低使用门槛并提高开发效率。

此时，整个组件封装的设计思路 be like:

用文字描述上图所示的方案：

①在表单Form 上通过来动态渲染不同类型的表单控件小组件，

②对各种类型的控件进行独立封装、分开管理，并导入和注册

③根据需要，在各个小组件中添加一些自定义属性、样式和其他定制化功能等

优势

▷ 高复用性：通过单独封装各种类型的表单控件小组件，实现了高度的组件复用

▷ 灵活性：通过封装各种表单控件小组件，可以确保每个组件都具备较高的可重用性和可扩展性。同时，使用可以根据配置动态渲染不同的组件，提供了更大的灵活性

▷ 易于维护：每一种特定的表单控件都有独立的封装组件，易于进行单独的维护和测试。每个表单控件都有明确的封装边界(内部实现细节被隐藏起来，只暴露必要的接口供外部使用)，这有助于保持代码的模块化和可维护性

▷ 良好的扩展性：添加新的控件类型时，只需要创建新的封装组件并注册到组件库中即可

▷ 数据结构扁平化：通过调整数据结构，使得配置更加扁平、简洁直观和易于管理，更容易理解和操作，降低了使用门槛

潜在问题

▷ 初期投入大：需要投入较多的时间和精力来单独封装各种类型的表单控件小组件

基础学习：

前端最基础的就是 HTML , CSS 和 JavaScript 。

网页设计：HTML和CSS基础知识的学习

HTML是网页内容的载体。内容就是网页制作者放在页面上想要让用户浏览的信息，可以包含文字、图片、视频等。

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

CSS样式是表现。就像网页的外衣。比如，标题字体、颜色变化，或为标题加入背景图片、边框等。所有这些用来改变内容外观的东西称之为表现。

动态交互：JavaScript基础的学习

JavaScript是用来实现网页上的特效效果。如：鼠标滑过弹出下拉菜单。或鼠标滑过表格的背景颜色改变。还有焦点新闻（新闻图片）的轮换。可以这么理解，有动画的，有交互的一般都是用JavaScript来实现的。

lOEU-1714376527902)]

动态交互：JavaScript基础的学习

JavaScript是用来实现网页上的特效效果。如：鼠标滑过弹出下拉菜单。或鼠标滑过表格的背景颜色改变。还有焦点新闻（新闻图片）的轮换。可以这么理解，有动画的，有交互的一般都是用JavaScript来实现的。