0 前端项目技术选型

Tue, Sep 18, 2018

 

0x0 单页应用 & 多页应用 相关技术选型

不同项目需求不同：

• 传统的多页网站不会用React
• 单页应用用jQuery实现困难，需要自己处理技术细节，出错的可能性多

两大类站点

多页应用

每个新页面都需要做页面的跳转，是通过浏览器发请求到服务端的

日常：前端拿到设计图做好模板，后端用jsp等模板引擎填充数据，拼html代码，形成真实的html给浏览器做显示

特点：

1. 每个页面跳转都经过服务端
2. 新页面出现需要刷新浏览器
3. 用户需要有一定的等待时间

js定位：js主要做动画，数据处理都是在后端做好的

1. 后端处理好拼给浏览器例如：
2. 1. 如点击某个按钮后，隐藏了一个div显示了另一个div
   2. js设计初衷就是做这些小功能的，随着js标准升级，功能才变强大
   3. 

常用类库：

1. jQuery：对原生的DOM事件做了封装，解决了浏览器兼容性问题 & 提供更好用的api
2. mootools | YUI：DOM封装类库，使用方法和原生js差不多 - 多页应用时代更多的就是通过js操纵DOM

常用工程架构工具：

1. 无特定前端工具，后端配合grunt：一头豪猪，是一个命令启动器，本质上是一个注册任务的脚本处理器
2. 1. 通过grunt执行一个config（比如指定编译的文件、编译好的东东输出到哪个目录下面）
   2. 用起来比较麻烦，执行任务很慢，因为硬盘读写效率低导致的
   gulp：也是跑任务的工具，和grunt差不多
   1. 好处是通过stream的方式处理文件，比grunt更快，API更简洁好用
   2. 现在基本上已经被npm替代了

常用模块化工具：

1. 大部分情况下没有模块化工具：每个页面单独引一个jQuery，单独写几行代码就好
2. seajs：支付宝的小伙开发的
3. requirejs

静态文件处理：

1. 手动编译到html中，配置的时候不够灵活
2. 有的时候不处理，交给后端用Nginx机制去处理

单页应用

特征 - 前端路由：点到一个新页面，浏览器不需要刷新，只是页面内容刷新就可以了

三大类库：React、Vue、Angular

• 特点：
  • 各自有自己的开发范式
  • 对整个DOM做了上层的抽象 
• 好处：
  • 隔离了DOM层，所以才能做服务端渲染
    • 服务端没有js的DOM api的运行环境（如：document.xxx），如何把js的DOM操作渲染成最终的html呢？
    • 通过类库抽象出来的方式去渲染

1. 前辈：backbone.js
   • 前端MVC的经典案例，整个类库的代码量很少
   • 是一个骨架，细节需要自己实现
2. React：
   • 需要把它的代码编译成浏览器支持的代码才能运行，JSX语法浏览器并不认识
3. Vue：
   • 和React的主要区别：Vue的数据是双向绑定的，下层可以修改上层数据。React遵循单向数据流，数据只能从上到下修改
4. Angular：
   • 用ts开发
   • 里面有不少超前的东西
   • 目前的生态不够完整

工程架构工具：npm 占据90%左右的使用量了

模块化工具：

1. webpack：
   • 可以打包任何的静态资源文件（js、jsx、css、sass...）
   • 可以按照想要的样子做编译
   • 
2. rollup.js：
   • 能够按需引入函数
   • 而不是把文件中的所有的函数都包含进来

静态文件处理：使用webpack处理静态文件，直接在js里引静态资源就好，模块化工具会自动转换成线上可用静态资源路径

0x1 web app 架构

简介

以前：写好网页模板交给后端，后端填数据，把填好的html返回给浏览器

现在：webapp所有的前端页面跳转，都在浏览器中做

• 一次加载的内容变多
• 数据通过api获取，在前端渲染出来
• 大部分代码都是js代码，甚至不用写html了

工程架构

解放生产力

通过自动化操作，保障开发目光能聚焦在业务上，而不是繁琐的文件复制、目录改变之类重复性的劳动

源码处理：需要让jsx能自动转成js、自动使用babel编译、图片路径自动处理

图片处理：

• 图片是一个资源，在js中应该能直接import到
• 为什么要Import？
  1. 业务代码开发目录时在src目录中，而最终是需要把「资源」编译到dist目录中，这一步其实是需要做资源拷贝的
  2. 希望图片能做「浏览器长缓存」，需要控制图片的版本。我们不希望每次手动在图片后面加版本号，这一步也希望能交给工程架构去自动完成
  3. 最终的图片url，后面会自动加一串hash值
• 我们在业务代码中，直接把import进来的东东，作为资源路径即可，而不必关心dist目录中图片的hash值是多少，每次的真实路径是什么

环境搭建

每种框架的解决方案都不一样（jsx、ts等），需要有一个编译的过程，把不同语法类型编译成浏览器能识别的语言（es5）

预见问题：一开始，手头项目直接写css即可。但是以后会不会出现css太多类重名的问题？如果会，是否需要提前考虑解决方案还是到时再说？

质量保证

通过代码规范，保证排错、可读性

code lint：用来规范代码的写法

排除环境差异：存在操作系统环境差异，需要通过工程架构避免类似问题

• 可以通过给编辑器放一个editconfig，处理不同环境下，代码规范问题
• 包括定义：方法结束时，应该留一个空行、用4个空格还是一个tab之类的

git commit预处理：强制自动做代码lint监测，有错就不让commit

关键点：定制

每个项目和团队都是不一样的，需要通过定制，满足团队的上述需求。

需要对所使用的定制工具，了如指掌，甚至自己需要写一些webpack的脚本实现某些功能才行

项目架构

工程架构更多的考虑让工程跑起来、更方便做开发（自动处理的东西之类的）

项目架构需要考虑：

• 网页如何运行
• 业务代码如何分层以便做好功能
• 预留业务扩展的空间

技术选型：

• web app使用哪个框架？还是需要自己写？
• 它的store选哪个？
• 数据逻辑如何做？

数据解决方案：

• mobx
• redux
• flux
• 需要考虑：
  • 后端结构是怎样的？
  • API形式如何？
  • http请求用什么方案？（自己写？还是怎样？）

代码风格：

和代码检测不一样，这里主要考虑：

• 数据存储：
  • 哪些数据存在mobx中？（mobx是整个应用公用的数据管理）
  • 哪些数据存在当前react的view中？

0x2 网络优化 & webpack打包

网络优化

方法：合并资源文件，减少http请求

说明：

• 浏览器并发http请求有数量限制，桌面8个，手机6个
• 如果需要并发请求的资源太多，会延长整个页面的加载时间
• 合并后，可以加快网页加载时间

示例：

• 我们一个工程中，js文件很多
• 打包出的实际页面中只有两个js文件，这就是代码打包的结果
• webpack根据所有的Import依赖树，做了文件合并，合并成一个js文件
• 打包完成，会生成一个dist目录，就是合并后的文件的存放目录
• 生成一个vendor.js文件：这个文件是压缩过的
  • vendor：包含了所有引入的第三方类库的文件
    • 因为第三方库更新频率较低，适合长期存在浏览器缓存中,所以单独打一个js包
• 生成一个业务代码打包后的js文件
• 类库的css文件，使用cdn存就好

方法：利用浏览器的缓存机制

• 加载资源文件的时候设置过期时间，默认使用浏览器内部的本地文件，这样就可以不经过网络了
• 缓存机制的问题：
  1. 网站更新后，如果js静态资源的文件名没有更改，那么浏览器端不会更新静态资源，而使用缓存的资源
  2. 需要有机制更新静态资源文件的文件名和url：
     1. 缓存更新机制
        1. 以前：直接加时间戳，问题是不能定位到哪个文件更新了哪个没更新，导致发布一个版本，所有静态资源都被更新
        2. 现在：打包文件根据内容做计算得到hash
           1. 如果内容有更新，hash就会更新
           2. 如果没更新，就用缓存