业务基础库封装设计

STAR 法则描述

1. 背景

是针对的 pc 业务，之前的开发没什么规范，一些常用的方法基本上就是项目之间复制来复制去，导致非常的杂乱。比如说 http 请求，有的用 axios 封装的，有的用 jquery 封装的，还有的自己封装，非常的混乱。其次，项目缺乏质量监控体系，排查问题非常的麻烦，只能等用户反馈问题，然后去修，往往没办法判断出问题。

2. 任务

基于这些原因，我自己搞了一套基础库来统一这些流程，最终目标是让开发过程更加的友好统一，而且能有一些线上排查问题的手段。

3. 行动

基础库内封装了请求、登陆态、pc 业务使用的 iframe 方案，因此使用 postMessage 通信、以及一些其他常用的公共方法封装等等。质量监控体系则包含 http 请求上报、逻辑错误上报、资源加载上报这些。

4. 结果

开发上，很多常用的方法直接能使用，大大减少了代码冗余，很多逻辑不用自己再重复的去写，效率上能得到一个很好的提升。同时一些项目的一些公共方法得到统一，比如 http 请求，不再是随心所欲的去搞。
质量监控上，多了一种线上问题排查的手段，之前大部分都是等用户来反馈，使用这套方案能自己通过质量上报去发现一些潜在的问题，及时修复。

项目细节

1. 请求封装

对于请求的封装，就是对 xhr 的封装。常用 Content-Type 请求头，from-data，x-www-form-urlencoded，application/json 三种，需要针对这三种分别做对应的数据处理。然后就是 xhr 的正常请求，不过由于需要 http 监控上报，因此需要使用 EventEmitter 来处理 xhr 请求成功、失败、超时等几种情况，emit 出来然后 on 监听这些状态，进而对这些做不同的上报。

2. 登陆态

常规的 Cookie-Session 方案。

3. iframe 通信

目前的 pc 端的方案是，iframe 内使用我们的页面，内嵌我们的 iframe 是为了把发布等流程放到我们自己负责，而不被阻塞流程。但是也要接受 iframe 带来的问题，比如典型的跨域问题。一般常用 postMessage 来解决，当然也可以使用 hashchange 来解决。其实 iframe 更多的问题可能是体验样式上的一些问题，比如：

【高度自适应】iframe 是需要指定宽高的，可以通过 postMessage 来传递高度。
【窗口滚动】同样需要 postMessage 传递到外层然后外层来跳转。
【弹窗问题】内外是不同窗口，因此很难定位到中间位置，诸如此类问题。

4. 质量监控

使用 addEventListener 来监听整个页面

【未捕获 reject】unhandledrejection 捕获到没有处理过的 reject。
【脚本错误】error 捕获脚本错误和资源错误（instanceof ErrorEvent 脚本错误，剩余的 instanceof Error 都是资源错误），开启 Vue.config.errorHandler 之后会没办法捕获到脚本错误
【资源错误】但是资源错误的捕获需要提前放，如果启动时资源加载错误，框架中此时还没有监听，因此没办法捕获，需要单独写一份 js，然后脚手架中引入该文件