登錄時序圖

發(fā)起網(wǎng)絡(luò)請求的流程圖

具體到業(yè)務(wù)開發(fā)過程中的前端來說，我認(rèn)為上圖還不夠完整，于是我畫了下面這張以前端邏輯為出發(fā)點的、包含循環(huán)的流程圖。 我認(rèn)為前端每一次發(fā)起網(wǎng)絡(luò)請求，跟后臺進行數(shù)據(jù)交互，都適用于下圖的流程： 

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

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

• wx.getStorage(session)： 嘗試獲取本地的session。如果之前曾經(jīng)登錄過，則能獲取到；否則，本地?zé)osession
• wx.login()： 小程序提供的接口，用于獲取code（code有效期為5分鐘）
• wx.request(code)： 將code通過后臺提供的接口，換取session
• wx.setStorage(session)： 將后臺接口返回的session存入到localStorage，以備后續(xù)使用
• wx.request(session)： 真正發(fā)起業(yè)務(wù)請求，請求中帶上session
• parse(data)： 對后臺返回的數(shù)據(jù)進行預(yù)解析，若發(fā)現(xiàn)登錄態(tài)失效，則重新執(zhí)行登錄；若成功，則真正獲取到業(yè)務(wù)數(shù)據(jù)拓展小程序網(wǎng)絡(luò)請求的能力

只要遵循上圖的流程，我們就無需在業(yè)務(wù)邏輯中關(guān)注登錄態(tài)的問題了，相當(dāng)于把登錄態(tài)的管理問題耦合到了發(fā)起網(wǎng)絡(luò)請求當(dāng)中。 一般情況下，我們程序設(shè)計都會遵循模塊解耦的原則，盡可能將模塊顆?；阶钚?。這導(dǎo)致可能有些同學(xué)認(rèn)為模塊耦合不是好事情，但是我認(rèn)為這是要分情況的：

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

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

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

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

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

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

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

我們來看看執(zhí)行上面代碼的DEMO效果： 

可以看到，通過weRequest發(fā)出的請求，將會自動帶上登錄態(tài)參數(shù)。 對應(yīng)的流程為下圖中紅色的指向： 
沒有登錄態(tài)時，自動登錄

那如果當(dāng)前小程序并沒有登錄態(tài)的情況又會如何呢？ 接下來我們來看看本地?zé)o登錄態(tài)情況下的模擬： 

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

接下來我們再來看看，當(dāng)本地儲存的登錄態(tài)過期之后，頁面的行為如何： 

對后臺數(shù)據(jù)進行預(yù)解析之后，發(fā)現(xiàn)登錄態(tài)過期，于是重新執(zhí)行登錄流程，獲取新的session之后，重新發(fā)起請求。 對應(yīng)的流程為下圖中紅色的指向： 
組件的配置項

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

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

小程序?qū)Ρ纫酝腍5，登錄態(tài)管理邏輯要復(fù)雜很多。通過weRequest這個組件，希望能幫助開發(fā)者把更多精力放在業(yè)務(wù)邏輯上，而登錄態(tài)管理問題只需通過一次簡單配置，以后就不用再花精力管理了。FAQ我希望在請求時候，頁面能出現(xiàn)最簡單的loading狀態(tài)，該怎么辦？

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

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

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

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

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

此時，如果接口返回錯誤碼，將觸發(fā)這里定義的fail函數(shù)，且默認(rèn)錯誤彈框?qū)⒉粫霈F(xiàn)。為什么工具在發(fā)起請求之前，不主動去判斷第三方session是否過期，而要通過接口結(jié)果來判斷，這不是浪費了一次請求往返嗎？

每個小程序?qū)τ谧陨砩傻膕ession都有自己的一套管理方案，微信官方也沒有指明一套通用的方案來要求開發(fā)者，僅僅要求了應(yīng)該保證其安全性且不應(yīng)該設(shè)置較長的過期時間。 原文如下：

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

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

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