一个react的项目,光react肯定是不足以做出一个优秀的项目的。那么一个将军要配哪些兵的。
1. 懒加载
- react原生lazy react16.6以上才支持,简单好用
- bundle-loader,安装bundle-loader来使用,简单轻便,就是每个文件都的加上lazy,社区热度不够,目前已很少更新维护。
- react-loadable,简单轻便,api丰富(具体安装使用文档,可见我的github)
为什么要做dynamic import?
dynamic import不知道为什么有很多叫法,什么按需加载,懒加载,Code Splitting,代码分页等。 总之,就是在SPA,把JS代码分成N个页面份数的文件,不在用户刚进来就全部引入,而是等用户跳转路由的时候,再加载对应的JS文件。 这样做的好处就是加速首屏显示速度,同时也减少了资源的浪费。
2. 支持TS
不像java是强类型语言,js是一门弱类型语言,对变量的类型非常宽容,而且不会在这些变量和它们的调用者之间建立结构化的契约。如果你长期在没有类型约束的环境下开发,就会造成“类型思维”的缺失,养成不良的编程习惯,这也是做前端开发的短板之一,值得我们警醒。
尽管 ES 标准在近几年有了长足的进步,但在类型检查方面依然无所建树。大家可能常常会遇到这样到场景:
- 你调用一个别人写的函数,很不幸,这个家伙没有留下任何注释,为了搞清楚参数类型,你只能硬着头皮去看里面的逻辑。
- 为了保证代码的健壮性,你很有责任心,对一个函数的输入参数进行各种假设,最终给老板盛上了一碗香喷喷的意大利面。
- 领导看好你,让你维护一个重要的底层类库,你殚精竭虑,优化了一个参数类型,但不知道有多少处引用,在提交代码前,是否感到脊背发凉?
- 明明定义好了接口,可一联调就报错了——“TypeError: Cannot read property ‘length’ of undefined”,于是你怒气冲冲地去找后端理论:“嘿,哥们儿!这个字段是数组!这个字段是数组!这个字段是数组!”
让我们see see下面的Dome:
1 == '1' //数字和字符串 true
'1' == true //字符串和布尔 true
null == undefined // null和 undefined true
let a=1 //a定义为数字
a={b:1} // a也可以改为object {b: 1}
// 再比如
let arr = [{a:1}];
function mapArr(arrVal){
return arrVal.map(ele=>ele.a)
}
mapArr(arr); //[1]
//在某个不知道的情况下 arr给赋值成 undefined,而还是执行mapArr(arr)
//Uncaught TypeError: Cannot read property 'map' of undefined
这个时候就需要TS,很好地弥补了 JavaScript 在静态类型检查方面的缺陷
官网定义:TypeScript是JavaScript 的一个超集,它可以编译成JavaScript,可以在任何浏览器,任何计算机,任何操作系统上运行,并且是开源的。
那么, TypeScript 究竟有哪些特性使得它成为大家的”刚需“?
第一,类型检查。TypeScript 会在编译代码时进行严格的静态类型检查,这意味着你可以在编码阶段发现可能存在的隐患,而不必把它们带到线上。
第二,语言扩展。TypeScript 会包括来自 ES 6 和未来提案中的特性,比如异步操作和装饰器;也会从其他语言借鉴某些特性,比如接口和抽象类。
第三,工具属性。TypeScript 能够编译成标准的 JavaScript,可以在任何浏览器、操作系统上运行,无需任何运行时的额外开销。从这个角度上讲,TypeScript 更像是一个工具,而不是一门独立的语言。
除此之外,TypeScript 还可以帮助团队重塑“类型思维”,接口提供方将被迫去思考 API 的边界,他们将从代码的编写者蜕变为代码的设计者。
Dome 子组件接口里定义了props里的name必须的且是string,而父组件没有传递,或者传错类型,typescript类型校验都会及时在开发阶段提示出来。
3.配置husky:stylelint、tslint,加入到pre-commit校验中
4.配置一下commitizen,规范commit格式,使得可以自动生成change.log
5.单元测试JEST
下面是测试 数字转英文的funciton ;0,1,2,3 依次转成 A,B,C,D
// 测试utils里面的方法
import { numberToLetter } from '../packages/utils/index';
let assert = chai.assert;
describe('#numberToLetter()', function() {
it('should return -1 when the value is not present', function() {
assert.equal(numberToLetter(1), 'B');
});
});
6.开发流程
- 从master 切代码 到dev
- 个人从dev 切分支 本地开发
- 个人代码合并到dev进行测试,UI基准测试
- dev代码合并到master进行发布(发布打Tag)
个人分支规范 版本-姓名-任务
7.UI基准测试
为了保证UI组件输出的正确性,引入半自动化UI基准测试。
组件的输出最终由 三个因素决定
1、数据源
2、运行环境(Mac/Window 不同Chrome版本)
3、组件代码
当固定 其中两个因素 就能准确知道 剩下一种因素变更对结果产生的影响
基于这个推论,固定数据源 和 运行环境 就能得知 组件代码变更对结果的影响
运行环境 Mac / Window Chrome59 Chrome64
ToDo:
1、完善数据源case
2、制定执行流程
3、生成各个浏览器的基准图片