所以日志会输出
undefinedi am sub
也就是说在父组件的 方法中, 能拿到 this. , 但是拿不到this., 因为this的指向以及改变了
回到u-
由于上面的特性, 我们也看到了uview对于 u-的处理, 他们为了使用者进行自定义返回的时候避免这个坑,
他们做了如下处理
goBack() {// 如果自定义了点击返回按钮的函数,则执行,否则执行返回逻辑if (typeof this.customBack === 'function') {// 在微信,支付宝等环境(H5正常),会导致父组件定义的customBack()函数体中的this变成子组件的this// 通过bind()方法,绑定父组件的this,让this.customBack()的this为父组件的上下文this.customBack.bind(this.$u.$parent.call(this))();} else {uni.navigateBack();}
通过bind的方法,把this的指向又交还给了父组件, 这样作为使用者,就可以肆无忌惮的通过props传递, 从而实现多种多样的自定义返回处理.
? 爸爸就该有爸爸的样子.jgp
再回到我们的问题
对于瞎玩二次封装的我们来讲, 在 子组件内部,我们的:-back=""中, 的函数体内部, this到底现在指向了谁??
打印一下
作为子组件的竟然持有函数 abc? 那很显然在
methods: {// 自定义返回-前置拦截customBackBefore() {console.log("navbar-customer-back-before")// this.$props.customBack()console.log(this)}}
此刻的子组件中的 函数体中, this指向的是父组件的
(当然,在子组件的 的生命周期等其他函数中, this还是指向子组件本身的)
为啥中this指向的是父组件
我的理解:
1.在未做二次封装之前, 我们一般直接使用 uview的u-, 一旦自定义导航事件函数, uview会帮我们处理, 把 Props传递,该方法里的this指向子组件而不是父组件 这个问题内部处理, 使得我们任何的自定义导航事件函数:-back="xxxx",在xxx中都能正确的拿回父组件的this
2.在做二次封装的时候, 最终的u-拿到的是page组件的this. 在重新bind的时候, 被组件内部的:-back拦截了
解决办法
这里有好几个方法,不过其中有坑, 我们来分析一下, 选那些合适~~~
先看看组件的,这里会添加事件的触发
// 自定义返回-前置拦截customBackBefore() {console.log("navbar-customer-back-before")}}
再看看page 父组件中的abc函数体, 这里通过两个this,来打印确定this的指向.
methods: {abc() {// page页的stateconsole.log(this.pageTitle)// navbar子组件的decconsole.log(this.dec)uni.showToast({title: "1abc2"})},}
方案1: 将错就错? 直接调用abc
// 自定义返回-前置拦截customBackBefore() {console.log("navbar-customer-back-before")// 既然this已经明确指向page父组件, 那显然直接调用this.abc()是可以生效的this.abc()}}
看看日志
该方案直接就躺平了, 就直接拿父组件的函数abc来执行, 日志输出方面也表明了, 在abc函数内部的this指向是page的,大问题没有.缺点是导致组件无法通用化, 和封装的目的相违背 pass
方案2: 坚持props传
坚持props传 - 子组件中,修正this指向 自己
既然 问题出在this的指向不对,那我们做一下this的指向重置即可
子组件全局设置一个 that 用来缓存 的this
在周期函数里赋值,(因为此时的子组件在这个生命周期里,this是指向自身的)
然后再 函数体重使用即可
不过,这里插一句, 还记得那句话么
文章插图
- Thinkphp+Uniapp开发的CRM客户关系管理系统源码
- uniapp app分享功能微信小程序的分享
- 如何处理杀毒软件提示:受到192.168.1.X的网络攻击,已阻止。暴破攻击防护
- uni-app+uView如何轮播图滑动时改变背景颜色和导航栏颜色