一个简洁、有趣的无限下拉方案
作者：網(wǎng)易云音樂前端團(tuán)隊
https://juejin.im/post/5de5baf2518825235b095cbe
本文主旨
長列表渲染、無限下拉也算是前端開發(fā)老生常談的問題之一了，本文將介紹一種簡潔、巧妙、高效的方式來實現(xiàn)。話不多說，看下圖，也許你可以發(fā)現(xiàn)什么？
不知你是否從上面這張圖中注意到了什么，比如只是渲染了可視區(qū)域的部分 DOM?，滾動過程中只是外層容器的 padding 在改變？
前一點(diǎn)很好理解，我們考慮到性能，不可能將一個長列表（甚至是一個無限下拉列表）的所有列表元素都進(jìn)行渲染；而后一點(diǎn)，則是本文所介紹方案的核心之一！
不賣關(guān)子，提前告訴你該方案的要素就是兩個：
Interp Observer
padding
說明了要素，也許你可以嘗試著開始思考，看你是否能猜到具體的實現(xiàn)方案。
方案介紹
Interp Observer
基本概念
一直以來，檢測元素的可視狀態(tài)或者兩個元素的相對可視狀態(tài)都不是件容易事。傳統(tǒng)的各種方案不但復(fù)雜，而且性能成本很高，比如需要監(jiān)聽滾動事件，然后查詢 DOM , 獲取元素高度、位置，計算距離視窗高度等等。
這就是 Interp Observer 要解決的問題。它為開發(fā)人員提供一種便捷的新方法來異步查詢元素相對于其他元素或視窗的位置，消除了昂貴的 DOM 查詢和樣式讀取成本。
兼容性
主要在 Safari 上兼容性較差，需要 12.2 及以上才兼容，不過還好，有 polyfill 可食用。
一些應(yīng)用場景
頁面滾動時的懶加載實現(xiàn)。
無限下拉（本文的實現(xiàn)）。
監(jiān)測某些廣告元素的曝光情況來做相關(guān)數(shù)據(jù)統(tǒng)計。
監(jiān)測用戶的滾動行為是否到達(dá)了目標(biāo)位置來實現(xiàn)一些交互邏輯（比如視頻元素滾動到隱藏位置時暫停播放）。
padding 方案實現(xiàn)
基本了解 Interp Observer 之后，接下來就看下如何用 Interp Observer + padding 來實現(xiàn)無限下拉。
先概覽下總體思路：
監(jiān)聽一個固定長度列表的首尾元素是否進(jìn)入視窗；
更新當(dāng)前頁面內(nèi)渲染的第一個元素對應(yīng)的序號；
根據(jù)上述序號，獲取目標(biāo)數(shù)據(jù)元素，列表內(nèi)容重新渲染成對應(yīng)內(nèi)容；
容器 padding 調(diào)整，模擬滾動實現(xiàn)。
核心：利用父元素的 padding 去填充隨著無限下拉而本該有的、越來越多的 DOM 元素，僅僅保留視窗區(qū)域上下一定數(shù)量的 DOM 元素來進(jìn)行數(shù)據(jù)渲染。
1、監(jiān)聽一個固定長度列表的首尾元素是否進(jìn)入視窗
// 觀察者創(chuàng)建 this.observer = new InterpObserver(callback, options);// 觀察列表第一個以及最后一個元素 this.observer.observe(this.firstItem); this.observer.observe(this.lastItem); 復(fù)制代碼我們以在頁面中渲染固定的 20 個列表元素為例，我們對第一個元素和最后一個元素，用 Interp Observer 進(jìn)行觀察，當(dāng)他們其中一個重新進(jìn)入視窗時，callback 函數(shù)就會觸發(fā)：
const callback = (entries) => {entries.forEach((entry) => {if (entry.target.id === firstItemId) {// 當(dāng)?shù)谝粋€元素進(jìn)入視窗} else if (entry.target.id === lastItemId) {// 當(dāng)最后一個元素進(jìn)入視窗}}); }; 復(fù)制代碼2、更新當(dāng)前頁面渲染的第一個元素對應(yīng)的序號 (firstIndex)
拿具體例子來說明，我們用一個數(shù)組來維護(hù)需要渲染到頁面中的數(shù)據(jù)。數(shù)組的長度會隨著不斷請求新的數(shù)據(jù)而不斷變大，而渲染的始終是其中一定數(shù)量的元素，比如 20 個。那么：
1、最開始渲染的是數(shù)組中序號為 0 - 19 的元素，即此時對應(yīng)的 firstIndex 為 0；
2、當(dāng)序號為 19 的元素（即上一步的 lastItem ）進(jìn)入視窗時，我們就會往后渲染 10 個元素，即渲染序號為 10 - 29 的元素，那么此時的 firstIndex 為 10；
3、下一次就是，當(dāng)序號為 29 的元素進(jìn)入視窗時，繼續(xù)往后渲染 10個元素，即渲染序號為 20 - 39 的元素，那么此時的 firstIndex 為 20，以此類推。。。
總體來說，更新 firstIndex，是為了根據(jù)頁面的滾動情況，知道接下來哪些數(shù)據(jù)應(yīng)該被獲取、渲染。
3、根據(jù)上述序號，獲取對應(yīng)數(shù)據(jù)元素，列表重新渲染成新的內(nèi)容
const renderFunction = (firstIndex) => {// offset = firstIndex, limit = 10 => getData// getData Done => new dataItems => render DOM}; 復(fù)制代碼這一部分就是根據(jù) firstIndex 查詢數(shù)據(jù)，然后將目標(biāo)數(shù)據(jù)渲染到頁面上即可。
4、padding 調(diào)整，模擬滾動實現(xiàn)
既然數(shù)據(jù)的更新以及 DOM 元素的更新我們已經(jīng)實現(xiàn)了，那么無限下拉的效果以及滾動的體驗，我們要如何實現(xiàn)呢？
想象一下，拋開一切，最原始最直接最粗暴的方式無非就是我們再又獲取了 10 個新的數(shù)據(jù)元素之后，再塞 10 個新的 DOM 元素到頁面中去來渲染這些數(shù)據(jù)。
但此時，對比上面這個粗暴的方案，我們的方案是：這 10個新的數(shù)據(jù)元素，我們用原來已有的 DOM 元素去渲染，替換掉已經(jīng)離開視窗、不可見的數(shù)據(jù)元素；而本該由更多 DOM 元素進(jìn)一步撐開容器高度的部分，我們用 padding 填充來模擬實現(xiàn)。
向下滾動
向上滾動
最后是 padding 設(shè)置更新以及相關(guān)緩存數(shù)據(jù)更新
思考總結(jié)
方案總結(jié)：
利用 Interp Observer 來監(jiān)測相關(guān)元素的滾動位置，異步監(jiān)聽，盡可能得減少 DOM 操作，觸發(fā)回調(diào)，然后去獲取新的數(shù)據(jù)來更新頁面元素，并且用調(diào)整容器 padding 來替代了本該越來越多的 DOM 元素，最終實現(xiàn)列表滾動、無限下拉。
相關(guān)方案的對比
這里和較為有名的庫 - iScroll 實現(xiàn)的無限下拉方案進(jìn)行一個基本的對比，對比之前先說明下 iScroll infinite 的實現(xiàn)概要：
iScroll 通過對傳統(tǒng)滾動事件的監(jiān)聽，獲取滾動距離，然后：
設(shè)置父元素的 translate 來實現(xiàn)整體內(nèi)容的上移（下移）；
再基于這個滾動距離進(jìn)行相應(yīng)計算，得知相應(yīng)子元素已經(jīng)被滾動到視窗外，并且判斷是否應(yīng)該將這些離開視窗的子元素移動到末尾，從而再對它們進(jìn)行 translate 的設(shè)置來移動到末尾。這就像是一個循環(huán)隊列一樣，隨著滾動的進(jìn)行，頂部元素先出視窗，但又將移動到末尾，從而實現(xiàn)無限下拉。
相關(guān)對比：
實現(xiàn)對比：一個是 Interp Observer 的監(jiān)聽，來通知子元素離開視窗，只要定量設(shè)置父元素 padding 就行；另一個是對傳統(tǒng)滾動事件的監(jiān)聽，滾動距離的獲取，再進(jìn)行一系列計算，去設(shè)置父元素以及子元素的 translate。顯而易見，前者看起來更加簡潔明了一些。
性能對比：我知道說到對比，你腦海中肯定一下子會想到性能問題。其實性能對比的關(guān)鍵就是 Interp Observer。因為單就 padding 設(shè)置還是 translate 設(shè)置，性能方面的差距是甚小的，只是個人感覺 padding 會簡潔些？而 Interp Observer 其實抽離了所有滾動層面的相關(guān)邏輯，你不再需要對滾動距離等相應(yīng) DOM 屬性進(jìn)行獲取，也不再需要進(jìn)行一系列滾動距離相關(guān)的復(fù)雜計算，并且同步的滾動事件觸發(fā)變成異步的，你也不再需要另外去做防抖之類的邏輯，這在性能方面還是有所提升的。
存在的缺陷：
padding 的計算依賴列表項固定的高度。
這是一個同步渲染的方案，也就是目前容器 padding 的計算調(diào)整，無法計算異步獲取的數(shù)據(jù)，只跟用戶的滾動行為有關(guān)。這看起來與實際業(yè)務(wù)場景有些不符。解決思路：
思路 1、利用 Skeleton Screen Loading 來同步渲染數(shù)據(jù)元素，不受數(shù)據(jù)異步獲取的影響。即在數(shù)據(jù)請求還未完成時，先使用一些圖片進(jìn)行占位，待內(nèi)容加載完成之后再進(jìn)行替換。
思路 2、滾動到目標(biāo)位置，阻塞容器 padding 的設(shè)置（即無限下拉的發(fā)生）直至數(shù)據(jù)請求完畢，用 loading gif 提示用戶加載狀態(tài)，但這個方案相對復(fù)雜，你需要全面考慮用戶難以預(yù)測的滾動行為來設(shè)置容器的 padding。
延伸拓展
請大家思考一下，無限下拉有了，那么無限上拉基于這種方案要如何調(diào)整實現(xiàn)呢？
如果將 Interp Observer 用到 iScroll 里面去，原有方案可以怎樣優(yōu)化？
代碼實現(xiàn)
完整代碼實現(xiàn)參考(https://github.com/Guohjia/listScroll)
參考文章
Interp Observer API
InterpObserver’s Coming into View
Infinite Scroll’ing the right way
總結(jié)
以上是生活随笔為你收集整理的一个简洁、有趣的无限下拉方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Flutter 1.17 | 2020
- 下一篇： 分析 HTTP，TCP 的长连接和短连接