开门见山。
问题初始
在实际的前端项目中（尤其前后分离模式），可以说ajax请求是无法避开的工作内容（甚至可能是每天都写）。
ajax请求 —— 获取数据 —— 渲染数据
然而在 【获取数据】到【渲染数据】之间，却有个问题，如何确保【渲染】是在【数据】获取到以后才执行？
以axios这一ajax工具举例
function getInfo() {
axios.get('localhost:8080').then((res) => {
this.info = res.data // 将获取到的数据进行赋值
})
}
我们常见的作法，是利用.then来确保得到响应后，再执行相应的赋值、渲染操作
问题出现
但是在实际项目中，我们往往会将ajax请求，独立抽出封装。
// 在实际项目中，往往会多封装一层axios，确保符合业务需求
import request from './request.js'
// 然后建立api.js文件，集中处理各个接口
export const getInfo = () =>
request({
url:'localhost:8080',
method: 'get'
})
然后在实际组件中使用
import { getInfo } from './api.js'
function init() {
const res = getInfo()
console.log(res) //undefinde
}
为什么会出现undefinde？ 因为JS在执行的时候Promise会被放入事件队列里，也就是其他语句执行完后才执行
// 这时候可以理解为它的执行顺序是
const res
getInfo() //执行
console.log(res)
getInfo() // 返回的响应数据
也就是说如果不加以处理，那么往往你会数据获取失败，最终页面无法渲染正确数据。
这时候，就该ES7 为我们带来的武器 async/await 闪亮登场啦
问题初解
在上面的实际使用中，我们只需要加上async await，即可解决问题
import { getInfo } from './api.js'
async function init() {
const res = await getInfo()
console.log(res) //打印出数据
}
async 表示这是一个async函数
只有这样，才能使用await
await右边必须跟着Promise。
await的作用，就是确保promise返回响应了，才继续执行下面语句。
新的问题
如果出现error怎么办?error的捕捉与处理也是一个ajax请求很常见的问题。
可能我们一开始会使用try catch来进行处理
import { getInfo } from './api.js'
async function init() {
try {
const res = await getInfo()
console.log('数据获取成功')
// 执行后续相应操作
} catch (error) {
console.log(error)
// 执行后续相应操作
}
}
可是如果有多条 const res = await getInfo()要执行呢？
或者说获取数据后的后续操作比较多，不臃肿吗？
更何况一个前端项目，类似getInfo()的操作是极其多的，相应的，也会有极其多的try catch，这时候怎么办?
新的思路
针对try catch封装一层新的抽象
//新建一个文件，就叫它utils.js好了，专门用来存放我们封装的方法
export const handleAjax = async function(asyncFunc) {
try {
const res = await asyncFunc()
return [null,res]
} catch (error) {
return [error,null]
}
}
然后在我们的实际组件中使用它
import { getInfo } from './api.js'
import { handleAjax } from './utils.js'
async function init() {
const [res, error] = await handleAjax(getInfo)
if(error) {
console.log('报错啦')
}
}
咦，这样看的确是少了烦人的try catch ，但是好像只要有ajax请求，就会进行异常判断，也就是只要import { getInfo } 就一定会伴随import { handleAjax } 既然如此，我为什么不把异常判断及相应处理与 之前封装的request.js，合并在一起呢？
Great!
You got it!
这也就是为什么开头的时候我们特地封装出request.js的原因之一！
不过又有新问题了
最后问题
那就是在实际开发中，针对不同接口/需求，所要进行异常的处理是不同的，如果直接封装进request.js，恐怕在一些情况下会不适用。
所以到了这一阶段，要怎么选择，就得看自己的项目情况更适合哪一种了
PS：拿我之前的一个项目举例好了，我封装了两个axios，一个封装了错误捕捉，用于纯数据获取（例如广告列表之类的）的api使用，另一个则较为原始，供其他api使用（如点赞收藏之类的，情况比较复杂，处理方式也不同）
然而其他项目并没有这么做，所以嘛。。。
