背景
在开始之前呢,先提示一下大家,这里所说的自定义导航指的是底部的tabbar!不要问我为什么,我也不知道。
其实我个人是不推荐自定义tabbar的,但为什么我还是这么去做了呢?主要原因是我们的业务需要根据客群的不同展示不同的tabbar,如果用原生的tabbar是无法实现的。因此我们最后决定通过自定义的方式来实现。不想看文字也没事,看一下我的示意图你就知道需求了...╮(╯_╰)╭
是不是秒懂!
自定义导航的优劣势
自定义导航最大的优势就是自定义,这不是废话吗... 我总结了以下优势供大家参考:
- 随意组合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的时候都去遍历一次数组,妈耶,当时我怎么就没这么写...
还有一点思路可以供给大家作为参考,因为我们在切换tab的时候需要把actived
的状态进行修改,这个修改我们可以不用去过多的去考虑切换的过程,因为原生的切换是使用wx.switchTab
的方式进行切换,我们自定义导航的话也可以模仿这个方式去做,我们可以用wx.redirectTo
来代替,因为用的是redirect,所以我们在判断路由的时候比较方便,直接取路由中的第一个来进行判断就行了。
其实说到路由栈,有一个比较麻烦的地方就是,当这个tab页面变成一个常规的页面时(就是可以通过navigate的方式访问),我们的访问路径就会复杂起来,举个例子吧:
假如你通过点击tab进行切换页面的时候,这个是正常情况,但是假如你从别的页面访问的时候这个路由的长度可能就会大于1,这个时候你就需要对路由进行更加细致的检查了。
其他的话,我遇到的问题就是背景中提到的根据客群的不同展示不同的tabbar。
这个的问题点在于,我们获取用户客群信息的时候是个异步的过程,当请求回来的时候会有一个比较明显的变换过程,可能导航就会从三个变成四个,这个的话,目前的我的方案没有完全避免,因为我不可能等到请求回来的时候再显示导航条吧,所以我会把用户第一次请求的结果记录下来,之后的话会优先取缓存中的数据,这样除了用户第一次回变换一次,之后的话就不会出现闪烁的情况。
总结
大家在可以使用小程序原生的tabbar的时候就用原生的,因为原生的体验上会更好一些。当然,如果不得不用自定义导航的时候不如就好好设计一下,充分发挥自定义导航的优势。要是大家有什么别的想法,欢迎大家在底下留言,同时也欢迎大家加我微信交流:zyf348519452,交个朋友也很好啊