随着互聯網發展格局的千變萬化，小程序從(cóng)起始的未知發展直至至今所引起的小程序浪潮。正因爲小程序的開發愈加成熟，随之各種框架層出不窮，以至于很多方面需要我們不斷摸索和嘗試，很多彎路(lù)需要我們親自(zì)踏遍從(cóng)而劈開捷徑，對于功能多，叠代多，入口多的小程序該如(rú)何開發？在本文中我與大(dà)家一起探討(tǎo)，我所親曆和感悟的有關小程序最佳實踐的那些事(shì)。

登錄注冊

自(zì)2019年(nián)9月1号起，不滿足登錄規範的小程序審核将無法通過，即那些未事(shì)先展示小程序功能的界面，并強制調起微信登錄授權的小程序。

所謂規範即指站(zhàn)在用戶角度考慮的，那些連界面都(dōu)沒有看(kàn)到的小程序，進去(qù)後就(jiù)要求登錄授權确實有點強迫用戶，這種類型的小程序加多反而會讓用戶反感小程序的使用，無法推進小程序的發展。

在改進後，小程序的幾個 TAB 頁面如(rú)下：

 

但(dàn)是這樣的改進對開發者來(lái)說(shuō)可(kě)能不太友好，不僅僅是産品層面上需要放(fàng)開至少首頁等這些頁面作(zuò)爲公共頁面，另外接口也需要考慮沒有用戶信息的情況下返回數據等等。最令開發者真正需要絞盡腦汁的，是那些原本簡單粗暴的閃屏頁面解決問(wèn)題的方法現在不再适用了，因此迫切需要全面地改進方法，尤其對于入口落地頁面多，分(fēn)享入口多，模闆消息多的小程序來(lái)說(shuō)，那種見(jiàn)縫插針的做法必将爲以後埋下巨大(dà)的隐患。

我們需要從(cóng)整體(tǐ)層面上考慮這個問(wèn)題，它需要滿足下面幾個極端情況：

• 落地頁多（用戶相(xiàng)關的界面也會有）
• 分(fēn)享入口多（用戶相(xiàng)關的界面也會被分(fēn)享）
• 公開界面與私有界面以及共存的情況不确定

與産品事(shì)先約定好功能可(kě)行性邊界是不明智的選擇，不如(rú)從(cóng)開始就(jiù)做到足夠大(dà)的邊界才是明智之舉。

其實上面三點都(dōu)是在說(shuō)明同一個問(wèn)題，即用戶的登錄注冊需要足夠的方便與靈活。我們不妨來(lái)分(fēn)析一下什麽情況下需要用戶登錄吧(ba)？思來(lái)想去(qù)，簡而言之就(jiù)是需要用戶信息的時候，比如(rú)這個頁面是用戶的訂單列表，那肯定是需要用戶登錄之後才能查看(kàn)到所需信息。有些頁面比如(rú)展示一些商品列表，如(rú)果沒有做用戶畫(huà)像及個性化推薦，那麽其實是不需要用戶信息的，那這個頁面可(kě)以認爲是公開的頁面。

• 公開頁面（不需要用戶信息，比如(rú)首頁，活動展示頁等）
• 私有頁面（用戶訂單列表，個人(rén)數據等）
• 混合頁面（有無用戶信息都(dōu)可(kě)以展示，可(kě)能樣式上有區别）

可(kě)能觸發用戶登錄的情況有：從(cóng)公開頁面切換到私有頁面，點擊調起注冊頁面，接口請(qǐng)求需要用戶信息調起登錄注冊界面。我們會通過注冊新開辟一個頁面，這個方法的優點無需多說(shuō)，參考很多類似 App 的做法便知。

比如(rú)有個簽到按鈕，新用戶進來(lái)點擊之後，點擊簽到，這時回去(qù)調用 check(...) 方法，其回調的值是 true，表示打開成功；若回調值是 false，表示打開失敗，這時可(kě)能就(jiù)會進入注冊登錄的界面。

 

在上面這個圖中上半部分(fēn)是簽到的流轉圖，下面是登錄檢查的流轉圖，其中的 checkRequest 的功能完成沒有在圖中展示出來(lái)，其實這裡(lǐ)還(hái)可(kě)以做很多拓展，比如(rú)是否靜(jìng)默檢查，是否強制檢查，是否需要注冊完成後完善相(xiàng)關信息，是否注冊完成後進入下一個頁面等等。所有的登錄注冊相(xiàng)關邏輯都(dōu)可(kě)以進入到這個流程中來(lái)，不需要再考慮這個接口調用時用戶處于什麽狀态，不需要考慮這個按鈕點擊後用戶的不同狀态如(rú)何處理(lǐ)等等，隻需要定義目标狀态即可(kě)。

路(lù)由

小程序的路(lù)由和 WEB 不同，或者說(shuō)是經過了高度的封裝，然後提供了幾個接口：wx.navigateTo、wx.redirectTo、wx.reLaunch、wx.switchTab和 wx.navigateBack。這些接口的使用都(dōu)非常簡單，提供頁面的路(lù)徑就(jiù)可(kě)以跳(tiào)轉到響應的頁面，比如(rú)：

 

那麽這樣的接口有什麽不足之處呢(ne)？最主要爲以下兩點：

1. 需要輸入頁面的路(lù)徑，當然可(kě)以是相(xiàng)對路(lù)徑，但(dàn)是還(hái)是會覺得(de)不太方便，當頁面很多時這種使用方式就(jiù)非常的低效且容易出錯，漏掉一個字符就(jiù)會出現跳(tiào)轉錯誤的問(wèn)題。另外，如(rú)果這個頁面的目錄變了，那麽就(jiù)需要修改所有使用的地方。
2. 當需要帶參數跳(tiào)轉時，拼接起來(lái)很不方便，尤其是參數較爲多的情況時。

要解決上面兩個問(wèn)題其實很簡單，使用代理(lǐ)模式，我們重新定義下這幾個方法，爲頁面定義一個清單，并爲每個頁面起一個别名：

 

頁面清單對象就(jiù)可(kě)以解決路(lù)徑全爲字符串，使用效率低，以及容易出錯等問(wèn)題，而代理(lǐ)方法可(kě)以組裝參數對象，方便傳參提高效率。基于這個原始動機以及設計(jì)理(lǐ)念，我們來(lái)一步一步完善加強這個自(zì)定義路(lù)由的功能。

注入到常用對象中

由于使用的是 Taro 框架，正常跳(tiào)轉時使用的是 Taro.navigateTo這樣的方法，因此能否将自(zì)定義的方法注入到這個對象上呢(ne)，那樣的話(huà)使用起來(lái)應該會更加方便。

由于使用的是 TypeScript，所以注入起來(lái)不像 JavaScript 那麽方便可(kě)以直接注入，因爲 Taro 的類型上并沒有我們自(zì)定義的方法。所以第一步新建一個文件(jiàn) shim.taro.d.ts 放(fàng)到 src 下，在其中加上如(rú)下内容：

 

這時在使用 Taro 時你(nǐ)會發現可(kě)以有提示了，也不會警告了，但(dàn)是運行時會報方法不存在，那是因爲這個僅僅隻是聲明，并沒有實現，因此需要找一個文件(jiàn)實現這些方法，然後在 app.tex 中引入這個文件(jiàn)，這時便可(kě)以正常使用了。

增加頁面屬性

上面說(shuō)到爲每個頁面加上别名，列出我們使用的頁面的清單，但(dàn)是僅僅别名太過于簡單，于是我們可(kě)以爲每個頁面定義一下頁面屬性，如(rú)下：

 

如(rú)此一來(lái)，在通過别名查詢頁面時，拿到的不再單單是一個頁面的地址路(lù)徑，而是更多關于這個頁面的信息。可(kě)以擴展很大(dà)功能，比如(rú)跳(tiào)轉時可(kě)以檢查當前頁面的類型，如(rú)果使用 navigate 的方式跳(tiào)轉到了一個 tab 類型的頁面那麽可(kě)以強轉爲 launch 的方式跳(tiào)轉，這樣就(jiù)不會出現跳(tiào)轉出錯的問(wèn)題。另外可(kě)以添加這個頁面是否公開頁面，或私有頁面等信息，來(lái)觸發用戶是否需要登錄等，以及這個頁面是否需要額外信息才能進入，也是可(kě)以在這裡(lǐ)配置的。

與登錄檢查的結合

登錄檢查有了，路(lù)由也有了，剛好頁面觸發的用戶登錄注冊就(jiù)可(kě)以解決了。場景是這樣的，新用戶進到一個引導的頁面（比如(rú)首頁，或者其他(tā)無需用戶登錄的頁面）時，點擊跳(tiào)轉到一個子頁面，而子頁面是需要用戶登錄才能訪問(wèn)的，這時想要的邏輯是，如(rú)果這個用戶已經注冊過，那麽無感知直接進入，如(rú)果未注冊，那麽就(jiù)跳(tiào)轉到注冊頁面，注冊完後跳(tiào)轉到子頁面。

 

在路(lù)由跳(tiào)轉到目标頁面的時候檢查必要的前提條件(jiàn)，比如(rú)登錄狀态，發現用戶并未注冊時則調起登錄注冊頁面，完成後進入目标頁面。部分(fēn)代碼如(rú)下圖：

 

閃屏頁面

閃屏其實是不應該存在小程序中的一個頁面，我們從(cóng)原來(lái)的閃屏作(zuò)爲小程序的唯一入口，到現在登錄注冊的改造讓閃屏從(cóng)小程序中消失做了很多的改造。從(cóng)唯一入口變成了多入口，閃屏已經不再需要。但(dàn)是有些時候你(nǐ)還(hái)是會感覺一個閃屏頁面确實會有其存在的必要性。

 

如(rú)上所示，如(rú)果我們加入了閃屏頁面，可(kě)以作(zuò)爲統一的外部落地頁，可(kě)以根據頁面的别名再做跳(tiào)轉，然後直接使用了前面自(zì)定義的路(lù)由功能。

另外對于普通二維碼這個功能是非常有必要的，因爲普通二維碼隻能有10個，且每個的落地頁固定，這樣的處理(lǐ)就(jiù)可(kě)以實現無限制的落地頁，并且可(kě)以帶很多參數。

 

綜上所述，代碼部分(fēn)其實也是很簡單的，處理(lǐ)兩種類型的參數即可(kě)。有一個值得(de)推薦的做法，結合自(zì)定義路(lù)由是很好的處理(lǐ)方式。另外還(hái)有一個較好的實踐就(jiù)是将參數展開，比如(rú)目标頁面的參數，其實是帶在入口頁面上的，然後由入口頁面結合自(zì)定義路(lù)由轉發到目标頁面，而不是直接帶在目标頁面上。