一个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校验中

https://www.yuque.com/dingyin-pahte/lnv9wi/nizvqp

4.配置一下commitizen,规范commit格式，使得可以自动生成change.log

https://www.yuque.com/dingyin-pahte/lnv9wi/nizvqp#eQJ5U

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、生成各个浏览器的基准图片