參考美團、餓了麼 && localStorage

時間 2019-11-11

標籤參考餓了 localstorage 简体版

原文原文鏈接

localStorage使用。

爲何要使用 localStorage？

由於在以前的討論過程當中，問題：每次添加一件商品和去掉一個商品都須要發送一個http請求來更新購物車，目的是爲了在用戶下次登陸的時候能夠記得購物車裏的內容，這樣，若是用戶選了以後即便沒有付款，可是下次登陸的時候仍然一打開頁面咱們就能夠把localStorage中的內容顯示出來，這樣，用戶體驗會更好一些，好比 餓了麼在小程序上的作法就是這樣，可是美團不是，美團並無保存購物車中的內容，而餓了麼保存了，之因此能夠判斷使用的時localStorage，是由於咱們在斷網的狀況下他也能夠記錄。

之因此可用，是由於在兼容性上也不存在問題，支持IE8，Android2.1（幾乎是全部的了）、以及iOS3，因此兼容想上能夠作。

另外，localStorage能夠存儲JSON字符串，因此說數據也沒有問題，而且本地的存儲量在5M，足以知足咱們的需求。

一樣的，localStorage也存在跨域的問題，只能在一個網站下面使用，廢話很少說，開始吧。

具體思路：

當用戶添加一件商品的時候，咱們就把相應的商品的sbgaid值存儲到localStorage中，而且由於使用localStorage也只須要購物車部分，咱們如今有兩種選擇：

一種是添加一個商品存儲到一個鍵值對中；刪除一件商品，就刪除一個鍵值對。

優勢：比較簡單，添加setItem，刪除removeItem。缺點：可能會比較亂，全是一堆鍵值對。

還有一種作法是先新建一個對象，而後添加一個商品，就把鍵值對添加到這個對象上，而後在JSON.stringify，而後再存儲到locolStorage中。

優勢: 可能看上去能夠整潔一些。缺點：須要不斷的更新這個對象，而後就是轉換和替換JOSN字符串，結果就是消耗性能。

師兄的意思是從商品中尋找localStorage，咱們能夠來使用localStorage的遍歷方法判斷是否相等來作。。

須要知道的時，咱們須要存儲的是什麼？一個是sbgaid，這個是每個商品都不一樣的，因此能夠做爲鍵，那麼值是什麼呢? 固然就是用戶須要買的數量了！存儲的過程當中，若是add，就amount爲1，若是remove，那麼就直接刪除這個鍵值對便可。因此仍是使用前者好一些。

綜合考慮兩種，其實用戶的購物車每每不多，因此即便是散的鍵值對，也不會很亂，影響不大，因此我決定最終採用第一種作法。

2017年6月19日更新

　　目前項目的需求是作成微商廈的形式，因此說咱們須要改變localStorage的存儲形式，對應於不一樣的店鋪都要有不一樣的k-v，大體以下所示：

    var sbid1 = {
        // 商品標記
        sbgaid1: {
          name: 'apple',
          number: 1,
          unitPrice: 25,
          unit: "個",
          sbgaid: 'sbgaid1'
        },
        sbgaid2: {
          name: 'pear',
          number: 1,
          unitPrice: 85,
          unit: "斤",
          sbgaid: 'sbgaid2'
        },
        sbgaid3: {
          name: 'pig',
          number: 1,
          unitPrice: 5,
          unit: "頭",
          sbgaid: 'sbgaid3'
        },
        // 總價，在訂單頁刷新的時候是須要的。
        totalPrice: 115
    };

    var sbid2 =  {
        sbgaid1: {
          name: 'apple',
          number: 1,
          unitPrice: 25,
          unit: "哦哦",
          sbgaid: 'sbgaid1'
        },
        sbgaid2: {
          name: 'pear',
          number: 1,
          unitPrice: 5,
          unit: "斤",
          sbgaid: 'sbgaid2'
        },
        sbgaid3: {
          name: 'pig',
          number: 1,
          unitPrice: 15,
          unit: "頭",
          sbgaid: 'sbgaid3'
        },
        totalPrice: 45
    };

    // 存儲方式二
    localStorage.setItem('sbid1', JSON.stringify(sbid1));
    localStorage.setItem('sbid2', JSON.stringify(sbid2));

總體思路:

　　1、

　　首先解決添加商品和減去商品的問題，在添加商品的時候，首先檢測當前的sbid是否存在， 若是不存在就建立一個值爲相應sbid的localStorage鍵值對，值爲一個對象，而後對象中查看是否有相應的商品，若是有相應的商品，咱們就直接給number++,若是沒有相應的商品，咱們就建立一個該商品的對象，並保存相應的信息。而後再存儲。若是是減去一個商品，就要直接減1，若是結果爲0，那麼刪去對象的這個鍵就能夠了。

補充：

　以前試了一下采用localStorage作購物車的頁面，可是有一個問題很明顯的出現了。

　仍是要先說一說餓了麼爲何要用localStorage，這是由於餓了麼但願當用戶某次選中某些產品以後，而後退出，在下次進來的時候能夠顯示出這些以前點擊過的商品。

　這一點很重要，我以前嘗試的方法是採用組件懶加載的方式，也就是說，好比一個店家中五個分類，每一個分類下大概有30件產品，當我進入主頁時，我會自動把第一個分類下的產品顯示出來10條（注意：不是顯示徹底）。以下所示：

　　而後獲取到這些數據以後，就把數據存放到vue的store中，這樣，下次用戶再加載時，就可使用使用store中的了。

　　若是我但願看到該分類下的更多，那麼我必定會向下拉，這裏我使用了懶加載，當用戶拉到底部時，開始加載更多的數據，這樣就避免了沒必要要的數據浪費。

　　當看其餘分類下的產品時，好比我點擊一下哈哈，這時又會發送一個ajax請求，請求到這個頁面下的前10條數據。當我但願看更多時，拉到底部開始加載更多數據。

　　 而這就有一個問題！ --- 那就是若是暫時性的網絡差，那麼我可能已經點擊了哈哈，可是界面還停留在蔬菜的內容上，這是由於vue的view是由數據驅動的，我這樣的作法若是沒有獲取到數據，那麼界面就不會發生變化，這樣的用戶體驗是很是的很差的。因此這種方法不可取。

那麼餓了麼團隊處理這種問題的思路是什麼呢？

　打開餓了麼的web app，能夠很容易發現，餓了麼的思路以下：vue

　　進入首頁，先定位（這個不管是美團仍是餓了麼都是這麼作的，優勢是能夠根據你的位置來提供附近的店家，可是缺點也是存在的，它佔用帶寬比較多，4g的網絡還要加載一會，若是網絡再差一點，那麼幾乎要卡死。），定位成功以後就是推薦商家的界面，每個店家是一個item，而且咱們能夠無限向下拉，這個界面採用了懶加載的方式，用戶體驗仍是很不錯的（除了以前說到的位置定位之外）。對於這些店家的介紹無非是店名、評分、位置、月訂單數、配送費、起送價格、一些優惠政策等等。 web

　　進入其中的一個店家以後，其上半部分是店家的介紹，下面是商品的羅列和能夠左右切換的評分。對於商品而言，一樣，左邊是分類，右邊是商品。主要說一說它的實現方式：進入店家以後，先顯示分類，而後顯示出全部分類下的全部商品！！！！而不是點擊一個分類以後再發送ajax。而且只有第一個分類的圖片是事先加載好的。其餘分類只是加載了基本的數據，而沒有加載圖片，咱們經過斷網就能夠發現。而且不管一個分類下有幾十件商品，他都是一次性加載完的，那麼這樣作的好處是什麼呢？我我的認爲好處有如下幾點：ajax

第1、這是最爲重要的一點 --- 一次性加載完全部的數據，咱們就能夠和本地的localStorage作比較，而後把用戶上次選擇過的商品標記出來，讓用戶快速看到以前選了的商品，由於好比我以前的作法，每次只加載一個分類的下的10件商品，那麼這個分類下的其餘商品因爲沒有請求，因此和本地的localStorage就沒法比較，因此說咱們就沒法標記用戶以前的購物車內容。而且利用localStorage的方式能夠節省很多帶寬，很好用。而若是一次所有加載完成，那麼咱們就能夠直接標記處全部了。
第2、這樣作所浪費的帶寬並很少，讀取localStorage的性能消耗應該是能夠接受的。由於對於其餘分類下的產品咱們沒有下載圖片，而只是接受一下數據而已，好比這個店家共有五個分類，那麼咱們只不過就多使用了4個http請求而已，爲何這麼說呢？由於咱們一下請求了全部的商品，關鍵是沒有請求圖片，咱們知道一個圖片就要發送一個http請求，而且圖片的大小每每要比數據大得多！！！因此這種方法是可取的。只要咱們可以解決如何作到只請求數據，而不請求圖片便可。再說一下localStorage消耗的性能問題 --- 首先說明：購物車必定是從商品來匹配購物車的內容，即接收到一個數據，而後遍歷購物車便可。通常用戶的購物車不可能有太多商品，因此一個數據循環那麼幾個localStorage，幾乎是不怎麼消耗性能的，這點我以爲沒必要擔憂。
第3、大大提升了用戶體驗。爲何這麼說呢? 以前我提到過個人作法的問題，就是點擊一個分類請求其中的內容並顯示，這樣的缺點在於 --- 若是在網絡較差的狀況下，咱們所獲得的內容可能仍是原來的，尚未被替換。可是若是使用這種方式，一個很大的好處就是 --- 由於已經得到了全部數據，因此在切換上面數據的更新是很快的，徹底不存在延遲的問題，而圖片的加載就取決於你的網絡狀況了，可是大多數狀況下，咱們並不在乎圖片是否顯示，可能咱們只是看到名字以後就下單了，因此這對於提升用戶體驗的幫助很是的大！

　　總而言之，能夠採起這種思路！用戶體驗必然獲得大幅度的提升！！！！數據庫

　　可是使用這種方式，存在哪些亟待解決的問題呢？小程序

首先，應該解決請求時的pageSize問題，如何作到一次性獲取全部的數據？
如何作到對於其餘的分類只請求數據，而不請求圖片？
是否須要所謂的複選框？美團、餓了麼都是沒有的，而且意義可能不大！
首頁是否須要添加更多的內容呢？
微信小程序的開發須要嗎？仍是挺願意作一個小程序的。

　 回答問題：後端

若是商家中的商品有10000條，那麼咱們可能返回10000條數據嗎？那是不可能的，因此不可能讓後端作到一下返回這麼多數據。另外，若是數據庫有髒數據，那麼顯然也是不適合的，因此任忠鋒師兄的建議是取一個比較大的數字就能夠了，好比50條數據，對於通常的商家而言，50條數據每每就表明了這個分類下的全部數據。
只請求數據，不請求圖片可使用 jqury插件 lazyload，固然對於vue也是同樣的。
仍是須要複選框的，畢竟若是作好了，那麼後面想要用就用，不想要用就算了。
根據任忠鋒師兄的想法首頁可能須要添加一些優惠信息。
微信小程序實際上能夠在這個項目作完以後着手作了，若是能夠實現相同的功能，那麼何樂而不爲呢？

　　在嘗試這個方法的過程當中，我仍是不可避免的遇到了問題。其實也不是問題，只是我以前的想法可能出現了誤差。好比說，對於用這個方式咱們來分析一下圖片是怎麼加載的。即一進入以後首先加載了必需要加載的東西。微信小程序

　　而且能夠看到加載其餘種類的商品數據只發了3個http請求，而且請求到的數據量是很小的，因此這種思路是絕對划得來的。跨域

　　對於餓了麼，咱們還能夠發現它作的一個比較好的地方，那就是在進入一個店鋪以後，用戶體驗作的是真的很棒，好比我先進入這個店，它此時並無獲取圖片，而是等到獲取了全部的分類以後纔開始獲取圖片。若是不是這樣作，那麼咱們頗有可能在獲得其餘分類的時間會很是長。微信

　　即進入店鋪，優先獲取全部分類下的全部商品的數據，這是第一步，第二步纔是獲取第一個分類下的圖片。 網絡

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。