在最近的微信小程序开发中,遇到一个比较坑的界面开发,说坑并不是因为它难,而是这其中包括了太多的开发时所要填的坑了,今天准备将这些填完的小坑一个个刨出来仔细啃啃,做一个demo分享一下。

需求分析

简单梳理一下需求:1.tabbar 需要用 fixed来跟随 2.需要有上拉刷新,下拉加载的功能

需求很简单,看起来一个个都不是很困难,但其中隐约的藏着许多个小坑洼,需要一个个仔细的来填上。首先先进个需求,position:fixed; 直接实现,不存在任何困难。

实现方法

紧接着面对上拉刷新、下拉加载这个功能,老生常谈,主要有两个实现的方式:

1.scroll-view的上下监听函数,在触顶和触底时分别执行上拉刷新和下拉刷新机制。

2.微信api自带的onReachBottom 和 onPullDownFresh 两个函数,分别为触底执行和下拉刷新。

先来介绍一下两种方法:

1.利用scroll-view 来放置列表展示页,将产品列表贴在scroll-view上,利用下滑属性可以将产品展示在其中。在scroll-view触底时, 绑定bindtaplower 这个函数将会被触发,达到“下拉刷新”的效果。

2.利用page标签自带的onReachBottom 来达到下拉加载,上拉刷新。两个api属于自带的api,而这个的上拉刷新也自带了一个刷新动画。

两种方法均有其特点和优异之处。从个人的开发喜好来说,在单列表中,第二种方式,即OnReachBottom 和 onPullDownFresh 的方式是优于先进种方式的。为什么呢?因为它自带了一个下拉刷新的动画。而用scroll-view 的上拉刷新是不带这个动画的。所以谁更加先进不言而喻啦。

那么,我们应该如何合适的使用这两种方案?

微信小程序是一种很简单的前端程序,但是它其中蕴含了许多的大大小小的坑。比如:在scroll-view 的碰边函数上,会出现碰触执行多次的问题,即触底执行的判定过于多次,导致其疯狂触发函数。

面临这样的bug,我的先进想法是给他们上个锁。每当函数执行时将锁关上,在函数之行结束之时再将锁打开。这样就可以将函数重复执行的问题解决了。

·上拉加载的函数·

upper: function() {
    var that = this
    var timestamp = Date.parse(new Date()) / 1000;
    var lastTime = this.data.lastLoadTime
    if (timestamp - lastTime < 5) {
        console.log('太快了')
    } else {
        that.setData({ lastLoadTime: timestamp })
        if (this.data.pullUpAllow) {
            console.log('刷新啦')
            that.setData({
                pullUpAllow: false
            })
            wx.showNavigationBarLoading() //在标题栏中显示加载
            console.log(that.data.classidnow)
            wx.request({
                url: '…',//这里放置的是接口的地址
                method: 'POST',
                data: {
                    shopid: getApp().globalData.shopid,
                    classid: that.data.classidnow,
                    userid: getApp().globalData.userid
                },
                header: {
                    'content-type': 'application/json' // 默认值
                },
                success: function(res) {
                    console.log(res)
                    if (res.data.data.length != 0) {
                        let shoppingDetail = res.data.data
                        that.setData({
                            shopping: shoppingDetail,
                            showNowData: false
                        })
                        console.log(that.data.shopping)
                    } else {
                        that.setData({
                            shopping: shoppingDetail,
                            showNowData: true
                        })
                    }
                },
                complete: function() {
                    wx.hideNavigationBarLoading() //完成停止加载
                    wx.stopPullDownRefresh() //停止下拉刷新
                    setInterval(() => {
                        that.setData({
                            pullUpAllow: true
                        })
                    }, 1000)
                }
            })
        }
    }
}

虽然可以解决下拉刷新触发过多的问题,但因为上拉刷新的硬伤,所以我认为,在能使用onReachBottom的情况下,不要去使用scroll-view来写。因为上拉加载时,用

Scroll-viewl动画提示用户在下拉刷新时,用的是showNavigationBarLoading()这个api,他做到的是在标题上加入一个旋转的小动画。但是使用这个api时,会产生的一个问题就是,如果在上拉加载时不放手时,还是会疯狂触发上拉刷新的bug,这是后标题会疯狂鬼畜的抖动。这时候,我想到的解决方案是给上拉再次加入一个时间锁。在三秒之内,再次触发刷新时,禁止它的触发。而自带的onReachBottom 将不会再触发这类问题,因为它要真真实实的上拉,所以综上所述,如果能用onReachBottom ,辣就不要用scroll-view来写上拉刷新啦,因为真的没那么好用的。

如果你以为这就结束了?

上一段说了,如果如果能用onReachBottom ,就用这个,那么什么情况下不能用呢?这就关系到一开始说的需求了,需求上是关系到一个需要position:fixed的属性的。那么,我们就要面临一个问题了。如果用的是view 标签,在拉到1/2 时,做tab切换,时候就面临一个问题:它的切换并不会切到顶部,而出现的也是在刷新之后的1/2处,这个体验非常不人性化。那么,在面对需要置顶的情况下,view的使用就会面临一个瓶颈了。如何让view置顶?这是个问题。

我的解决方案是:scroll-view 在每次切换时,让scrollTop行内标签归零,这样就可以让每次切换置顶了。而因为scrolltop一开始就为0,先进次的上拉刷新是不会触发的。在这样的场景下,目前还是用scroll-view 来的更为简便。