用户
 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,登录网站

小程序社区 首页 资讯/观点 查看内容

小程序开发的几个好的实践

Rolan 2019-11-27 00:24

作者 | 张鹏前端工程师,关注大前端各种新兴技术。随着互联网发展格局的千变万化,小程序从起始的未知发展直至至今所引起的小程序浪潮。正因为小程序的开发愈加成熟,随之各种框架层出不穷,以至于很多方面需要我们 ...

作者 | 张鹏

前端工程师,关注大前端各种新兴技术。

随着互联网发展格局的千变万化,小程序从起始的未知发展直至至今所引起的小程序浪潮。 正因为小程序的开发愈加成熟,随之各种框架层出不穷,以至于很多方面需要我们不断摸索和尝试,很多弯路需要我们亲自踏遍从而劈开捷径,对于功能多,迭代多,入口多的小程序该如何开发? 在本文中我与大家一起探讨,我所亲历和感悟的有关小程序最佳实践的那些事。

登录注册

自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空间
收藏
原作者: 张鹏 来自: 杏仁技术站