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

登录注册

自2019年9月1号起，不满足登录规范的小程序审核将无法通过，即那些未事先展示小程序功能的界面，并强制调起微信登录授权的小程序。

所谓规范即指站在用户角度考虑的，那些连界面都没有看到的小程序，进去后就要求登录授权确实有点强迫用户，这种类型的小程序加多反而会让用户反感小程序的使用，无法推进小程序的发展。

在改进后，小程序的几个 TAB 页面如下：

但是这样的改进对开发者来说可能不太友好，不仅仅是产品层面上需要放开至少首页等这些页面作为公共页面，另外接口也需要考虑没有用户信息的情况下返回数据等等。最令开发者真正需要绞尽脑汁的，是那些原本简单粗暴的闪屏页面解决问题的方法现在不再适用了，因此迫切需要全面地改进方法，尤其对于入口落地页面多，分享入口多，模板消息多的小程序来说，那种见缝插针的做法必将为以后埋下巨大的隐患。

我们需要从整体层面上考虑这个问题，它需要满足下面几个极端情况：

落地页多（用户相关的界面也会有）
分享入口多（用户相关的界面也会被分享）
公开界面与私有界面以及共存的情况不确定

与产品事先约定好功能可行性边界是不明智的选择，不如从开始就做到足够大的边界才是明智之举。

其实上面三点都是在说明同一个问题，即用户的登录注册需要足够的方便与灵活。我们不妨来分析一下什么情况下需要用户登录吧？思来想去，简而言之就是需要用户信息的时候，比如这个页面是用户的订单列表，那肯定是需要用户登录之后才能查看到所需信息。有些页面比如展示一些商品列表，如果没有做用户画像及个性化推荐，那么其实是不需要用户信息的，那这个页面可以认为是公开的页面。

公开页面（不需要用户信息，比如首页，活动展示页等）
私有页面（用户订单列表，个人数据等）
混合页面（有无用户信息都可以展示，可能样式上有区别）

可能触发用户登录的情况有：从公开页面切换到私有页面，点击调起注册页面，接口请求需要用户信息调起登录注册界面。我们会通过注册新开辟一个页面，这个方法的优点无需多说，参考很多类似 App 的做法便知。

比如有个签到按钮，新用户进来点击之后，点击签到，这时回去调用 check(...) 方法，其回调的值是 true，表示打开成功；若回调值是 false，表示打开失败，这时可能就会进入注册登录的界面。

在上面这个图中上半部分是签到的流转图，下面是登录检查的流转图，其中的 checkRequest 的功能完成没有在图中展示出来，其实这里还可以做很多拓展，比如是否静默检查，是否强制检查，是否需要注册完成后完善相关信息，是否注册完成后进入下一个页面等等。所有的登录注册相关逻辑都可以进入到这个流程中来，不需要再考虑这个接口调用时用户处于什么状态，不需要考虑这个按钮点击后用户的不同状态如何处理等等，只需要定义目标状态即可。

路由

小程序的路由和 WEB 不同，或者说是经过了高度的封装，然后提供了几个接口：wx.navigateTo、wx.redirectTo、wx.reLaunch、wx.switchTab和 wx.navigateBack。这些接口的使用都非常简单，提供页面的路径就可以跳转到响应的页面，比如：

那么这样的接口有什么不足之处呢？最主要为以下两点：

需要输入页面的路径，当然可以是相对路径，但是还是会觉得不太方便，当页面很多时这种使用方式就非常的低效且容易出错，漏掉一个字符就会出现跳转错误的问题。另外，如果这个页面的目录变了，那么就需要修改所有使用的地方。
当需要带参数跳转时，拼接起来很不方便，尤其是参数较为多的情况时。

要解决上面两个问题其实很简单，使用代理模式，我们重新定义下这几个方法，为页面定义一个清单，并为每个页面起一个别名：

页面清单对象就可以解决路径全为字符串，使用效率低，以及容易出错等问题，而代理方法可以组装参数对象，方便传参提高效率。基于这个原始动机以及设计理念，我们来一步一步完善加强这个自定义路由的功能。

注入到常用对象中

由于使用的是 Taro 框架，正常跳转时使用的是 Taro.navigateTo这样的方法，因此能否将自定义的方法注入到这个对象上呢，那样的话使用起来应该会更加方便。

由于使用的是 TypeScript，所以注入起来不像 JavaScript 那么方便可以直接注入，因为 Taro 的类型上并没有我们自定义的方法。所以第一步新建一个文件 shim.taro.d.ts 放到 src 下，在其中加上如下内容：

这时在使用 Taro 时你会发现可以有提示了，也不会警告了，但是运行时会报方法不存在，那是因为这个仅仅只是声明，并没有实现，因此需要找一个文件实现这些方法，然后在 app.tex 中引入这个文件，这时便可以正常使用了。

增加页面属性

上面说到为每个页面加上别名，列出我们使用的页面的清单，但是仅仅别名太过于简单，于是我们可以为每个页面定义一下页面属性，如下：

如此一来，在通过别名查询页面时，拿到的不再单单是一个页面的地址路径，而是更多关于这个页面的信息。可以扩展很大功能，比如跳转时可以检查当前页面的类型，如果使用 navigate 的方式跳转到了一个 tab 类型的页面那么可以强转为 launch 的方式跳转，这样就不会出现跳转出错的问题。另外可以添加这个页面是否公开页面，或私有页面等信息，来触发用户是否需要登录等，以及这个页面是否需要额外信息才能进入，也是可以在这里配置的。

与登录检查的结合

登录检查有了，路由也有了，刚好页面触发的用户登录注册就可以解决了。场景是这样的，新用户进到一个引导的页面（比如首页，或者其他无需用户登录的页面）时，点击跳转到一个子页面，而子页面是需要用户登录才能访问的，这时想要的逻辑是，如果这个用户已经注册过，那么无感知直接进入，如果未注册，那么就跳转到注册页面，注册完后跳转到子页面。