前端 ajax 請求的優雅方案

hankkin 發布于2019-08-22 11:17 / 1569人閱讀

摘要：本文客戶端為先講個故事類似這種支持的已經很友好了，請求成功后我們可以從的中拿到后端返回的數據。比如數據在中，這意味著我們每個請求都需要多做一次處理才能拿到實際的數據。要解除上述苦惱，我們需要對所有的接口請求做統一的封裝。

本文http客戶端為axios

先講個故事

類似axios這種支持Promise的API已經很友好了，請求成功后我們可以從then的Response中拿到后端返回的數據。比如：

axios.get("/user/12345")
    .then((response) => {
        console.log(response);
    })
    .catch((error) => {
        console.log(error);
    });

數據在response.data中，這意味著我們每個請求都需要多做一次處理才能拿到實際的數據。
然后，實際場景后端基本不會直接把數據給我們，他會做一層封裝，比如response.data的結構會是這樣：

{
    "date": "2017-12-14 15:21:38",
    "success": true,
    "obj": {
        ...
    },
    "version": "V1.0"
}

所以，response.data.obj才是我們真正要的數據啊喂，所以我們每個請求都需要再多做一次處理=_=

突然有一天，后端說，“response.data不再是對象，改成了JSON字符串，你做一下處理~”。
然后是的，每個接口，是每一個，我們都需要改成JSON.parse(response.data).obj，半條命哦！

如果，后端再說，“我又改回對象了，你撤銷之前的處理吧~”。。。
如果，后端又說，“不是所有的都是對象，有一些還是JSON字符串，具體你看下更新的接口文檔~”。。。
如果，我們不曾相遇。。。

后來的我們

ES6 Proxy用于修改某些操作的默認行為，等同于在語言層面做出修改，所以屬于一種“元編程”（meta programming），即對編程語言進行編程。
Proxy可以理解成，在目標對象之前架設一層“攔截”，外界對該對象的訪問，都必須先通過這層攔截，因此提供了一種機制，可以對外界的訪問進行過濾和改寫。

要解除上述苦惱，我們需要對所有的接口請求做統一的封裝。如此一來，就算后端改來改去，我們只需修改一個地方甚至不用修改！

const apiService = new Proxy(axios, {
  get (target, propKey, receiver) {
    return function (...args) {
      return target[propKey](...args)
        .then((res) => {
          const resData = typeof res.data === "string" ? JSON.parse(res.data) : res.data;
          return typeof resData.obj === "string" ? JSON.parse(resData.obj) : resData.obj;
        })
        .catch((err) => {
          throw err;
        });
    }
  }
});

對應的接口請求部分改為：

apiService.get("/user/12345")
    .then((data) => {
        console.log(data);
    })
    .catch((error) => {
        console.log(error);
    });

“你隨便改，我改一下算我輸！”

GPU云服務器云服務器 ajax的異步請求 ajax的post請求 ajax請求 ajax請求數據

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/92119.html

在單頁應用中，如何優雅的上報前端性能數據

摘要：本文的介紹的是如何設計一個通用的可以以較小的侵入性，自動上報前端的性能數據。具體的做法可以看我的上一篇文章在單頁應用中，如何優雅的監聽的變化。三如何上報性能數據那么如何上報性能數據呢，我們第一反應就是通過請求的形式來上報前端性能數據。 ??最近在做一個較為通用的前端性能監控平臺，區別于前端異常監控，前端的性能監控主要需要上報和展示的是前端的性能數據，包括首頁渲染時間、每個頁面的白屏時...

KitorinZero 2019-08-30 15:55 評論0 收藏0
在單頁應用中，如何優雅的上報前端性能數據

摘要：本文的介紹的是如何設計一個通用的可以以較小的侵入性，自動上報前端的性能數據。具體的做法可以看我的上一篇文章在單頁應用中，如何優雅的監聽的變化。三如何上報性能數據那么如何上報性能數據呢，我們第一反應就是通過請求的形式來上報前端性能數據。 ??最近在做一個較為通用的前端性能監控平臺，區別于前端異常監控，前端的性能監控主要需要上報和展示的是前端的性能數據，包括首頁渲染時間、每個頁面的白屏時...

curried 2019-08-02 14:07 評論0 收藏0
在單頁應用中，如何優雅的上報前端性能數據

摘要：本文的介紹的是如何設計一個通用的可以以較小的侵入性，自動上報前端的性能數據。具體的做法可以看我的上一篇文章在單頁應用中，如何優雅的監聽的變化。三如何上報性能數據那么如何上報性能數據呢，我們第一反應就是通過請求的形式來上報前端性能數據。 ??最近在做一個較為通用的前端性能監控平臺，區別于前端異常監控，前端的性能監控主要需要上報和展示的是前端的性能數據，包括首頁渲染時間、每個頁面的白屏時...

beanlam 2019-08-23 14:41 評論0 收藏0
如何優雅處理前端的異常？

摘要：二需要處理哪些異常對于前端來說，我們可做的異常捕獲還真不少。總結一下，大概如下語法錯誤代碼異常請求異常靜態資源加載異常異常異常跨域崩潰和卡頓下面我會針對每種具體情況來說明如何處理這些異常。前端一直是距離用戶最近的一層，隨著產品的日益完善，我們會更加注重用戶體驗，而前端異常卻如鯁在喉，甚是煩人。一、為什么要處理異常？異常是不可控的，會影響最終的呈現結果，但是我們有充分的理由去做這樣的事...

zoomdong 2019-08-02 16:10 評論0 收藏0