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