小編最近在實(shí)現(xiàn)移動(dòng)端列表頁(yè)面顯示的時(shí)候一直在思考如何實(shí)現(xiàn)列表的自動(dòng)更新數(shù)據(jù)，對(duì)于大多數(shù)Native App或者Web App，在列表的底部增加“加載更多”的按鈕也是解決這樣的問(wèn)題一種交互的方式，當(dāng)然，這樣的交互其實(shí)還好，不過(guò)根據(jù)用戶的操作習(xí)慣來(lái)看，似乎滾動(dòng)刷新更多數(shù)據(jù)和下拉刷新當(dāng)前數(shù)據(jù)的操作方式，更符合用戶對(duì)列表分頁(yè)數(shù)據(jù)的讀取習(xí)慣，因此，在這里小編想簡(jiǎn)單的說(shuō)說(shuō)，這次在小編系統(tǒng)中所使用的下拉刷新和滾動(dòng)刷新的實(shí)現(xiàn)方式！

其實(shí)，這種實(shí)現(xiàn)數(shù)據(jù)加載的原理很簡(jiǎn)單

在滾動(dòng)刷新的時(shí)候，需要在列表滾動(dòng)到底部的時(shí)候，觸發(fā)相應(yīng)的回調(diào)函數(shù)，激發(fā)加載更多數(shù)據(jù)

在下拉刷新的時(shí)候，通過(guò)判斷列表的用戶手指離開(kāi)的時(shí)候的偏移量，觸發(fā)相應(yīng)的回調(diào)函數(shù)，激發(fā)數(shù)據(jù)刷新

當(dāng)然，在這里，為什么下拉列表的時(shí)候是激發(fā)數(shù)據(jù)刷新，在列表滾動(dòng)到底部的時(shí)候激發(fā)加載更多數(shù)據(jù)，這既算是交互上的一種優(yōu)化，也是一種用戶習(xí)慣的約定俗成，一般用戶在滾動(dòng)列表的時(shí)候，希望的是看到更多的數(shù)據(jù)；當(dāng)用戶試圖看到已經(jīng)加載的數(shù)據(jù)的新的狀態(tài)時(shí)，用戶會(huì)偏向于下拉刷新這個(gè)列表，這在Native App亦或是Web app中都是大同小異的。

當(dāng)然，這些都不過(guò)是js懶加載技術(shù)的不同實(shí)現(xiàn)方式。

那么，我們先來(lái)看下實(shí)現(xiàn)之后的效果，這也是小編目前在做的一款移動(dòng)端的產(chǎn)品

首先，我們先看下，列表的滾動(dòng)刷新，那么到底如何去判斷列表已經(jīng)滾動(dòng)到了底部呢？

我們先看一個(gè)圖，了解一些基本概念：

這里小編只列舉了我們常用的界面高度和寬度元素，這其中：

clientHeight

內(nèi)容可視區(qū)域的高度，也就是說(shuō)頁(yè)面瀏覽器可以看到內(nèi)容的這個(gè)區(qū)域的高度，但要注意padding是算在內(nèi)的

offsetHeight

在IE6，IE7，IE8以及最新的的FF, Chrome中，在元素上都是offsetHeight = clientHeight + 滾動(dòng)條 + 邊框

scrollHeight

這個(gè)屬性就比較麻煩了,因?yàn)樗鼈冊(cè)诨鸷鶬E下簡(jiǎn)直差太多了..

在火狐下還很好理解,它其實(shí)就是滾動(dòng)條可滾動(dòng)的部分還要加上border的高度還要加上橫向滾動(dòng)條不可用的高度,與clientHeight比起來(lái),多個(gè)border的高度跟橫向滾動(dòng)條不可用的高度.

在IE中 scrollHeight確是指這個(gè)對(duì)象它所包含的對(duì)象的高度加上boder的高度和marging,如果它里面沒(méi)有包含對(duì)象或者這個(gè)對(duì)象的高度值未設(shè)置,那么它的值將為15

那么，在這里，我們會(huì)發(fā)現(xiàn)，當(dāng)scrollTop + offsetHeight >= scrollHeight的時(shí)候，其實(shí)，我們的滾動(dòng)條就已經(jīng)到達(dá)最底部了，那么，滾動(dòng)刷新觸發(fā)的邏輯也就出來(lái)了，那么，這里會(huì)需要這樣幾個(gè)方法，來(lái)獲取不同的高度元素

各個(gè)高度元素的方法有了，接下來(lái)，我們需要有一個(gè)方法去檢查頁(yè)面額滾動(dòng)條是否已經(jīng)到達(dá)了底部，那么，其實(shí)就是執(zhí)行這個(gè)公式的計(jì)算邏輯

那，這里的loadDownFn就是我們的滾動(dòng)刷新的方法，這個(gè)方法也是通過(guò)指令的方式傳遞到這個(gè)組件之中的，這點(diǎn)在接下來(lái)也會(huì)提到。

既然有了檢查滾動(dòng)條滾動(dòng)位置的方法，那如何才能夠激發(fā)這個(gè)方法在用戶滾動(dòng)列表的時(shí)候執(zhí)行呢，那么，我們需要在列表滾動(dòng)的時(shí)候，去激發(fā)檢查方法的執(zhí)行，其實(shí)這里就是對(duì)列表的scroll事件綁定了監(jiān)聽(tīng)器。

那么，在這里，throttle是個(gè)限速器，防止?jié)L動(dòng)條滑懂到底部時(shí)多次激發(fā)刷新函數(shù)

因此我們的滾動(dòng)刷新也就完成了，其實(shí)回頭看看，畢竟JS實(shí)現(xiàn)的代碼會(huì)有一些回調(diào)方法在里面，影響了我們通常的線性思維，但是我們可以發(fā)現(xiàn)，思路還是很清晰的，那接下來(lái)，我們看下下拉刷新的是如何實(shí)現(xiàn)的。

其實(shí)下拉刷新的觸發(fā)邏輯也是很簡(jiǎn)單的，說(shuō)白了，就是在用戶手指接觸屏幕的時(shí)候，捕獲一下列表所在div的一個(gè)高度坐標(biāo)，在用戶手指脫離屏幕的時(shí)候再捕獲一下列表所在div的一個(gè)高度坐標(biāo)，做個(gè)差值判斷一下用戶的執(zhí)行的動(dòng)作是否是摁住該div的一個(gè)拉動(dòng)動(dòng)作（注意：不是滾動(dòng)動(dòng)作哦），從而判斷是否應(yīng)該激發(fā)我們的數(shù)據(jù)刷新方法。

那在這里，我們捕獲用戶的觸屏操作，需要利用到H5的touch事件，這里，我們?cè)俜_(kāi)教科書(shū)看下，H5的touch事件都指的是什么？

觸摸事件(touch)會(huì)在用戶手指放在屏幕上面的時(shí)候、在屏幕上滑動(dòng)的時(shí)候或者是從屏幕上移開(kāi)的時(shí)候觸發(fā)，這其中包括以下幾個(gè)事件：

(on)touchstart：觸摸開(kāi)始的時(shí)候觸發(fā)
(on)touchmove：手指在屏幕上滑動(dòng)的時(shí)候觸發(fā)
(on)touchend：觸摸結(jié)束的時(shí)候觸發(fā)
(on)touchcancel：系統(tǒng)取消touch事件的時(shí)候觸發(fā)。例如電話接入或者彈出信息。一般用在游戲：玩著的時(shí)候，突然來(lái)電話了，就觸發(fā)touchcancel事件暫停游戲、存檔等操作。

那，在這里，小編主要用到了touchstart,touchmove和touchend這三個(gè)事件，分別用來(lái)捕獲用戶的觸屏行為：

在touchmove里面，大家要注意，由于微信中的webview會(huì)存在黑底的問(wèn)題，因此我們拉動(dòng)列表的時(shí)候，會(huì)出現(xiàn)露出微信上方黑底的問(wèn)題，因此，我們需要調(diào)用preventDefault方法，防止事件繼續(xù)向上冒泡，從而防止用戶在拖動(dòng)列表的時(shí)候，微信上方出現(xiàn)黑底，那樣會(huì)十分影響體驗(yàn)。

那接下來(lái)，我們需要做的就是把這些觸摸事件綁定到滾動(dòng)條上就行了：

那么，我們的下拉刷新的主要邏輯也就完成了

當(dāng)然這里，我們也需要提供靈活的方式，能夠動(dòng)態(tài)的去綁定和解綁下拉刷新和滾動(dòng)刷新的方法

最后，因?yàn)槲覀兊目丶](méi)辦法知道我們的數(shù)據(jù)已經(jīng)加載完，因此我們需要提供一個(gè)方法，由外部的數(shù)據(jù)刷新方法調(diào)用結(jié)束后，通知我們的組件，數(shù)據(jù)已經(jīng)加載完，并且重新渲染下拉處或者底部處的樣式：

我們?cè)诮M件中，也建議在vue的nextClick中對(duì)該方法進(jìn)行調(diào)用：

這樣，一個(gè)基本的下拉刷新和滾動(dòng)刷新的指令也就實(shí)現(xiàn)了.

以上所述是小編給大家介紹的基于vue的下拉刷新指令和滾動(dòng)刷新指令，希望對(duì)大家有所幫助，如果大家有任何疑問(wèn)請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持！

最新評(píng)論