登錄時(shí)序圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

接下來(lái)我們?cè)賮?lái)看看，當(dāng)本地儲(chǔ)存的登錄態(tài)過(guò)期之后，頁(yè)面的行為如何： 

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

weRequest提供一個(gè)init方法，用于對(duì)組件的配置，以下展示所有的配置項(xiàng)：

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

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

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

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

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

只需要在請(qǐng)求的時(shí)候，加上參數(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);
    }
})

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

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

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

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

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