今天在社区答题的时候,遇到一个题目 《CDN引入的 Vue3 和Element Plus 表格异常,怎么解决呢?》。在去复现的时候和提问者犯了一样的错误。没有显式地写出关闭标签,想当然的直接复制了官方的代码示例就粘贴上去运行了。
然后还以为是 CDN 上最新版本的包有问题,从 2.2.32
一路试到了 2.0.0
都还是一样情况,然后很果断地得出了一个结论:官方的演示 Demo
也有问题 😂。
其实问题就是在 没有显式地写出关闭标签……
今天在社区答题的时候,遇到一个题目 《CDN引入的 Vue3 和Element Plus 表格异常,怎么解决呢?》。在去复现的时候和提问者犯了一样的错误。没有显式地写出关闭标签,想当然的直接复制了官方的代码示例就粘贴上去运行了。
然后还以为是 CDN 上最新版本的包有问题,从 2.2.32
一路试到了 2.0.0
都还是一样情况,然后很果断地得出了一个结论:官方的演示 Demo
也有问题 😂。
其实问题就是在 没有显式地写出关闭标签……
这次在写业务的时候因为是无限层级的递归表单,用了 provide/inject
来暴露注册以便收集数据。所以就想要用 Map
数据结构来处理数据的收集等等功能。直接使用 记录ID 作为键名就可以了,这样也可以直接去重。但是写完了业务代码之后发现我把后代的表单注册进来并没有触发响应,导致数据回填失败。
所以想着是不是 Vue 2x
无法监听 Map
或者 Set
的数据变更的。就去检索了一下相关的信息,发现 Vue 2x
真的无法监听 Map
以及 Set
俩兄弟。只能够通过修改其他变量来曲线救国。
Vue 3x
通过 Proxy
来代理就没有了这个问题。
在 Vue
项目的开发中,很多人都因为想要限制 CSS
样式的作用范围(避免样式污染的问题)去使用 scope
属性。
但是很多的情况下都会去修改分装好的子组件以及UI库中的组件样式,所以经常会用到 样式穿透 这个东西,因为我以前是使用的 Stylus
作为样式预处理器的,所以并没有感觉到什么困惑的地方,但是有很多同学是使用的 Scss
以及 Less
的,对于他们来说什么时候使用 /deep/
什么时候使用 ::v-deep
是很困扰的。特别是对于一些刚刚进入前端圈的小伙伴们。
正好最近在思否也遇到了很多人来问这样的问题,就像一次性都把相关的疑问都回答了。
最近在写基础组件,同事一直反馈说组件总是提示警告:
[Vue warn]: Invalid prop: type check failed for prop "value". Expected String, Array, got Null
一开始以为是接收的问题,把定义的props
加上了工厂函数后没有报异常就没再管了。
今天再去看的时候发现还是有报错,检查了一下组件代码没发现问题,在查看业务代码的时候发现同事喜欢给声明的变量默认赋值为 null
。而不是声明正确的基础类型。所以我就想应该如何把这个问题彻底解决掉。
今天我中遇到了一个这样的场景,发现触发复用的自定义组件中添加了防抖的函数,发现只执行了一次,并没有如预期的那样每个组件内的函数都执行一次。
一开始以为是没有同步赋值,检查了一下没问题,才把关注点转移到 debounce
上面。移除防抖之后果然解决问题了,但防抖又不能去去掉。
所以查了一下相关的问题,发现是因为多个组件实例是共享同一个预置防抖的函数,并不是相互独立的。
最近有一个项目,我发现有一些表单内容高度重复的情况,几张页面的表单虽有些细微差,但还是有很多同样的表单内容,或者 表单域A 和 表单域B 同时出现在一个页面中的这种情况。
我就想着能不能把他们都提出来,单独的做成组件在再使用到这些内容的时直接引入对应的表单域组件,并且可以把下拉菜单的远程查询也放到组件中,这样就会精简点很多重复的代码。
也算是经典面试题的一部分了,对于父子间的通讯很多时候的使用我都是限于 props
/$emit
来处理,或者 Vuex
/EventBus
这种方式,很少会用到 Provide
/Inject
来处理。其实这是一个很实用的跨级组件间通讯的方式。
这对选项需要一起使用,以允许一个祖先组件向其所有子孙后代注入一个依赖,不论组件层次有多深,并在其上下游关系成立的时间里始终生效。
看文档中关于这对API的解释就可以看到,向其所有后代 注入一个依赖,所以在跨级组件间通讯,或者 单父多子组件间通讯就会很方便了。
简单的使用可以查看官方文档中的示例,我就不举例了,因为使用起来真的很简单。
最直白的(但是错误的)可以理解为 props
的强化版本,暴露一个可以无视子组件的嵌套层级属性来进行注入。
一直没有怎么用过 Vue 的 过滤器 API,都是直接用 AntD Pro 当中提供的数字千分格式化、时间格式化之类的,没有自己去声明过,主要是因为 Array.prototype.filter
的先入为主,一直把 vue.filter
理解成为了筛选,而不是过滤器。
其实,vue.filter
是借鉴了 Linux 当中的 Pipe 符号 (|
) 来处理数据 ,然后借用了 filter
这个名字:
利用 Linux 所提供的管道符 “
|
” 将两个命令隔开,管道符左边命令的输出就会作为管道符右边命令的输入
其实我觉得如果直接用 pipe
来命名其实就更好理解了,但是也许是因为前端圈子接触到 pipe
的人并不多,使用 filter
这个熟悉的单词可能更加容易让大众接受。
使用起来确实很方便,用 |
符号分隔就行,会按照 从前往后的顺序 依次 传入过滤器,然后返回转换后的值。
等到后来再遇到适合的场景想起来使用 filter
,但又因为项目的历史原因没有去使用,因为自己都是局部使用 computed
计算 和 方法调用返回 来处理(也是Vue3所推荐的替代过滤器的方式)
最近在考虑把遍码习惯整理一下,一个良好的遍码习惯可以有效减少一个项目的维护成本,
因为不可能在整个项目的生命周期中,均由最初的开发人员来维护,或者所有的代码都是由你一个人写出来的,
改善代码的可读性,可以让开发人员尽快理解历史的业务代码。
之前也有研究过 ESlint的格式化风格 选择一款适合自己的来规范自己,但是了解的越多,越觉得还是需要团队互相讨论来找一个大家能都接受的妥协结果,所以最后还是选择了 Prettier
,因为我觉得其它两种风格相对来说太严苛了,很多项目都是自己开发并没有多人合作开发的情况出现,所以使用 Prettier 相对来说所自由一些…
今天洗澡的时候在听 饥人谷的模拟面试 (五) 的时候,一直觉得这次面试的学生有点差,如果是我来面话可能已经让他回家了,但是 方方老师 很有耐心,在中间问道 .sync
的时候我 ???? 完全没有印象了。
正好已经有2个月没有更新了,所以复习一下 v-bind
的三个修饰符 [ .prop
, .camel
, .sync
]