微信小程序之自定义导航

在开始之前呢，先提示一下大家，这里所说的自定义导航指的是底部的tabbar！不要问我为什么，我也不知道。

其实我个人是不推荐自定义tabbar的，但为什么我还是这么去做了呢？主要原因是我们的业务需要根据客群的不同展示不同的tabbar，如果用原生的tabbar是无法实现的。因此我们最后决定通过自定义的方式来实现。 不想看文字也没事，看一下我的示意图你就知道需求了 ...╮(╯_╰)╭

是不是秒懂！:sunglasses:

自定义导航的优劣势

自定义导航最大的优势就是自定义，这不是废话吗...:joy:我总结了以下优势供大家参考:

• 随意组合tab的item成为新的tabbar；
• 可以在导航上的写一些动画；
• 在tabbar的UI上也能够更加自由；
• ......

自定义导航的优势仁者见仁智者见智。可能因为业务的不同，所体现的优势也不一样，我就不在这里掰扯了。

说了这些优势，其实自定义导航的劣势也比较明显：

• 自定义导航需要在每个tab页面进行引入，麻烦。
• 需要自己实现手机的适配。
• 页面切换的时候，会有闪现得情况。
• 必要的时候还需要考虑维护路由。
• ......

实现方案

因为tabbar是一个比较独立的模块，所以可以写成组件的形式，这样子也方便维护。引入组件方法要是不熟悉的话，大家可以看官方的文档。自定义组件

创建组件

目录结构

这里我把组件命名为nav，目录结构如下：

可以看到组件模块的目录结构和普通的page页面没什么区别，当然page页面需要在app.json里边进行引入，但是组件的话是不需要的。

json文件的配置

接下来，我们需要在组件的json文件中配置一下：

{
  "component": true,
  "usingComponents": {}
}
复制代码

其他的就不需要再进行配置了。当然，假如你的组件里边需要引入其他的组件，可以用同样的方式，并且在 "usingComponents": {} 里边引入就行。

wxml的结构

接下来就是wxml文件的书写。这个页面的话就和page页面一样就行了。这里不需要考虑里边的节点数，因为最后小程序会把他们再封装到一个根节点上，所以大家不必要再自己再添加一个根节点。

其他的话，有一个地方可能需要和大家提醒一下， 记得给iPhoneX做一下兼容 ！这里我的tabbar用的是fixed的布局方式，所以 可能会遮住一些元素 。

<view class="nav-placeholder" style="padding-bottom: {{isIpx ? 68 : 0}}rpx;"></view>
复制代码

我解决的方案如上，采用的是一个空白的元素进行占位。

引用组件的时候需要在目标页面的json文件中声明一下：

"usingComponents": {
    "x-nav":"../../",
}
复制代码

然后在模板中直接引用就行了：

<x-nav show="{{true}}" cartcount="{{cartcount}}" catchtouchmove="ture"></x-nav>
复制代码

wxss的结构

这里的样式就不要再具体说明了，因为组件的存在所以里边的类名不会被污染,大家放心的使用，大家可以在里边加各种动画，比如下边这样：

这个只是一个思路，要是我真这么设计，估计明天就会因为鞋带是蝴蝶结的被开除。你们可以让设计做一些高大上的东西出来。

如果你非要用外部的样式的话也可以，但是你自己需要注意类名命名的问题，可以通过声明 options 来实现：

options:{
    addGlobalClass: true
},
复制代码

js的结构

js的结构可能会有一些不一样，因为是组件，所以不再是通过 page({}) 这样子的方式去创建，而会改成 Component({}) 的方式。

其他的写法和vue就比较像了。

props 就变成了 properties ,格式如下：

properties: {
	val1: {
		type: Boolean,
		value: false,
		observer: function(newVal, oldVal) {
			console.log(newVal, oldVal);
		}
	},
	val2: {
		type: String,
		value: '0',
		observer: function(newVal, oldVal) {
			console.log(newVal, oldVal);
		}
	},
	...
},
复制代码

properties 中假如你传入的值可能会是不同类型的你可以换成 optionalTypes ，这个是支持多类型的

data的话就没必要细说了，小程序的组件里边依然支持 getApp() 的方法，假如你有什么方法写在app.js中也是可以直接调用的。

在这里边我会用到 show() 方法，组件中使用 onShow() 这种带on的生命周期是有一些特别的，如下:

pageLifetimes:{
	show(){
            consolelog('show');
	},
	hide(){
            consolelog('hide');
	},
	resize(){
            consolelog('hide');
	},
},
复制代码

不带on的话是写在另外一个对象中的 lifetimes:{} ：

lifetimes: {
    attached() {
      // 在组件实例进入页面节点树时执行
    },
    detached() {
      // 在组件实例被从页面节点树移除时执行
    },
    created() {
      // 在组件实例刚刚被创建的时候
    },
    ready() {
      // 在组件在视图层布局完成后执行
    },
    moved() {
      // 在组件实例被移动到节点树另一个位置时执行
    },
    error() {
      // 每当组件方法抛出错误时执行
    }
  },
复制代码

这里可能会有同学有疑问这个 lifetimes里的方法为什么可以写在外边 ，其实 写在外边的是旧式的定义方式 ，可以保持对 <2.2.3> 版本基础库的兼容。

其他的地方有一个 navList:[] 这个就是导航tab的list了，格式的话，推荐大家可以模仿原生的格式：

navList: [
	{
		name:'***', //nav的名称
		url:'****', //跳转的地址
		actived:true, //是否选中状态
		nomalImg:'***', //不被选中时的icon
		activedImg:'***', //被选中的icon
		type:'***' //导航类型
	},
	{
		name:'***',
		url:'***',
		actived:false,
		nomalImg:'***',
		activedImg:'***',
		type:'***'
	},
	{
		name:'***',
		url:'***',
		actived:false,
		nomalImg:'***',
		activedImg:'***',
		type:'***'
	}
],
复制代码

这里的话大家可以优化一下，因为当时写的比较急，再总结的时候发现好多地方可以优化。比如这个 navList 大家可以改为对象的模式，因为在 getCurrentPages() 中的路径其实也是 /pages/.... 这样子的格式，大家可以把路径作为key，这样就不需要每次change的时候都去遍历一次数组，妈耶，当时我怎么就没这么写...:sob:

还有一点思路可以供给大家作为参考，因为我们在切换tab的时候需要把 actived 的 状态进行修改 ，这个修改我们可以 不用去过多的去考虑切换的过程 ，因为原生的切换是使用 wx.switchTab 的方式进行切换，我们自定义导航的话也可以模仿这个方式去做，我们可以 用 wx.redirectTo 来代替 ,因为用的是redirect，所以我们在判断路由的时候比较方便，直接取路由中的第一个来进行判断就行了。

其实说到路由栈，有一个比较麻烦的地方就是，当这个tab页面变成一个常规的页面时(就是可以通过navigate的方式访问)，我们的访问路径就会复杂起来，举个例子吧：

假如你通过点击tab进行切换页面的时候，这个是正常情况，但是假如你从别的页面访问的时候这个路由的长度可能就会大于1，这个时候你就需要对路由进行更加细致的检查了。

其他的话，我遇到的问题就是背景中提到的 根据客群的不同展示不同的tabbar 。

这个的问题点在于，我们 获取用户客群信息的时候是个异步的过程 ，当请求回来的时候会有一个 比较明显的变换过程 ，可能导航就会从三个变成四个，这个的话，目前的我的方案没有完全避免，因为我不可能等到请求回来的时候再显示导航条吧，所以我会 把用户第一次请求的结果记录下来 ，之后的话会优先取缓存中的数据，这样 除了用户第一次回变换一次，之后的话就不会出现闪烁的情况 。