本次例会打算分享一些开发的小技巧和知识
谷歌开发者工具一些方便调试的小技巧
elements 里面选中某个元素,按 h 可以快速显示隐藏该元素,visibility: hidden !important
sources 里面,按 ctrl + o
可以打开某个 js 脚本,并且可以直接修改它,修改的内容在不刷新的情况下是生效的。
在 sources 里打开压缩过后的代码时,可以点击左下角的 {}
标志,会格式化已有代码
一个 css 小知识点
写 类似于 弹窗遮罩层的时候,可用 css 或 js
1 | .opoup-wp { |
关于写不写分号
没有应该不应该,只有你自己喜欢不喜欢。JavaScript
语法长得 C-like
不代表它本质上和 C
是一类语言,所有直觉性的 “当然应该加分号” 都是保守的、未经深入思考的草率结论。后来新设计的语言里可选分号的多得去了,光是 “可以加分号但是大家都不加” 的语言就有:Go, Python, Ruby, Swift,Scala…
至于说 “很难总结什么时候加不加”,其实真的很简单。真正会导致上下行解析出问题的 token
有 5 个:括号,方括号,正则开头的斜杠,加号,减号
抛弃鼠标
尽可能地去背一些快捷键,这样会减少你离开键盘去摸鼠标的次数,提高效率
百度脑图 写代码之前画一画脑图,清晰的逻辑会让编码事半功倍
合理冗余其实也是一种重构
说到重构,可读性重构是很有必要的,代码是写给人看的。
有这样一个需求,一开始很简单,需要设计两个运营展位:
1 | // 抽象一个组件 |
现在需求要求在第一个展位的标题上增加热文标记:
1 | const Item = ({ title, content }, index) => ( |
需求又变了,要求:在第一个展位去掉内容,并且在下方加个按钮;第二个展位的标题右边增加一个超链接以及增加一个副标题:
1 | // 往往会变成这样 |
面目全非,中间混杂着两个状态(第一个、第二个)的判断逻辑。
实际情况很可能比这个更复杂,在多状态交织逻辑难以通过一套代码表达清楚时,进行合理冗余就是个不错的选择。
将上面的例子用两个 if 重写如下:
1 | // 第一个展位 |
不要过度设计,简单才是最好的。。。但 react 并不是那么好用