首页 > 代码库 > 总结一下公司项目使用各种较新的前端技术和 Api 的一些经验。

总结一下公司项目使用各种较新的前端技术和 Api 的一些经验。

关于 ES6:

需要注意 ES6 的一些特性和 API 是需要一个 200k 的 Polyfill 才能得到支持的,特性如 for ... of 循环,generator,API 如 Object.assign 等。我们的做法是放弃这些特性,单独引入对应 API 的 Polyfill 。

 

关于 Webpack:

Webpack 有一个 Code splitting 功能,墙裂推荐。Webpack 作者自己表示发明新轮子的原因就是因为其他工具没有 Code splitting 。

我们在做包体积优化这个事情的时候,看到有两个可能性:DllPlugin 和 Code splitting。严格来说,这两个方案不是解决同一件事情的,侧重点不一样。

DllPlugin 可以把依赖库和业务代码分开,这样一是能够提升编译效率,二是业务代码修改打出的包很小,每次修改,用户只需重新加载一个很小的业务代码的包。长期来看是非常省流量的做法。

Code splitting 做的事情是异步加载依赖包。有点像 RequireJS 。比如我有个页面有轮播的需求,引入了一个几十k的第三方库,而其他页面都用不到,我就可以使用 Code splitting 的特性,异步加载这个库。这样只有在用户访问特性页面才会加载这个库,否则这个流量就省了。

考虑到我们的上线并不十分频繁,DllPlugin 所带来的流量节省效果并不明显,所以我们优先引入了 Code splitting 方案。

 

Fetch 及 CORS: CORS 不是一个新技术,但是似乎因为兼容问题,业内用得不多,也可能是我孤陋寡闻。我们使用 CORS 的考虑是:

1: 想用 Fetch 但不想用 Fetch-jsonp 。

2: 需求都是来自移动端。

于是就上了 Fetch + CORS 的方案。这里有一个小小的注意点:当开启 CORS 发出一个非简单请求(not-so-simple request)时,浏览器会发起一次预请求(详见:http://www.ruanyifeng.com/blog/2016/04/cors.html),预请求必须是一个简单请求(simple request),这件事情非常好理解:我在发一个非简单请求之前,需要询问服务器这个非简单请求包含的特殊字段能不能发,那么一定不能在询问的时候就已经带上了这些个特殊字段,否则预请求存在的意义是什么。

 

还有什么想到了再补充吧。。

 

总结一下公司项目使用各种较新的前端技术和 Api 的一些经验。