良好的编码习惯
- 统一代码风格:使用Eslint
可以帮助我们检查代码格式,慢慢养成编码习惯。根据实际情况,初期可以使用较简单的代码规范。
- 命名规范,使用
与业务或功能相关的词
,力求语义表达完整清楚, 不要嫌名字长
`abc` `form1` `form2` // bad
`userRegistForm` `todoList` // good
- 命名风格:小驼峰命名法
下划线命名:user_name
中划线命名:user-name
小驼峰命名:userName
大驼峰命名:UserName
- 缩进
空格还是tab?4个空格还是2个?tab的4个空格
- 多写代码注释
最低要求:在文件头部的注释写明代码文件作用,关键代码、逻辑复杂的代码。
vs code插件
/*
* @Author: xuan
* @Date: 2018-05-15 20:08:15
* @Desc: 我是文件说明,我要表达文件代码主要功能
*/
关于优质代码一些个人经验
-
非必要不重新渲染
state渲染流程
- 不是页面中
看得见的文字/状态
数据,不要放到state中。这类数据包括一些中间状态数据或者函数间共享的数据,它们的改变一样会引起页面重新渲染,吃掉浏览器资源。
那么这类数据放在哪里呢?与组件并列的变量或者ref都可以
import React from 'react';
const listQueryTimeout = 1.5 * 1000;
export default (props) => {
...
}
- 复杂的对象不要放到state中。state越复杂,调用了set方法之后React/VUE的diff函数耗时越久,所以自定义对象层级不超过两层。此外一些类库产生的对象也是复杂对象。
const [ viewer , setViewer ] = useState(new Cesium.Viewer('cesiumContainer')) // bad
const [ userProfile, updateUserProfile ] = useState({
name: 'xxx',
department: {
id: '1',
name: '研发部'
}
}) // ok
const [ userName , updateUserName ] = useState('xxx') // good
- 增加功能时,先梳理清楚原有代码逻辑,不要随意增加state
- 单个函数的代码行数不要超过100行
- 倒逼代码精简和逻辑的拆分
- 编码水平提升可将该指标逐步变小
- 功能块内部代码解耦:业务计算逻辑与页面渲染分开。好处,适应需求修改,方便未来对算法的优化
getPrice = (price = 0, isMonth = false) => {
if (price === 0) {
return 0 + '元'
} else if (!isMonth) {
return (price / 10000).toFixed(2) + '万'
}
return price + '元'
}
showPrice(price) {
return <div className='price-containre'>
<span className='price-tile'>单价 ¥</span>
<span className='price-contetn'>{ this.getPrice(price) }</span>
</div>
}
render(<>
{ showPrice('111.112') }
</>)
- 注意循环
- 尽量不要在render遍历数组和进行计算。接口获取数据后先计算出渲染所需数据再放入state,遵循
先计算好,再渲染
的规则 - 数据量较大或者计算较复杂的循环时,使用for循环。for循环的效率综合来看略好于数组内置函数 参考链接
- 节流与防抖
合理使用节流和防抖,可以控制事件触发频率,提高代码性能。
- 节流
规定在一个单位时间内,只能触发一次函数。如果这个单位时间内触发多次函数,只有一次生效。n秒内只执行一次
滚动加载,加载更多或滚到底部监听
谷歌搜索框,搜索联想功能
高频点击提交,表单重复提交
- 防抖
在事件被触发n秒后再执行回调,如果在这n秒内又被触发,则重新计时。只在最后一次n秒内执行
搜索框搜索输入。只需用户最后一次输入完,再发送请求
手机号、邮箱验证输入检测
窗口大小Resize。只需窗口调整完成后,计算窗口大小。防止重复渲染。
网友评论