前端开发那些事儿Vue技术每天学一点Vue3

vue3:双向绑定 vs 单向数据流

2021-08-28  本文已影响0人  自然框架

惯性思维

一开始看到vue说是双向绑定的,就自动认为数据流向也是双向的,后来发现我错了。

以前的想法是:我给你,你给我,这就是双向绑定,同时也是双向流动,但是vue不是这么干的。那么vue是怎么做的呢?

抛物线的单向数据流

为了便于说明,画个图先:

绑定与流向

步骤:

  1. 在父组件里面定义一个 info
  2. 在子组件里面定义一个 props 接收
  3. 子组件内部使用 emit “修改”props
  4. 模板重新渲染

看表面效果:

这不就是双向流动吗?

但是实际情况并不是这样的。

实际情况

表面上看,emit 是在子组件写的,但是具体的赋值操作并不是在子组件里执行的。

看上图里面的1,2,3,特意调整了字号和颜色,应该很明显吧。这是一个“抛物线”,兜了一个圈子才实现了修改。

缘由

那么为啥要这么折腾呢?大概是因为响应性吧。
以前有个段子,不能给邮箱设置“自动回复”功能,如果设置了可能会这样:

比如我给你发了一个邮件,你的邮箱服务会自动给我发送一个“已收到”的反馈。

然后我的邮箱服务收到你的反馈后,认为是收到了新邮件,于是又给你的邮箱发了一个“已收到”的反馈。

于是开始了无限循环。

那么vue是否也有类似的麻烦呢?不太清楚。

但是从设定来看,大概是为了避免这样的问题吧。

直接修改,又是咋回事?

不是规定子组件不能直接修改props吗?怎么还来个直接修改,违规了!

经常看到这样的说法,其实并不是这样的。

这里特指vue3,vue2没研究过。

在 vue3 里面 vuex 的状态是 proxy 的。
子组件的 props 也是 proxy 的,并且把第一层属性设置为只读,这样在子组件里面就无法直接修改第一层属性。

但是留了个“缺口”,没有限制第二层属性也是只读,这样的话我们就可以利用这个漏洞做点骚操作。

比如 info 定义为:

const dialog = reactive({
  visible: false,
  width: '80%'
})

子组件的 props 定义为这样,然后可以这样操作:

const props = defineProps({
  moduleId: [Number, String],
  dialog: Object
})
const dialogs = props.dialog

熟悉 el-dialog 的话,就会发现我想做什么了吧。

  <el-dialog
      :title="'添加模块:' + props.moduleId"
      v-model="dialogs.visible"
      :width="dialogs.width"
  >

我喜欢在父组件里面放一个按钮,然后把 el-dialog 放到一个子组件里面,这样父组件的代码不容易乱,单击父组件的按钮,可以打开 el-dialog。
但是问题来了,是否显示是通过 v-model 来设置的,而子组件的 v-model 不允许直接写 props。

一般的做法是写一个 computed ,设置 get 和 set,
get 获取 props 的属性,set 里面用 emit 来提交。
但是这样做很麻烦有没有。

于是我“直接”修改了,我觉得代码就应该直接一点。(emit 内部代码比较复杂,我没看懂,断点跟踪都没跟下去)

可能有人就不乐意了,你这是瞎干,违规了!

看看上面的图,proxy 会拦截 set 操作,然后实际修改值的操作在哪里呢?肯定不在子组件。

既然不是在子组件里修改的,那么这么做也没有违规,和使用 emit 是一样的原理。

使用emit是合规的吧。

补充,proxy 的 set 到底在哪里?

按F12看一下源码,可以找到 proxy 的 set 的位置,在一个单独的js文件里面,那么怎么算呢?应该看js文件是在哪个组件里面引入的。
看看代码,是不是在父组件写的import { reactive } from 'vue',所以修改操作实际发生在父组件,和emit是一样的原理。

proxy 的 set

不解

props 本身就是一个 proxy ,拦截一下就可以在父组件进行修改,那么为啥还非得使用 emit 绕圈圈呢?(不会又是为了向下兼容吧)

如果你想说,这样无法跟踪,不知道哪个子组件修改了,的话,那么可以看看上一篇:

使用proxy 给状态加一个跟踪功能: https://www.jianshu.com/p/c8b0d5c8ef42

上一篇 下一篇

猜你喜欢

热点阅读