登錄時序圖

發起網絡請求的流程圖

具體到業務開發過程中的前端來說，我認為上圖還不夠完整，于是我畫了下面這張以前端邏輯為出發點的、包含循環的流程圖。 我認為前端每一次發起網絡請求，跟后臺進行數據交互，都適用于下圖的流程： 

• hasChecked： 用一狀態標識本生命周期內是否執行過wx.checkSession，判斷該標識，若否，開始執行wx.checkSession，若是，進入下一步
• wx.checkSession()： 調用接口判斷登錄態是否過期，若是，重新登錄；若否，進入下一步

wx.checkSession()是小程序提供的檢測登錄態是否過期的接口，生命周期內只需調用一次即可。用戶越久未使用小程序，用戶登錄態越有可能失效。反之如果用戶一直在使用小程序，則用戶登錄態一直保持有效。具體時效邏輯由微信維護，對開發者透明

• wx.getStorage(session)： 嘗試獲取本地的session。如果之前曾經登錄過，則能獲取到；否則，本地無session
• wx.login()： 小程序提供的接口，用于獲取code（code有效期為5分鐘）
• wx.request(code)： 將code通過后臺提供的接口，換取session
• wx.setStorage(session)： 將后臺接口返回的session存入到localStorage，以備后續使用
• wx.request(session)： 真正發起業務請求，請求中帶上session
• parse(data)： 對后臺返回的數據進行預解析，若發現登錄態失效，則重新執行登錄；若成功，則真正獲取到業務數據拓展小程序網絡請求的能力

只要遵循上圖的流程，我們就無需在業務邏輯中關注登錄態的問題了，相當于把登錄態的管理問題耦合到了發起網絡請求當中。 一般情況下，我們程序設計都會遵循模塊解耦的原則，盡可能將模塊顆粒化到最小。這導致可能有些同學認為模塊耦合不是好事情，但是我認為這是要分情況的：

• 小程序區別與傳統的H5，不支持cookies，在代碼層級上講，這無形中就給登錄態的管理增加了復雜度：cookies會在H5的每個請求中自動帶上，但小程序的請求卻每次都需要手動帶上登錄態參數
• 小程序區別于基于公眾號登錄的H5來說，又存在一定的優勢：登錄授權時并不需要多次的頁面跳轉（Oauth），也正因為如此，小程序的請求在登錄態失效時，需要具備重新登錄并自動重試請求的能力（無頁面刷新感，用戶甚至都不能感知到進行了重新登錄）

以上兩點雖然是登錄態管理的問題，但從另外一個角度去理解，我更認為它是小程序網絡請求的能力問題，所以，我認為通過拓展小程序網絡請求能力來實現登錄態的自動管理是非常合適的。通用組件——weRequest

一個通過拓展wx.request，從而實現自動管理登錄態的組件。 先來看看怎么使用：

var weRequest= require('../weRequest');

// 初始化配置
weRequest.init({
    // 關于配置內容，將在后文詳述
    // 此處暫時省略...
})

// 發起請求
weRequest.request({
    url: 'order/detail',
    data: {
        id: '107B7615E04AE64CFC10'
    },
    success: function (data) {
		// 省略...
    }
})

• 引入weRequest組件
• 初始化組件配置
• 就像使用wx.request那樣去使用它自動帶上登錄態參數

我們來看看執行上面代碼的DEMO效果： 

可以看到，通過weRequest發出的請求，將會自動帶上登錄態參數。 對應的流程為下圖中紅色的指向： 
沒有登錄態時，自動登錄

那如果當前小程序并沒有登錄態的情況又會如何呢？ 接下來我們來看看本地無登錄態情況下的模擬： 

當本地沒有登錄態時，按照流程圖，weRequest將會自動執行wx.login()后的一系列流程，得到code并調用后臺接口換取session，儲存在localStorage之后，重新發起業務請求。 對應的流程為下圖中紅色的指向： 登錄態過期時，自動重新登錄

接下來我們再來看看，當本地儲存的登錄態過期之后，頁面的行為如何： 

對后臺數據進行預解析之后，發現登錄態過期，于是重新執行登錄流程，獲取新的session之后，重新發起請求。 對應的流程為下圖中紅色的指向： 
組件的配置項

weRequest提供一個init方法，用于對組件的配置，以下展示所有的配置項：

weRequest.init({
    // 儲存在localStorage的session名稱，且CGI請求的data中會自動帶上以此為名稱的session值；可不傳，默認為session
    sessionName: "session",
    // 請求URL的固定前綴；可不傳，默認為空
    urlPerfix: "https://www.example.com/",
    // 觸發重新登錄的條件，res為CGI返回的數據
    loginTrigger: function (res) {
        // 此處例子：當返回數據中的字段errcode等于-1，會自動觸發重新登錄
        return res.errcode == -1;
    },
    // 用code換取session的CGI配置
    codeToSession: {
        // CGI的URL
        url: 'user/login',
        // 調用改CGI的方法；可不傳，默認為GET
        method: 'GET',
        // CGI中傳參時，存放code的名稱，此處例子名稱就是code；可不傳，默認值為code
        codeName: 'code',
        // CGI中返回的session值
        success: function (res) {
            // 此處例子：CGI返回數據中的字段session即為session值
            return res.session;
        }
    },
    // 登錄重試次數，當連續請求登錄接口返回失敗次數超過這個次數，將不再重試登錄
    reLoginLimit: 2,
    // 觸發請求成功的條件
    successTrigger: function (res) {
        // 此處例子：當返回數據中的字段errcode等于0時，代表請求成功，其他情況都認為業務邏輯失敗
        return res.errcode == 0;
    },
    // 成功之后返回數據；可不傳
    successData: function (res) {
        // 此處例子：返回數據中的字段data為業務接受到的數據
        return res.data;
    },
    // 當CGI返回錯誤時，彈框提示的標題文字
    errorTitle: function(res) {
        // 此處例子：當返回數據中的字段errcode等于0x10040730時，錯誤彈框的標題是“溫馨提示”，其他情況下則是“操作失敗”
        return res.errcode == 0x10040730 ? '溫馨提示' : '操作失敗'
    },
    // 當CGI返回錯誤時，彈框提示的內容文字
    errorContent: function(res) {
        // 此處例子：返回數據中的字段msg為錯誤彈框的提示內容文字
        return res.msg
    }
})讓業務邏輯更專注，不用再關注底層登錄態問題

小程序對比以往的H5，登錄態管理邏輯要復雜很多。通過weRequest這個組件，希望能幫助開發者把更多精力放在業務邏輯上，而登錄態管理問題只需通過一次簡單配置，以后就不用再花精力管理了。FAQ我希望在請求時候，頁面能出現最簡單的loading狀態，該怎么辦？

只需要在請求的時候，加上參數showLoading: true即可，如：

weRequest.request({
    url: 'order/detail',
    showLoading: true,
    data: {
        id: '123'
    },
    success: function (data) {
        console.log(data);
    }
})

當然，如果你希望使用個性化的loading樣式，你可以直接使用beforeSend參數來進行自定義展示個性化的loading，并且在complete的時候將它隱藏。某些請求在返回錯誤時，我不希望觸發通用的錯誤提示框，而想用特別的邏輯去處理，該怎么辦？

只需要在請求的時候，加上參數fail: function(){ ... }即可，如：

weRequest.request({
    url: 'order/detail',
    slience: true,
    data: {
        id: '123'
    },
    success: function (data) {
        console.log(data);
    },
    fail: function(res) {
        console.log(res);
    }
})

此時，如果接口返回錯誤碼，將觸發這里定義的fail函數，且默認錯誤彈框將不會出現。為什么工具在發起請求之前，不主動去判斷第三方session是否過期，而要通過接口結果來判斷，這不是浪費了一次請求往返嗎？

每個小程序對于自身生成的session都有自己的一套管理方案，微信官方也沒有指明一套通用的方案來要求開發者，僅僅要求了應該保證其安全性且不應該設置較長的過期時間。 原文如下：

通過 wx.login() 獲取到用戶登錄態之后，需要維護登錄態。開發者要注意不應該直接把 session_key、openid 等字段作為用戶的標識或者 session 的標識，而應該自己派發一個 session 登錄態（請參考登錄時序圖）。對于開發者自己生成的 session，應該保證其安全性且不應該設置較長的過期時間。session 派發到小程序客戶端之后，可將其存儲在 storage ，用于后續通信使用。

因此，不能要求所有后端接口都要返回session的過期時間給前端，甚至有些后端邏輯對于session的管理是動態的，會隨調用情況來更新session的生命周期，這樣的話邏輯就更復雜了。但是無論任何一種管理策略，都必須會有兜底策略，即前端傳入過期的session，后端必須要返回特定標識告知前端此session過期。

因此作為一個通用的工具組件，我需要確保更多的開發者能夠低門檻地使用，所以并沒有針對各種特別策略去優化，而且我相信，對于正常使用小程序的用戶來說，登錄態過期是一個相對低概率的事情，對整體效率性能來說，是微乎其微的，使用通用的兜底策略去應對這種情況，我認為已經是足夠的了。