用戶
 找回密碼
 立即注冊

QQ登錄

只需一步,快速開始

掃一掃,登錄網站

小程序社區 首頁 資訊/觀點 查看內容

湖人vs凯尔特人抢七:小程序開發的幾個好的實踐

湖人vs爵士季后赛 www.nbgeh.club Rolan 2019-11-27 00:24

作者 | 張鵬前端工程師,關注大前端各種新興技術。隨著互聯網發展格局的千變萬化,小程序從起始的未知發展直至至今所引起的小程序浪潮。正因為小程序的開發愈加成熟,隨之各種框架層出不窮,以至于很多方面需要我們 ...

作者 | 張鵬

前端工程師,關注大前端各種新興技術。

隨著互聯網發展格局的千變萬化,湖人vs爵士季后赛從起始的未知發展直至至今所引起的小程序浪潮。 正因為小程序的開發愈加成熟,隨之各種框架層出不窮,以至于很多方面需要我們不斷摸索和嘗試,很多彎路需要我們親自踏遍從而劈開捷徑,對于功能多,迭代多,入口多的小程序該如何開發? 在本文中我與大家一起探討,我所親歷和感悟的有關小程序最佳實踐的那些事。

登錄注冊

自2019年9月1號起,不滿足登錄規范的小程序審核將無法通過,即那些未事先展示小程序功能的界面,并強制調起微信登錄授權的小程序。

所謂規范即指站在用戶角度考慮的,那些連界面都沒有看到的小程序,進去后就要求登錄授權確實有點強迫用戶,這種類型的小程序加多反而會讓用戶反感小程序的使用,無法推進小程序的發展。

在改進后,小程序的幾個 TAB 頁面如下:

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

我們需要從整體層面上考慮這個問題,它需要滿足下面幾個極端情況:

  • 落地頁多(用戶相關的界面也會有)

  • 分享入口多(用戶相關的界面也會被分享)

  • 公開界面與私有界面以及共存的情況不確定

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

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

  • 公開頁面(不需要用戶信息,比如首頁,活動展示頁等)

  • 私有頁面(用戶訂單列表,個人數據等)

  • 混合頁面(有無用戶信息都可以展示,可能樣式上有區別)

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

比如有個簽到按鈕,新用戶進來點擊之后,點擊簽到,這時回去調用 check(...) 方法,其回調的值是 true,表示打開成功; 若回調值是 false,表示打開失敗,這時可能就會進入注冊登錄的界面。

在上面這個圖中上半部分是簽到的流轉圖,下面是登錄檢查的流轉圖,其中的  checkRequest 的功能完成沒有在圖中展示出來,其實這里還可以做很多拓展,比如是否靜默檢查,是否強制檢查,是否需要注冊完成后完善相關信息,是否注冊完成后進入下一個頁面等等。 所有的登錄注冊相關邏輯都可以進入到這個流程中來,不需要再考慮這個接口調用時用戶處于什么狀態,不需要考慮這個按鈕點擊后用戶的不同狀態如何處理等等,只需要定義目標狀態即可。

路由

小程序的路由和 WEB 不同,或者說是經過了高度的封裝,然后提供了幾個接口: wx.navigateTo 、 wx.redirectTo、 wx.reLaunch、 wx.switchTab 和  wx.navigateBack 。 這些接口的使用都非常簡單,提供頁面的路徑就可以跳轉到響應的頁面,比如:

那么這樣的接口有什么不足之處呢? 最主要為以下兩點:

  1. 需要輸入頁面的路徑,當然可以是相對路徑,但是還是會覺得不太方便,當頁面很多時這種使用方式就非常的低效且容易出錯,漏掉一個字符就會出現跳轉錯誤的問題。 另外,如果這個頁面的目錄變了,那么就需要修改所有使用的地方。

  2. 當需要帶參數跳轉時,拼接起來很不方便,尤其是參數較為多的情況時。

要解決上面兩個問題其實很簡單,使用代理模式,我們重新定義下這幾個方法,為頁面定義一個清單,并為每個頁面起一個別名:

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

注入到常用對象中

由于使用的是 Taro 框架,正常跳轉時使用的是  Taro.navigateTo 這樣的方法,因此能否將自定義的方法注入到這個對象上呢,那樣的話使用起來應該會更加方便。

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

這時在使用 Taro 時你會發現可以有提示了,也不會警告了,但是運行時會報方法不存在,那是因為這個僅僅只是聲明,并沒有實現,因此需要找一個文件實現這些方法,然后在 app.tex 中引入這個文件,這時便可以正常使用了。

增加頁面屬性

上面說到為每個頁面加上別名,列出我們使用的頁面的清單,但是僅僅別名太過于簡單,于是我們可以為每個頁面定義一下頁面屬性,如下:

如此一來,在通過別名查詢頁面時,拿到的不再單單是一個頁面的地址路徑,而是更多關于這個頁面的信息。 可以擴展很大功能,比如跳轉時可以檢查當前頁面的類型,如果使用 navigate 的方式跳轉到了一個 tab 類型的頁面那么可以強轉為 launch 的方式跳轉,這樣就不會出現跳轉出錯的問題。 另外可以添加這個頁面是否公開頁面,或私有頁面等信息,來觸發用戶是否需要登錄等,以及這個頁面是否需要額外信息才能進入,也是可以在這里配置的。

與登錄檢查的結合

登錄檢查有了,路由也有了,剛好頁面觸發的用戶登錄注冊就可以解決了。 場景是這樣的,新用戶進到一個引導的頁面(比如首頁,或者其他無需用戶登錄的頁面)時,點擊跳轉到一個子頁面,而子頁面是需要用戶登錄才能訪問的,這時想要的邏輯是,如果這個用戶已經注冊過,那么無感知直接進入,如果未注冊,那么就跳轉到注冊頁面,注冊完后跳轉到子頁面。

在路由跳轉到目標頁面的時候檢查必要的前提條件,比如登錄狀態,發現用戶并未注冊時則調起登錄注冊頁面,完成后進入目標頁面。 部分代碼如下圖:

閃屏頁面

閃屏其實是不應該存在小程序中的一個頁面,我們從原來的閃屏作為小程序的唯一入口,到現在登錄注冊的改造讓閃屏從小程序中消失做了很多的改造。 從唯一入口變成了多入口,閃屏已經不再需要。 但是有些時候你還是會感覺一個閃屏頁面確實會有其存在的必要性。

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

另外對于普通二維碼這個功能是非常有必要的,因為普通二維碼只能有10個,且每個的落地頁固定,這樣的處理就可以實現無限制的落地頁,并且可以帶很多參數。

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

全文完

鮮花
鮮花 (1)
雞蛋
雞蛋

剛表態過的朋友 (1 人)

分享至 : QQ空間
收藏
原作者: 張鵬 來自: 杏仁技術站
天天真人捕鱼赢话费 山东11选5走势图-前二基本走势 山西快乐10分规则 波克捕鱼达人oppo专区 有没有一款自动赚钱的软件 快乐10分遗漏 金巴黎彩票网址 单机免费打麻将单机版 平码杀肖公式规律 彩票2元网安卓 宁夏11选5中奖规则 安微快三今天预测号码 福建十一选五开奖结果走势图百度乐彩 北京中彩快印连锁 gta5设施可以赚钱吗 青海11选5一定牛