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

最新推荐文章于 2024-10-10 17:09:29 发布

2401_84616838

最新推荐文章于 2024-10-10 17:09:29 发布

阅读量422

点赞数 5

分类专栏：程序员文章标签：前端面试学习

本文链接：https://blog.csdn.net/2401_84616838/article/details/138959101

版权

程序员专栏收录该内容

106 篇文章 0 订阅

订阅专栏

最后

开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
就答题情况而言，第一问100%都可以回答正确，第二问大概只有50%正确率，第三问能回答正确的就不多了，第四问再正确就非常非常少了。其实此题并没有太多刁钻匪夷所思的用法，都是一些可能会遇到的场景，而大多数人但凡有1年到2年的工作经验都应该完全正确才对。
只能说有一些人太急躁太轻视了，希望大家通过此文了解js一些特性。

并祝愿大家在新的一年找工作面试中胆大心细，发挥出最好的水平，找到一份理想的工作。


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配置项里面重复写
校验规则需要在每次使用的时候就写一遍
|