良好的编码习惯
- 统一代码风格：使用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。只需窗口调整完成后，计算窗口大小。防止重复渲染。
