Vue3.2:为什么Ref操作Dom好用高效?
缘起在开发一个项目之前,我们往往会先做一个需求分析。对于前端,我们可以研究或者选择一个基础的组件库来提高我们的工作效率。毕竟对于一个在乎时间成本的公司来说,是不会给你看电视剧玩游戏的时间去开发一个类似日历的组件的。然而,市面上的组件库并不能全部满足我们的需求。这时候就需要我们自己编写组件来应用到项目中了。而这就是我想说的:如何设计组件,使其易于应用(或减少代码量)并提高可扩展性,便于需求变更和后续维护?方式有很多种,利用Ref来操作Dom的特性是其中之一,但是这种方式让我们在维护和操作Modal、Popup、频繁操作Dom来显示和隐藏交互组件方面发挥了很大的优势.下面从几个方面分析一下Ref操作Dom的相关知识点和应用实例。Ref获取Dom的本质。Vue2.x和Vue3.x中的Ref操作Dom。据说Ref获得了Dom的精华。Vue2.x中Vue的对象属性$refs实际上是所有注册的refs的集合,ref对应模板模板中不同组件或普通Dom元素关联的ref="xx"。;源码中实际获取ref的方法也是通过native方法getElementById获取的Dom节点;可以说ref是document.getElementById的语法糖。vue3的ref延续了vue2的用法,也增加了创建响应式数据的功能。有人会问,既然ref和getElementById都可以获取到Dom,那么在项目开发中,选择哪种方法都无所谓。?关于这个问题,资料显示$refs相对于document.getElementById的方式,会减少获取dom节点的消耗;而具体原因将在下一篇文章中详细讨论。Ref操作Dom在Vue2.x和Vue3.x中是不同的。在Vue2.x中,我们只需要在相应的Dom元素或组件中添加ref="xx"属性,然后在Vue对象中使用this.$refs.xx即可。直接获取Dom并操作其方法属性,@ok="editAvailableUser"/>或dd
//$refsshowManagerModal(){this.$refs.avaUserTreeSelect.showModal(this.form.managers)控制台.log(this.$refs.user.text)},Vue3.2版本中Vue3.2的使用方式//普通Dom
//component
可能这里有人会有疑问,为什么要声明一个和模板的ref同名的常量变量,并绑定对应的dom呢?这里补充一下:早期版本的Vue3(3.0.0-beta.21)对compositionapi的支持只能在组件选项setup函数中使用,对应的变量都在setup()方法中传入return{写模板中需要用到的变量或方法}在3.0.0-beta.21版本中添加了constuser=ref(null);this.$ref。userRef操作组件Dom和父子组件将props从parent单向传递给child,child通过emits传递给parent,所以在控制弹出组件的显示和隐藏上也可以实现单向传递,但是这样,我们就会有如下父组件
subcomponentExchangeValidModalVue.vue
从代码中我们可以发现,实现一个组件的显示和隐藏功能是通过一个-父子组件的方式传递,要声明多个变量那么费劲,还得做两次监听,如果后面传入多个这样的参数,代码量可想而知,而且不易维护其实显示隐藏的功能可以直接在内部响应值,不需要在父级操作。将上面的代码改成如下:="true":on-close="onCloseExchange"/>在父组件中,我们只需要通过ref获取组件的Dom,然后操作Dom内部的方法即可;例如:父组件重写
/template>这样,是不是比从父母到孩子的单向数据传输方法?当然,我上面说的只是我举的例子。后面需要扩展组件中的功能时,也可以用类似的方式扩展,而不是单向的数据流。但是请注意,这种操作dom的方式并不是场景是最好的选择;我们可以根据情况选择。比如当一些数据只需要在子组件的类中实现,不需要父组件介入时,选择ref操作dom效率更高;补充知识点:在Vue3.2中,defineExpose默认不会暴露任何在中声明的绑定,即组件实例声明的绑定无法通过模板ref获取。Vue3.2提供了defineExpose编译宏,可以显式Expose组件中声明的需要暴露的变量和方法