前端项目技术选型

4,251 阅读5分钟

一个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

image.png


这个时候就需要TS,很好地弥补了 JavaScript 在静态类型检查方面的缺陷

官网定义:TypeScript是JavaScript 的一个超集,它可以编译成JavaScript,可以在任何浏览器,任何计算机,任何操作系统上运行,并且是开源的。


那么, TypeScript 究竟有哪些特性使得它成为大家的”刚需“?

第一,类型检查。TypeScript 会在编译代码时进行严格的静态类型检查,这意味着你可以在编码阶段发现可能存在的隐患,而不必把它们带到线上。

第二,语言扩展。TypeScript 会包括来自 ES 6 和未来提案中的特性,比如异步操作和装饰器;也会从其他语言借鉴某些特性,比如接口和抽象类。

第三,工具属性。TypeScript 能够编译成标准的 JavaScript,可以在任何浏览器、操作系统上运行,无需任何运行时的额外开销。从这个角度上讲,TypeScript 更像是一个工具,而不是一门独立的语言。

除此之外,TypeScript 还可以帮助团队重塑“类型思维”,接口提供方将被迫去思考 API 的边界,他们将从代码的编写者蜕变为代码的设计者。


Dome 子组件接口里定义了props里的name必须的且是string,而父组件没有传递,或者传错类型,typescript类型校验都会及时在开发阶段提示出来。

image.pngimage.png


3.配置husky:stylelint、tslint,加入到pre-commit校验中

www.yuque.com/dingyin-pah…

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

www.yuque.com/dingyin-pah…

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.开发流程

  1. 从master 切代码 到dev
  2. 个人从dev 切分支 本地开发
  3. 个人代码合并到dev进行测试,UI基准测试
  4. dev代码合并到master进行发布(发布打Tag)


个人分支规范 版本-姓名-任务

7.UI基准测试


为了保证UI组件输出的正确性,引入半自动化UI基准测试。


组件的输出最终由 三个因素决定

1、数据源

2、运行环境(Mac/Window 不同Chrome版本)

3、组件代码


当固定 其中两个因素 就能准确知道 剩下一种因素变更对结果产生的影响

基于这个推论,固定数据源 和 运行环境 就能得知 组件代码变更对结果的影响


运行环境 Mac / Window Chrome59 Chrome64

ToDo:


1、完善数据源case

2、制定执行流程

3、生成各个浏览器的基准图片