小程序開發(fā)的幾個(gè)好的實(shí)踐

隨著互聯(lián)網(wǎng)發(fā)展格局的千變?nèi)f化，小程序從起始的未知發(fā)展直至至今所引起的小程序浪潮。正因?yàn)?a target="_blank">小程序的開發(fā)愈加成熟，隨之各種框架層出不窮，以至于很多方面需要我們不斷摸索和嘗試，很多彎路需要我們親自踏遍從而劈開捷徑，對(duì)于功能多，迭代多，入口多的小程序該如何開發(fā)？在本文中我與大家一起探討，我所親歷和感悟的有關(guān)小程序好實(shí)踐的那些事。

登錄注冊(cè)

自2019年9月1號(hào)起，不滿足登錄規(guī)范的小程序審核將無法通過，即那些未事先展示小程序功能的界面，并強(qiáng)制調(diào)起微信登錄授權(quán)的小程序。

所謂規(guī)范即指站在用戶角度考慮的，那些連界面都沒有看到的小程序，進(jìn)去后就要求登錄授權(quán)確實(shí)有點(diǎn)強(qiáng)迫用戶，這種類型的小程序加多反而會(huì)讓用戶反感小程序的使用，無法推進(jìn)小程序的發(fā)展。

在改進(jìn)后，小程序的幾個(gè) TAB 頁面如下：

但是這樣的改進(jìn)對(duì)開發(fā)者來說可能不太友好，不僅僅是產(chǎn)品層面上需要放開至少首頁等這些頁面作為公共頁面，另外接口也需要考慮沒有用戶信息的情況下返回?cái)?shù)據(jù)等等。最令開發(fā)者真正需要絞盡腦汁的，是那些原本簡(jiǎn)單粗暴的閃屏頁面解決問題的方法現(xiàn)在不再適用了，因此迫切需要全面地改進(jìn)方法，尤其對(duì)于入口落地頁面多，分享入口多，模板消息多的小程序來說，那種見縫插針的做法必將為以后埋下巨大的隱患。

我們需要從整體層面上考慮這個(gè)問題，它需要滿足下面幾個(gè)極端情況：

• 落地頁多（用戶相關(guān)的界面也會(huì)有）
• 分享入口多（用戶相關(guān)的界面也會(huì)被分享）
• 公開界面與私有界面以及共存的情況不確定

與產(chǎn)品事先約定好功能可行性邊界是不明智的選擇，不如從開始就做到足夠大的邊界才是明智之舉。

其實(shí)上面三點(diǎn)都是在說明同一個(gè)問題，即用戶的登錄注冊(cè)需要足夠的方便與靈活。我們不妨來分析一下什么情況下需要用戶登錄吧？思來想去，簡(jiǎn)而言之就是需要用戶信息的時(shí)候，比如這個(gè)頁面是用戶的訂單列表，那肯定是需要用戶登錄之后才能查看到所需信息。有些頁面比如展示一些商品列表，如果沒有做用戶畫像及個(gè)性化推薦，那么其實(shí)是不需要用戶信息的，那這個(gè)頁面可以認(rèn)為是公開的頁面。

• 公開頁面（不需要用戶信息，比如首頁，活動(dòng)展示頁等）
• 私有頁面（用戶訂單列表，個(gè)人數(shù)據(jù)等）
• 混合頁面（有無用戶信息都可以展示，可能樣式上有區(qū)別）

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

比如有個(gè)簽到按鈕，新用戶進(jìn)來點(diǎn)擊之后，點(diǎn)擊簽到，這時(shí)回去調(diào)用 check(...) 方法，其回調(diào)的值是 true，表示打開成功；若回調(diào)值是 false，表示打開失敗，這時(shí)可能就會(huì)進(jìn)入注冊(cè)登錄的界面。

在上面這個(gè)圖中上半部分是簽到的流轉(zhuǎn)圖，下面是登錄檢查的流轉(zhuǎn)圖，其中的 checkRequest 的功能完成沒有在圖中展示出來，其實(shí)這里還可以做很多拓展，比如是否靜默檢查，是否強(qiáng)制檢查，是否需要注冊(cè)完成后完善相關(guān)信息，是否注冊(cè)完成后進(jìn)入下一個(gè)頁面等等。所有的登錄注冊(cè)相關(guān)邏輯都可以進(jìn)入到這個(gè)流程中來，不需要再考慮這個(gè)接口調(diào)用時(shí)用戶處于什么狀態(tài)，不需要考慮這個(gè)按鈕點(diǎn)擊后用戶的不同狀態(tài)如何處理等等，只需要定義目標(biāo)狀態(tài)即可。

路由

小程序的路由和 WEB 不同，或者說是經(jīng)過了高度的封裝，然后提供了幾個(gè)接口：wx.navigateTo、wx.redirectTo、wx.reLaunch、wx.switchTab和 wx.navigateBack。這些接口的使用都非常簡(jiǎn)單，提供頁面的路徑就可以跳轉(zhuǎn)到響應(yīng)的頁面，比如：

那么這樣的接口有什么不足之處呢？最主要為以下兩點(diǎn)：

1. 需要輸入頁面的路徑，當(dāng)然可以是相對(duì)路徑，但是還是會(huì)覺得不太方便，當(dāng)頁面很多時(shí)這種使用方式就非常的低效且容易出錯(cuò)，漏掉一個(gè)字符就會(huì)出現(xiàn)跳轉(zhuǎn)錯(cuò)誤的問題。另外，如果這個(gè)頁面的目錄變了，那么就需要修改所有使用的地方。
2. 當(dāng)需要帶參數(shù)跳轉(zhuǎn)時(shí)，拼接起來很不方便，尤其是參數(shù)較為多的情況時(shí)。

要解決上面兩個(gè)問題其實(shí)很簡(jiǎn)單，使用代理模式，我們重新定義下這幾個(gè)方法，為頁面定義一個(gè)清單，并為每個(gè)頁面起一個(gè)別名：

頁面清單對(duì)象就可以解決路徑全為字符串，使用效率低，以及容易出錯(cuò)等問題，而代理方法可以組裝參數(shù)對(duì)象，方便傳參提高效率。基于這個(gè)原始動(dòng)機(jī)以及設(shè)計(jì)理念，我們來一步一步完善加強(qiáng)這個(gè)自定義路由的功能。

注入到常用對(duì)象中

由于使用的是 Taro 框架，正常跳轉(zhuǎn)時(shí)使用的是 Taro.navigateTo這樣的方法，因此能否將自定義的方法注入到這個(gè)對(duì)象上呢，那樣的話使用起來應(yīng)該會(huì)更加方便。

由于使用的是 TypeScript，所以注入起來不像 JavaScript 那么方便可以直接注入，因?yàn)?Taro 的類型上并沒有我們自定義的方法。所以第一步新建一個(gè)文件 shim.taro.d.ts 放到 src 下，在其中加上如下內(nèi)容：

這時(shí)在使用 Taro 時(shí)你會(huì)發(fā)現(xiàn)可以有提示了，也不會(huì)警告了，但是運(yùn)行時(shí)會(huì)報(bào)方法不存在，那是因?yàn)檫@個(gè)僅僅只是聲明，并沒有實(shí)現(xiàn)，因此需要找一個(gè)文件實(shí)現(xiàn)這些方法，然后在 app.tex 中引入這個(gè)文件，這時(shí)便可以正常使用了。

增加頁面屬性

上面說到為每個(gè)頁面加上別名，列出我們使用的頁面的清單，但是僅僅別名太過于簡(jiǎn)單，于是我們可以為每個(gè)頁面定義一下頁面屬性，如下：

如此一來，在通過別名查詢頁面時(shí)，拿到的不再單單是一個(gè)頁面的地址路徑，而是更多關(guān)于這個(gè)頁面的信息。可以擴(kuò)展很大功能，比如跳轉(zhuǎn)時(shí)可以檢查當(dāng)前頁面的類型，如果使用 navigate 的方式跳轉(zhuǎn)到了一個(gè) tab 類型的頁面那么可以強(qiáng)轉(zhuǎn)為 launch 的方式跳轉(zhuǎn)，這樣就不會(huì)出現(xiàn)跳轉(zhuǎn)出錯(cuò)的問題。另外可以添加這個(gè)頁面是否公開頁面，或私有頁面等信息，來觸發(fā)用戶是否需要登錄等，以及這個(gè)頁面是否需要額外信息才能進(jìn)入，也是可以在這里配置的。

與登錄檢查的結(jié)合

登錄檢查有了，路由也有了，剛好頁面觸發(fā)的用戶登錄注冊(cè)就可以解決了。場(chǎng)景是這樣的，新用戶進(jìn)到一個(gè)引導(dǎo)的頁面（比如首頁，或者其他無需用戶登錄的頁面）時(shí)，點(diǎn)擊跳轉(zhuǎn)到一個(gè)子頁面，而子頁面是需要用戶登錄才能訪問的，這時(shí)想要的邏輯是，如果這個(gè)用戶已經(jīng)注冊(cè)過，那么無感知直接進(jìn)入，如果未注冊(cè)，那么就跳轉(zhuǎn)到注冊(cè)頁面，注冊(cè)完后跳轉(zhuǎn)到子頁面。

在路由跳轉(zhuǎn)到目標(biāo)頁面的時(shí)候檢查必要的前提條件，比如登錄狀態(tài)，發(fā)現(xiàn)用戶并未注冊(cè)時(shí)則調(diào)起登錄注冊(cè)頁面，完成后進(jìn)入目標(biāo)頁面。部分代碼如下圖：

閃屏頁面

閃屏其實(shí)是不應(yīng)該存在小程序中的一個(gè)頁面，我們從原來的閃屏作為小程序的唯一入口，到現(xiàn)在登錄注冊(cè)的改造讓閃屏從小程序中消失做了很多的改造。從唯一入口變成了多入口，閃屏已經(jīng)不再需要。但是有些時(shí)候你還是會(huì)感覺一個(gè)閃屏頁面確實(shí)會(huì)有其存在的必要性。

如上所示，如果我們加入了閃屏頁面，可以作為統(tǒng)一的外部落地頁，可以根據(jù)頁面的別名再做跳轉(zhuǎn)，然后直接使用了前面自定義的路由功能。

另外對(duì)于普通二維碼這個(gè)功能是非常有必要的，因?yàn)槠胀ǘS碼只能有10個(gè)，且每個(gè)的落地頁固定，這樣的處理就可以實(shí)現(xiàn)無限制的落地頁，并且可以帶很多參數(shù)。

綜上所述，代碼部分其實(shí)也是很簡(jiǎn)單的，處理兩種類型的參數(shù)即可。有一個(gè)值得推薦的做法，結(jié)合自定義路由是很好的處理方式。另外還有一個(gè)較好的實(shí)踐就是將參數(shù)展開，比如目標(biāo)頁面的參數(shù)，其實(shí)是帶在入口頁面上的，然后由入口頁面結(jié)合自定義路由轉(zhuǎn)發(fā)到目標(biāo)頁面，而不是直接帶在目標(biāo)頁面上。

文章名稱：小程序開發(fā)的幾個(gè)好的實(shí)踐
轉(zhuǎn)載來源：http://www.muchs.cn/news27/98227.html

網(wǎng)站建設(shè)、網(wǎng)絡(luò)推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網(wǎng)站制作，網(wǎng)絡(luò)營銷seo公司；服務(wù)項(xiàng)目有小程序開發(fā)等

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)