在微信小程序開(kāi)發(fā)中實(shí)現(xiàn)下拉刷新最簡(jiǎn)單的方式就是在頁(yè)面對(duì)應(yīng)的json文件中添加enablePullDownRefresh:true，然后在Page.onPullDownRefresh
方法中執(zhí)行刷新邏輯。這種方式有一些局限性，一是無(wú)法自定義下拉刷新效果，只能使用默認(rèn)的“三個(gè)圓點(diǎn)”樣式；二是下拉刷新的視圖位置是固定在頂部的，如果要刷新的視圖元素不是位于頁(yè)面頂部，那么使用這種方式就不太好了，最常見(jiàn)的場(chǎng)景就是頂部Tab標(biāo)簽欄，下面是要刷新的列表。在小程序基礎(chǔ)庫(kù)版本2.10.1之后，scroll-view支持自定義下拉刷新了，很好地解決了上述的兩個(gè)問(wèn)題，缺點(diǎn)當(dāng)然就是兼容性了。于是想著自己實(shí)現(xiàn)一個(gè)下拉刷新組件，由于我本身是做Android開(kāi)發(fā)的，所以嘗試實(shí)現(xiàn)了一個(gè)仿Material
Design風(fēng)格的下拉刷新效果（Android中的SwipeRefeshLayout），先附上一張效果圖：
雖然沒(méi)能做到百分之百的還原，不過(guò)基本功能還是實(shí)現(xiàn)了的。相關(guān)代碼我已經(jīng)上傳到了github。
使用方式
將組件拷貝到項(xiàng)目中，在頁(yè)面的json文件中引入，這里就不展示了。組件可設(shè)置的屬性如下：
此外，組件還定義了一個(gè)setRefresh()函數(shù)，用于設(shè)置刷新?tīng)顟B(tài)，參數(shù)傳入一個(gè)布爾值，true表示開(kāi)始刷新，顯示下拉刷新圓圈；false表示結(jié)束刷新，隱藏下拉刷新圓圈。
示例代碼如下：
index.wxml
<swipe-refresh-layout id='refresh' style='width:100vw;height:200rpx;'
loadMoreEnable bindrefresh='refresh' bindloadmore='loadMore'>
<!-- 要刷新的內(nèi)容 -->
</swipe-refresh-layout>
index.js
Page({
/**
* 頁(yè)面的初始數(shù)據(jù)
*/
data: {},
/**
* 生命周期函數(shù)--監(jiān)聽(tīng)頁(yè)面加載
*/
onLoad: function(options) {
this.swipeRefresh = this.selectComponent('#refresh');
},
/**
* 下拉刷新
*/
refresh: function() {
// 模擬獲取數(shù)據(jù)
setTimeout(() => {
// 結(jié)束下拉刷新
this.swipeRefresh.setRefresh(false);
}, 3000);
},
/**
* 上拉加載
*/
loadMore: function() {
// ...
}
})
需要注意，使用時(shí)必須給swipe-refresh-layout組件一個(gè)固定的寬度和高度。
實(shí)現(xiàn)原理
實(shí)現(xiàn)原理還是比較簡(jiǎn)單的，大體上就是通過(guò)監(jiān)聽(tīng)觸摸事件，在touchstart事件回調(diào)中記錄手指按下的坐標(biāo)；在touchmove事件回調(diào)中計(jì)算手指在豎直方向上的滑動(dòng)距離，通過(guò)css的transform屬性實(shí)現(xiàn)下拉刷新圓圈的移動(dòng)；在touchend事件回調(diào)中計(jì)算手指抬起時(shí)的滑動(dòng)距離，如果向下的滑動(dòng)距離超過(guò)閾值就觸發(fā)下拉刷新事件，否則將下拉刷新圓圈歸位。由于在滑動(dòng)的過(guò)程中需要頻繁地進(jìn)行用戶交互，出于性能方面的考慮，我使用了WXS函數(shù)用來(lái)響應(yīng)觸摸事件，將事件定義在視圖層，解決視圖層和邏輯層間通信耗時(shí)的問(wèn)題。
雖然整體的實(shí)現(xiàn)邏輯不難理解，但是在開(kāi)發(fā)過(guò)程中我還是遇到了幾個(gè)問(wèn)題，這里簡(jiǎn)單介紹一下。
touchmove導(dǎo)致的卡頓問(wèn)題
一開(kāi)始我使用的是bindtouchmove屬性監(jiān)聽(tīng)手指滑動(dòng)事件，在開(kāi)發(fā)工具上測(cè)試時(shí)沒(méi)有什么問(wèn)題，后來(lái)運(yùn)行在安卓真機(jī)上才發(fā)現(xiàn)手指觸摸屏幕下拉時(shí)刷新圓圈的移動(dòng)比較卡頓，不流暢。在微信開(kāi)放社區(qū)查了一下這個(gè)問(wèn)題，發(fā)現(xiàn)也有人遇到過(guò)，目前的解決方案就是將bindtouchmove改為catchtouchmove。具體原因還不清楚，可能是官方的bug吧，又或者小程序本身就是這樣設(shè)計(jì)的。改為catchtouchmove后確實(shí)是解決了下拉卡頓的問(wèn)題，但是同時(shí)會(huì)導(dǎo)致頁(yè)面內(nèi)容無(wú)法滑動(dòng)，如何解決這個(gè)問(wèn)題呢，我們不妨考慮一下具體的使用場(chǎng)景，正常情況下只有在頁(yè)面內(nèi)容處于頂部時(shí)才可以下拉刷新，可以利用這個(gè)條件來(lái)判斷是否需要我們自己處理touchmove事件。具體的做法是這樣的，首先在組件最外層使用scroll-view，通過(guò)bindscroll監(jiān)聽(tīng)滑動(dòng)事件：
_scroll: function(e) {
if (e.detail.scrollTop <= 50) {
// 滾動(dòng)到頂部
this.setData({
scrollTop: true
});
} else {
this.setData({
scrollTop: false
});
}
}
使用一個(gè)變量scrollTop來(lái)記錄是否滑動(dòng)到了頂部，這里的判斷條件為什么是e.detail.scrollTop <=
50而不是e.detail.scrollTop <=
0呢，因?yàn)橥ㄟ^(guò)測(cè)試我發(fā)現(xiàn)有時(shí)頁(yè)面滑動(dòng)到頂部時(shí)e.detail.scrollTop的值并不是0，而是一個(gè)接近0的整數(shù)，為了保證每次頁(yè)面滑動(dòng)到頂部都能改變scrollTop的狀態(tài)，這里就給了一個(gè)默認(rèn)值，取50是因?yàn)楣俜轿臋n上給出的默認(rèn)閾值就是50。
之后在catchtouchmove回調(diào)函數(shù)中根據(jù)scrollTop的值判斷是否需要處理滑動(dòng)事件，如果scrollTop的值為false（頁(yè)面內(nèi)容不處位于頂部）就直接return。
touchmove: function(e) {
if (!this.data.scrollTop) {
return;
}
// 處理滑動(dòng)事件
}
這樣就解決了頁(yè)面內(nèi)容始終無(wú)法滾動(dòng)的問(wèn)題，當(dāng)然上面的代碼只是簡(jiǎn)單地說(shuō)明解決方法，詳細(xì)內(nèi)容可以參考組件的源碼。
下拉刷新圓圈的顯示層級(jí)問(wèn)題
正常情況下下拉刷新圓圈是位于要刷新的內(nèi)容之上的，并且不會(huì)隨著內(nèi)容的滑動(dòng)而移動(dòng)，我們很容易就想到使用position:fixed屬性，通過(guò)z-index屬性來(lái)設(shè)置元素的層疊順序。但是如果下拉刷新圓圈的z-index指定一個(gè)大于0的數(shù)，而刷新組件又不是位于頁(yè)面的頂部，就會(huì)導(dǎo)致下拉刷新圓圈始終會(huì)顯示出來(lái)，如下圖所示：
我這里采取的解決方案就是將下拉刷新圓圈的z-index指定為-1，而刷新內(nèi)容的z-index指定為-2（取值不是固定的，只要比下拉刷新圓圈的小就可以），這樣就可以解決下拉刷新圓圈覆蓋在頁(yè)面普通視圖之上的問(wèn)題。當(dāng)然我的解決方案可能不是最好的，或者存在一些問(wèn)題，如果大家有自己的想法歡迎提出，一起交流。