今天不聊中間層，我們來聊聊中間頁
本文轉(zhuǎn)載自微信公眾號「微醫(yī)大前端技術(shù)」，作者黃琴。轉(zhuǎn)載本文請聯(lián)系微醫(yī)大前端技術(shù)公眾號。
背景
平常代碼編程中我們會碰到一些交互問題 or 團隊間的合作問題，需要處理鏈接跳轉(zhuǎn)之間的問題，假如我們作為提供方，需求方來自不同的業(yè)務團隊，甚至有時來自第三方。當然不僅限于此，還有很多令人腦殼疼的場景，這時候我們可以提供一個中間頁作為對接橋梁，在此頁面去攬下所有對接的活。但針對過渡頁的合理使用和一些注意事項，我這里想單獨拎一篇小文章出來說說，繼續(xù)看看吧。
使用場景
1: 不確定的多方業(yè)務方或者不同渠道業(yè)務方
假如我們作為提供方，會面對不同的業(yè)務方，一部分來自于不同的協(xié)作團隊，一部分來自不同的渠道(微信、小程序、app)，這時候中間頁就該上場了，由它來負責，主要根據(jù) query 參數(shù)去做跳轉(zhuǎn)邏輯處理，負責跳到具體的目標頁 A、B、C 等等。目標頁理應來說只負責該頁面具體的邏輯，不該外攬下其他的臟活，下圖為簡易版場景圖。
思路：在中間頁你可以針對不同的 query 去做處理，目標頁放在 targetUrl，在處理對應的邏輯結(jié)束之后，跳轉(zhuǎn)到目標頁。這時候用戶其實是無感知的，如下是簡易版 code。
注意：我們作為提供方，最好能能提供一個標準模版，例如 appid 專門用來區(qū)分來源，來源的定義盡可能標準化，targetUrl 用來存在跳轉(zhuǎn) url，跳轉(zhuǎn)到中間頁 token 處理，都是需要提前定義好的，這些 query 參數(shù)基本是統(tǒng)一的。so 最好是能對外提供一份對接文檔，注釋盡可能詳細(包括 code 中), 這樣避免自己踩坑(排查問題 or 撕逼。。。我太難了)
- // 這里例舉一個數(shù)組，假如針對 query 需要處理的邏輯
- const fnList = [
- ['appid', 'handleAppid'],
- ['token', 'handleToken'],
- ['payUrl', 'handlePayUrl'],
- ['sourceId', 'handleSourceId'],
- ...
- ];
- mounted() {
- this.handleQuery();
- // 處理完跳轉(zhuǎn)到目標頁志華，跳轉(zhuǎn)到目標頁 target
- if (this.query.target) {
- location.replace(this.query.target);
- }
- },
- // 具體的 handleQuery 操作
- handleQuery() {
- // 這里你可能有一些前置處理
- ......
- // 對 query 進行處理
- fnList.forEach(([key, fn]) => {
- if (this.query[key] && this[fn]) {
- this[fn]();
- }
- });
- },
2: 同一業(yè)務方但有定制化需求的場景
聽起來和第一種場景很像，但是有差啦。假如作為提供方，都是同一個對接方，但走的模式不同，導致后續(xù)業(yè)務流程不一樣。拿圖片中的例子來說，目標頁是根據(jù)類型前置不同的目標頁面，這里 query 的參數(shù)會根據(jù) type 的不同，會攜帶和其 type 對應的業(yè)務參數(shù)，這種提供的目標頁是一樣的，但參數(shù)會依賴業(yè)務自身需求而定。
簡易版 code 如下：
- // 根據(jù) type 類型區(qū)別業(yè)務來源
- checkType(type) {
- return this.query.type === type;
- },
- mounted() {
- // 可能有一些前置操作
- ......
- this.handleQuery();
- },
- // 具體的 handleQuery 操作
- handleQuery() {
- // 這里你可能有一些前置處理
- ......
- // 來自服務包，需要帶上 sourceId 參數(shù)
- if (this.checkType('serverPack')) {
- const newQuery = {
- sourceId: query.sourceId,
- ...
- };
- this.$router.replace({
- name: 'orderServerPackConfirm',
- query: newQuery,
- });
- return;
- }
- // 來自 XXX 的信息，需要將 osTokenId 帶到確認頁
- if (this.checkType('pcDetail')) {
- confirmQuery.osTokenId = this.query.osTokenId;
- }
- // 其他
- .....
- this.$router.replace({
- name: 'orderConfirm',
- query: confirmQuery,
- });
- },
3: 處理跨域請求或參數(shù)需要由接口提供的情況
前面兩種情況不論是 1or2，基本上我們說的是由 query 顯性傳遞，但是也會有部分場景我們可能不再適用，如下
1：參數(shù)過多 or 或者對應的某個參數(shù)值過大不適用 query 的方式傳遞，采用接口調(diào)用方式，由中間頁自行獲取其中必要的參數(shù)即可。
2: A 應用跳到 B 應用，此時兩個應用存在跨域問題，A 需要調(diào)用某接口，內(nèi)容值存在 cookie/storage 中，需要將其內(nèi)容傳送到 B 應用中使用。應對這種情況，可以在跳轉(zhuǎn)到 B 應用的過程中加一個前置跳轉(zhuǎn)中間頁，這時 A 只負責跳轉(zhuǎn)到中間頁，將其調(diào)用的接口入?yún)魅氲街虚g頁，在中間頁去請求接口，這是內(nèi)容值就可以穩(wěn)定存儲在 B 應用中了。
簡易版 code 如下：
- // 校驗 query 需要
- checkQuery(keys = []) {
- return keys.every((key) => !!this.query[key]);
- },
- // 根據(jù) type 類型區(qū)別業(yè)務來源
- checkType(type) {
- return this.query.type === type;
- },
- mounted() {
- // 可能有一些前置操作
- ......
- this.handleQuery();
- },
- // 具體的 handleQuery 操作
- handleQuery() {
- // 這里你可能有一些前置處理
- ......
- // 商詳
- if (this.checkType('detail') && this.checkQuery(['skuId', 'quantity'])) {
- // 接口在中間頁去請求
- data = await this.directBuy({
- skuId: +query.skuId,
- quantity: +query.quantity,
- });
- }
- // 購物車
- if (this.checkType('cart') && this.checkQuery(['shopcartId'])) {
- // 接口在中間頁去請求
- data = await this.submitCart({ shopcartids: JSON.parse(query.shopcartId) });
- }
- // 其他
- .....
- this.$router.replace({
- name: 'orderConfirm',
- query: confirmQuery,
- });
- },
使用中間頁的一些注意點
1: 不要濫用中間頁
中間頁在某些業(yè)務場景下確實能幫我們解決一部分的邏輯抽離問題，至少面對以上幾種場景不用再去擔心某些情況下給哪個業(yè)務方爸爸去提供不同的目標頁，但是我們還是要根據(jù)項目中實際情況去評估使用一個中間頁的必要性，至少我們應該保持著：必要性、業(yè)務耦合度、可擴展性的角度去理性編碼，濫用中間頁后期可能就會出現(xiàn)中間頁到中間頁的跳轉(zhuǎn)(不同開發(fā)可能寫了跳轉(zhuǎn)頁邏輯，已經(jīng)是個公共的頁面)，由于文檔不清晰或者更新不及時等原因，反而可能后期維護性成本更大，這是我們需要注意的一個問題。
2: 對于必要性的中間頁盡量往標準化處理
對于 query 上的公有參數(shù)例如來源 appid，統(tǒng)一好格式 h5 環(huán)境下 : p_h5_XXX， app 渠道下:p_app_XXX， 小程序環(huán)境下:p_miniPorgram_XXX，其他參數(shù)也類似，定義好統(tǒng)一標準
對于 query 上的必要參數(shù)例如目標 targetUrl，若提供的 url 不存在，提供標準化的報錯處理
對于豐富多樣化的參數(shù)來源，有必要的情況下，可放在服務端去處理，對外提供一個可配置化接口
3: 要有安全意識，針對 targetUrl 做好防漏洞處理，避免不可預期的 XSS 攻擊等
中間頁要考慮到 targetUrl 的安全漏洞，尤其是不需要登錄的中間頁，假如黑客發(fā)送某個鏈接，欺騙用戶點擊看起來是公司的福利界面鏈接，誘騙用戶點擊，用戶會毫無防范的點擊跳轉(zhuǎn)至虛假界面，則容易騙取用戶的相關(guān)信息，這是我們需要在加中間頁額外考慮的事情，可以對 targetUrl 加上白名單限制。
總結(jié)
以上就是我在我們項目中使用過的一些中間頁的一些總結(jié)吧，希望碰到有類似業(yè)務的小伙伴一點收獲，當然這只是我目前遇到的一些情況，還有我沒想到和沒涉及到的，歡迎提出你們寶貴的建議，就醬紫吧～
黃琴：一枚前端妹子，愛笑、愛運動、愛音樂、愛旅行
