南妮!vue引用组件时总报错,必须得查这查那的源码

vue

背景

原则上,为了便于维护和统一,我们会把可能在多个地方使用的功能做成一个组件。

而接手项目的时候,也尽量使用别人已有的组件。

这不,最近刚接手了个项目,引用别人的组件时,有些是可以使用的,但过些时间,发现就不能使用了,有的不能使用,直接报错。

本来好的,突然坏了这种就很搞事情了,要是没发现,演示是被老板看到岂不直接死翘翘?

问题现象

然后报错信息类似 [Vue warn]: Property or method "valueList" is not defined on the instance but referenced during render.

然后组件无法按预取工作,渲染不正常,功能无法使用。

问题排查

  • 检查组件是否可使用

    反正组件在自己的页面运行不正常,如果知道别人哪里有使用这个组件的情况下,先去看看这个组件在别人的页面上是不是能正常使用。

别人的页面能正常使用。

  • 确定使用方式

    那么看看是不是自己的使用方式不对。这时候就得看组件的 API 文档,这个当然一般都没有,所以就只能看源码了。源码先看入参部分,好家伙,props 该传的都传了。

搜索一下报错的东西,valueList 有匹配结果 inject:['valueList'],这是什么鬼?看起来这像是要注入一个参数,而我没有注入。

百度一下 vue inject 由于是 vue 项目所以需要添加关键字作为限定。

在父组件只要声明了provide,在其子组件,孙组件,曾孙组件等能形成上下游关系的组件中交互,无论多深都能通过inject来访问provider中的数据。

看起来在这个组件需要依赖 valueList 这个数据,可能我没有在我的页面里使用 provide

解决问题

那么问题来了, valueList 数组是什么?我该构造怎样的数据给它?

好吧,这时候就得查找别人是怎么引用这个组件的,然后根据 inject 的使用方式,需要找到引用这个组件的父级里找 provide 参数在哪声明的,需要看看构造这个参数的地方是怎样构造的。

那吧,上一层没有,再上一层……

也可以直接在代码中那家关键字 valueList 找到附近有 provide 即大概率确认。

现在,在一个上上上级 index.vue 中找到了以下代码片段:

  provide(){

return {

valueList:() => this.valueList

}

},

看起来还得再找 this.valueList 是什么东西……

知道了 valueList 是怎么构造的,这下还得思考,在自己的引用这个组件的地方,能不能构造出现这样的数据,例如这些数据可能由其他参数产生,但这个参数你所在的页面不一定能拿到。

思考问题根源

通过上面这些历程,不禁让人沉思,用个组件这么麻烦?不应该引用后传入必要的参数就好了嘛?像 antd / element-ui 这些 ui 组件库一样。

为什么看了组件本身的源码不行,还得看组件上上上层的源码?

这相当于定义了一个未知作用域的未知位置的不易追踪的“全局”变量,与 单向数据流状态可管理 截然相反。

解决问题根源

通过上面这些历程,我不认为这样的 inject 使用方式是一种优雅的使用方式。于是百度 不推荐 inject 类似的关键字,希望能找到一些大佬“喊话”,然后向人说明这样的搞法不行,这样搞得我用组件的人很难受。

果然,在官网上就有醒目的警告注明:

provide 和 inject 主要在开发高阶插件/组件库时使用。并不推荐用于普通应用程序代码中。

另外在很多第三方文章中也有:

官网不建议在应用中直接使用该办法,理由很直接:他怕你"管不好"

设计项目,通常追求有清晰的数据流向和合理的组件层级关系便于调试和维护,然而这对选项支持任意层级都能访问,导致数据追踪比较困难。不知道那一层级声明了provide又或是哪些层级使用了inject。造成比较大的维护成本。因此,除组件库或高阶插件外,Vue建议用Vuex解决或其他办法处理。


果然不出所料,找到各种文献,就可能借他人之口让写组件的人处理一下这些问题了。

后记

像这种不太负责的 inject 实现已经贯穿了整个项目的五心六腑,要改的地方可能很多。在这种情况下,如何愿意改和如何改又是一门学问了。

以上是 南妮!vue引用组件时总报错,必须得查这查那的源码 的全部内容, 来源链接: utcz.com/z/378560.html

回到顶部