「不吹不黑」說一說列表頁多"簡單"

前言

相信隨着前端職業的興起，有很多後端或者項目經理以爲前端不就那麼回事麼？甚至於有些時候，後端一看這麼個簡單的東西也要作一天？那麼本文就帶你們瞭解一下一個還算正常的手機列表頁須要那些工做量。

入口

分析列表頁首先要看入口，由於一個好的列表頁確定是可複用的，入口的不一樣將致使列表的數據展現不一樣以及處理的不一樣。

作過不止一次從不一樣入口到同一個列表頁，但展現倒是不一樣的，這裏多是由於業務不一樣，多是由於權限不一樣，多是由於歷史操做不一樣。那麼你的入口邏輯就要區分下了，區分不一樣的入口致使的差異，以及首次和非首次進入的區別。

也有一種特殊處理，就是當是列表頁進入詳情再返回列表的時候，須要記憶上一步列表的狀態。對於app是很簡單的事情也許，但對於前端就須要記錄比較多的關鍵點了。可能包括：用戶的過濾選擇，關鍵字，請求到的分頁信息，請求到的緩存數據，滾動到的位置。對，很明確行業是有明確的方案的，但注意我這裏是說的工做量，有這部分需求就須要去實現，去細化，以及測試的。

返回

列表進來了，我不想看，返回了個人入口頁面。這裏也有很重要的邏輯判斷。大部分人以爲返回不就是返回上一個頁面麼。有時候的確能夠如此考慮，但要看你的頁面流是什麼。

相信不少人知道頁面歷史記錄，在pc端你能夠經過多入口很方便的進入到任何一個可操做性的業務入口，可是手機端只能經過返回、關閉以及指定的主頁或者其餘按鈕脫離本頁面。

曾經深度研究過網易雲音樂app的播放頁。它能夠是不少頁面點擊進來的，每種不一樣渠道的進入，在音樂播放頁返回都要返回指定的頁而不是簡單的歷史記錄頁。因此不要簡單的認爲手機端的返回就和瀏覽器的返回前進是同樣的。當你的應用須要的時候，這個返回邏輯能夠包含不一樣的業務判斷。

也有些邏輯是藉助於返回進行的，好比離開頁面的風險提示，讓你確認操做而後再離開。而有的返回只是當前頁某些展現的去掉。

常規列表支持的交互

全量列表 && 分頁列表

雖然都是列表，但實際上有不少時候咱們的列表數據卻多是總量肯定的，可能涉及到某我的某個業務的數據量的時候，就只有不到一屏，或者最多兩頁，那這種時候，其實全量列表對於用戶來講是最合適最友好的，而對於全量列表也就不存在加載更多或者沒有更多的狀況了。

底部上拉加載 && 無限滾動加載

底部上拉是比較常規的交互方式，如今比較經常使用的是無限滾動加載直到沒有數據可加載。

下拉刷新 && 頂部雙擊刷新

下拉刷新是比較常規的交互方式，不過已經愈來愈少用了。如今更多的是頂部雙擊能夠同時達到快速回到頂部而且刷新的做用，對微信朋友圈的交互就是這樣的。

沒有數據 && 沒有更多數據

這兩點是徹底不一樣的頁面展現，而對於沒有數據在特定場景下都有特定的含義。

好比有些狀況下，產品須要作一些指引，須要在沒有數據的時候引導用戶，你能夠經過新建數據從而有數據，或者是由於你缺乏某些操做、資質之類的緣由致使你沒有數據能夠看。

也有意外狀況是由於你的弱網，斷網環境致使了你的沒有數據。還有一些異常狀況也會致使，而針對異常狀況是否作單獨說明也是須要和產品確認的點。好比服務器網關報錯引發的或者程序員開小差了。

而沒有更多數據，其展現也愈來愈趨於簡單，正經的文案多是寫，沒有更多數據了，調皮一點的會寫我是有底線的。

當沒有更多數據的時候，做爲性能交互優化的角度，也須要在邏輯判斷上取消其請求數據的部分，甚至取消上拉自己的邏輯操做。

分頁的頁數

做爲分頁的常規邏輯，須要清除的知道每次請求的準確頁數。我能夠簡單分享下本身的邏輯，假設用戶是初始狀態進入的，那麼默認pageNo是1，當觸發的時候去請求第二頁麼？不，不是這樣的。

在你請求有數據拿到第一頁的時候，其實你就知道總條數以及總頁數了。因此在每一次數據請求以前，就能夠經過比較pageNo與pageTotal的關係來決定加載觸發操做的時候是否有必要請求下一頁的數據，其是否還有下一頁。

實際上，當咱們的當前的pageNo == pageTotal的時候，已經不用請求了；

小於的時候，就須要請求，對應的加載動畫，請求接口，取消動畫。而後將頁數加1 以後，進行從新的判斷，若是發現此時，等於了就要下面顯示沒有更多數據；若是仍是小於就能夠仍然觸發其加載操做。

特別的是，須要你們注意當原本就只有一頁數據的時候，你就要顯示出沒有更多數據了。這種狀況基本都會被忽略，由於通常狀況下好像生產環境的列表數據不會這麼少，而致使測試或者開發測不到這種異常狀況的。

加載動畫

就是咱們常說的loading圖，不少交互會認爲你不加這個就交互很差呢。我本身的觀點是看你接口的請求時間以及對應的操做內是否有數據可看。

具體例子說明下：好比上面提到的無限滾動加載，其實大多數時候，咱們是看不到其無限滾動加載的觸發動畫的，由於其會定義在當你舉例底部還有50-100px的時候，就已經去請求數據了，其加載交互在你沒看到的底部位置，快的話1s-2s就把下面的數據請求並渲染好了，這樣反而是體驗好的。但若是你的設置是讓其閃現1s出現加載框而後消失那才尷尬呢。那麼，爲何開始進來的時候須要加載動畫是中央的loading呢，由於此時你沒有數據可看。

相似的例子還出如今列表項上支持的某些操做，當你點擊請求服務器進行功能的時候，其實你關注點是功能的執行結果，而不是繼續看數據，也不想丟失這部分的操做，而在產品設計的角度，也會盡可能減小此時其餘的沒必要要操做，因此纔會有這樣一個交互，告知用戶我在處理你的請求裏，請稍等。一則是友好，二則避免用戶重複點擊，形成服務器沒必要要的負擔，以及一些後端邏輯處理上多高併發的問題瓶頸，還有就是多請求多返回的衝突提示。

列表項騷操做

左滑 && 右滑

項目的滑動能夠展現更多操做或者信息。也有一些列表在切換類型的tab部分是經過滑動的，而也有列表是經過頁面滑動切換列表的。慢慢的這種切換列表的方式會變爲主流。

拖拽

不少時候會遇到列表的拖拽來調整順序，從而達到來調整你的優先級或者喜歡程度等。

雙擊

雙擊進行的操做會比較少，但慢慢的也會充當爲手機手勢經常使用的一種。

搜索功能

搜索範圍

目前的搜索有不少種類型，有本地搜索，有遠程搜索。本地搜索指的是以顯示的列表中進行關鍵字過濾，不用請求接口；而遠程搜索則是根據關鍵字進行遠程搜索。

搜索觸發條件

隨着前端交互的增長，觸發條件也增長了不少，簡單分爲如下幾種：

• 動態搜索，每當輸入發生變化的時候
• 離開焦點的時候
• 輸入法回車的時候
• 點擊其後面的搜索按鈕
• 搜索圖標

搜索幫助

作的好的產品會針對以前搜索過的結果進行搜素記錄提示，這個提示是個性化的，動態根據歷史記錄更新的。能夠輸入部分後再提供的聯想搜索結果中進行選擇從而搜索。

搜索與常規展現矛盾點

這裏簡單講下搜索與常規展現的邏輯處理，以搜索頁和常規列表頁爲一個頁面考慮。

搜索列表與常規列表關係

若是你的搜索請求接口和常規列表接口是同一個，通常狀況下都是同一個，當進行搜索的時候，獲得有效關鍵字以後，請求數據，須要將頁數重置爲1，須要提供關鍵字， 獲得搜索結果以後，須要判斷其是否有數據，其展現的沒有數據和常規列表的沒有數據提示是不同的，不同在你須要告訴用戶：1 搜索的關鍵字是什麼 2 是搜索無結果，區別於常規的無結果。

而當你將關鍵字去掉，切換爲常規列表的時候，須要把關鍵字去空，頁數也重置爲1 。這裏也延伸的拓展下，若是你還涉及到多個tab列表的切換，那麼你的tab可能就是對應到不一樣的type值的傳參，這部分也須要根據對應的部分進行重置。甚至於你可能須要同時進行幾種狀態的記憶管理，這是很常見的需求。

搜索列表是否和常規列表做爲同一個頁面

對於這種交互是打問號的，自從有第一個產品在搜索框點擊打開新頁面以後，搜索頁單獨打開頁面就變成了app交互的一種不成文的習慣。

列表中的懶加載

小談圖片

列表中的圖片如今都要支持必定的懶加載，在雲音樂的處理中都是開始是默認圖，而後是實際縮略圖代替。

縮略圖規則，通常都是按照比例排版的縮略圖。不知道你們有沒有研究過微信的縮略圖，它可不是簡單的把原圖尺寸用那麼小的尺寸顯示那樣簡單。縮略圖涉及到的點這裏稍微列舉下：

1 縮略圖的列表佔比，主要做用 2 縮略圖通常不是原圖，但有必定的轉換關係。在阿里的圖牀中會根據你穿的圖片提供至少3中規格的正方形縮略圖讓你進行選擇規格。 3 顯示的內容，通常狀況下都是原圖內容的100%展示，但若是原圖寬比不符合縮略圖的長寬比，很常見的把，那麼就會把原圖中間的百分之多少截圖做爲縮略圖展現的部分。 4 控制原圖的比例，固然更多時候爲了保證產品的統一，可能會控制原圖的比例。但若是業務自己是控制不了的，或者原本就不但願控制，也不用控制的。

小談骨架屏

第一次感覺到骨架屏是簡書的用戶體驗，初次感受沒特別的，再反過來對比的時候，發現這樣的體驗好不少。相信骨架屏會是頁面懶加載技術以後，前端體驗優化又一個必備必現的技術點。

其核心體驗是：先出輪廓，再詳細渲染。

總結

其實這裏僅僅列舉了一個手機列表頁的部分邏輯，尚未列舉完整，到這裏你還以爲作一個列表是很簡單的事情麼，其實若是從沒有很成熟的經驗開始作的話，也沒有那麼容易，須要考慮比較多的事情吧，畢竟列表頁是承載不少業務展示形式的載體。

若是你以爲本文還不錯，加個喜歡，沒有主講代碼技術，但滿滿的前端邏輯。