ios10 小程序自定义tabbar不显示_微信小程序之自定义导航

本文介绍了微信小程序中自定义tabbar的需求背景,分析了自定义导航的优劣势,并详细阐述了创建组件的实现方案,包括目录结构、json、wxml、wxss和js的配置。此外,还讨论了自定义导航在页面切换、路由管理和用户客群显示差异等方面的挑战及应对策略。
摘要由CSDN通过智能技术生成

背景

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

99fe6ffff8b6ae9318cd7cb0d495702b.png

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

47f6577296c98485aeb7e73d12662ab4.png

44e52ee6fcf25992b59b903c14c6c6da.png

是不是秒懂!

0ce3fa23dbc0d5888f5e5890155df3b3.png

自定义导航的优劣势

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

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

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

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

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

实现方案

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

2eaa8ca082fc897f434bcd83e836348e.png

创建组件

目录结构

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

23e017bc4744379f6db75fcb3123761c.png

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

json文件的配置

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

{
  "component": true,
  "usingComponents": {}
}

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

wxml的结构

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

2f32d32089de254ace4ab5407c9fdf28.png

其他的话,有一个地方可能需要和大家提醒一下,记得给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的结构

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

214fbded1f192926cb78a035e6724776.gif

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

afb8a58c37b8a17e1092a8648a3f6540.png

如果你非要用外部的样式的话也可以,但是你自己需要注意类名命名的问题,可以通过声明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的时候都去遍历一次数组,妈耶,当时我怎么就没这么写...

1c875d10ba836bbe7076729feda08b20.png

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

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

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

7d27c35f37b775a1af4d3cfcd5faffc3.png

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

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

总结

大家在可以使用小程序原生的tabbar的时候就用原生的,因为原生的体验上会更好一些。当然,如果不得不用自定义导航的时候不如就好好设计一下,充分发挥自定义导航的优势。要是大家有什么别的想法,欢迎大家在底下留言,同时也欢迎大家加我微信交流:zyf348519452,交个朋友也很好啊

813e1d6b2d7075c0ec63819e0b7f610d.png
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值