Vue传参和数据流设计
props
react和vue中的props是父组件将值传递给子组件的形式,父组件可以将任何自己可以拿到的变量与方法,传递给子组件,并且传递是当时的值,后续子组件是不可以更改这个值的。
这么来说其实很多值只要子组件想要用,父组件总是可以做得到给子组件传递的,但是否所有的子组件需要的值,都应该用props传递呢?
我们换一个思路,如果我们去写一个加法函数,很显然他的参数需要两个数,返回值是一个数,这里输入的两个数就相当于是组件的props,在我们去设计组件的props时,就可以参考这种方法。
- 举一个例子,如果我们有一个导航栏组件,其中会显示用户最在意的几个话题分类,右上角如果用户未登录显示登录按钮,如果登陆了显示头像。那么这个导航栏需要什么参数?我们很容易想到肯定需要登录状态,并且还要根据登录状态来加载他喜好的分类。但是思考一下,导航栏组件的父组件是谁?这个登录状态是父组件传给他的吗?
传参的本质
拥有某一状态(属性或行为的总称)的程序,将该状态放入需要这个状态的程序的上下文中(执行环境中,作用域中,怎么说都可以)
从刚才那个例子来讲,就是props是父组件为子组件传递状态的途径,刚才举的例子中,我们所需的状态(登录状态)其实应该存储于一个全局状态库,再由这个全局状态库来共享他的上下文,或者是让组件自发的去获取这个库来寻找他需要的上下文。
这个共享上下文的实现方法,其实非常简易,直接在根目录创建一个context.js,里面放一个大对象,装载全局上下文,谁想用就引入这个文件,然后用,想要改也可以引入这个文件,然后改。
现在讲的这一个思路就是非常简单的一个建立全局变量的方式,只不过这个全局变量不是默认引入的。
Vue官方提供的具体的几种传参方式
- props 属性
语法就不赘述了,是数组式对象式,还是把所有的option都填写完整的形式,这些都无所谓,重点就是他的共享上下文是直接由父组件递交给子组件。
- slot 插槽
这个传参也是父组件传给子组件,但是传的位置不一样,他是夹在父组件中间传的,也就是闭合标签的两个标签之间,传入的内容也更偏向于组件,或者渲染函数一类
- provide inject 依赖注入
这个是官方提供的共享上下文的方式,由任意祖先组件将需要共享的数据"提供出来"provide,然后任意层级的子组件需要获取该信息的时候将该数据注入自己inject,这样就完成了上下文的共享,其中存储上下文的区域是祖先组件。其实这种用法就是小范围的vuex。
- vuex / pinia
提供一个状态存储库store,任意组件可以通过直接引入store来获取需要的状态,任意组件可以利用已经声明的处理器函数mutation来更新store,因为加入了处理函数机制,修改变得更加有弹性,可以实现自定义业务,异步,数据处理等等许多其他的能力。
- 手写context共享以及钩子
这个写好了的话,其实原理和vuex是一模一样的,只不过少引入了一个包,在不需要那么大规模但是上下文又有一点复杂的情况可以用,或者就是比如你是框架开发者,你没法强迫其他开发者因为用了你的框架而被迫选择vuex,那你就自己手搓vuex。
- eventBus 事件总线
简单来说就是一方发送,一方接收,你可以理解为不用建立共享上下文的存储对象,就可以给任何层级的两个组件单向传值,本质上发布订阅模式,数据流的耦合方式是控制耦合,是极力不推荐的传参方式,用多了会让整个程序的数据流流向混乱。简单来形容,eventbus就是传参界的!important,不到万不得已是不采用的。