參考美團、餓了麼 && 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));      

整體思路: 　　一、 　　首先解決添加商品和減去商品的問題，在添加商品的時候，首先檢測目前的sbid是否存在， 如果不存在就建立一個值為相應sbid的localStorage鍵值對，值為一個對象，然後對象中檢視是否有相應的商品，如果有相應的商品，我們就直接給number++,如果沒有相應的商品，我們就建立一個該商品的對象，并儲存相應的資訊。然後再存儲。 如果是減去一個商品，就要直接減1，如果結果為0，那麼删去對象的這個鍵就可以了。                         　　   補充：  　 之前試了一下采用localStorage做購物車的頁面，但是有一個問題很明顯的出現了。 　 還是要先說一說餓了麼為什麼要用localStorage，這是因為餓了麼希望當使用者某次選中某些産品之後，然後退出，在下次進來的時候可以顯示出這些之前點選過的商品。  　 這一點很重要，我之前嘗試的方法是采用元件懶加載的方式，也就是說，比如一個店家中五個分類，每個分類下大概有30件産品，當我進入首頁時，我會自動把第一個分類下的産品顯示出來10條（注意：不是顯示完全）。 如下所示： 　　

　 　　然後擷取到這些資料之後，就把資料存放到vue的store中，這樣，下次使用者再加載時，就可以使用使用store中的了。   　　如果我希望看到該分類下的更多，那麼我一定會向下拉，這裡我使用了懶加載，當使用者拉到底部時，開始加載更多的資料，這樣就避免了不必要的資料浪費。  　　當看其他分類下的産品時，比如我點選一下哈哈，這時又會發送一個ajax請求， 請求到這個頁面下的前10條資料。 當我希望看更多時，拉到底部開始加載更多資料。  　　 而這就有一個問題！ --- 那就是如果暫時性的網絡差，那麼我可能已經點選了哈哈，但是界面還停留在蔬菜的内容上，這是因為vue的view是由資料驅動的，我這樣的做法如果沒有擷取到資料， 那麼界面就不會發生變化，這樣的使用者體驗是非常的不好的。 是以這種方法不可取。 

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

　  打開餓了麼的web app，可以很容易發現，餓了麼的思路如下：

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

　　進入其中的一個店家之後， 其上半部分是店家的介紹，下面是商品的羅列和可以左右切換的評分。 對于商品而言， 同樣，左邊是分類，右邊是商品。主要說一說它的實作方式： 進入店家之後，先顯示分類，然後顯示出所有分類下的所有商品！！！！ 而不是點選一個分類之後再發送ajax。 并且隻有第一個分類的圖檔是事先加載好的。其他分類隻是加載了基本的資料，而沒有加載圖檔，我們通過斷網就可以發現。并且無論一個分類下有幾十件商品，他都是一次性加載完的，那麼這樣做的好處是什麼呢？ 我個人認為好處有以下幾點：

• 第一、 這是最為重要的一點 --- 一次性加載完所有的資料，我們就可以和本地的localStorage做比較，然後把使用者上次選擇過的商品标記出來，讓使用者快速看到之前選了的商品，因為比如我之前的做法，每次隻加載一個分類的下的10件商品，那麼這個分類下的其他商品由于沒有請求，是以和本地的localStorage就無法比較，是以說我們就無法标記使用者之前的購物車内容。并且利用localStorage的方式可以節省不少帶寬，很好用。 而如果一次全部加載完成，那麼我們就可以直接标記處所有了。 
• 第二、 這樣做所浪費的帶寬并不多，讀取localStorage的性能消耗應該是可以接受的。 因為對于其他分類下的産品我們沒有下載下傳圖檔，而隻是接受一下資料而已，比如這個店家共有五個分類，那麼我們隻不過就多使用了4個http請求而已，為什麼這麼說呢？ 因為我們一下請求了所有的商品，關鍵是沒有請求圖檔，我們知道一個圖檔就要發送一個http請求，并且圖檔的大小往往要比資料大得多！！！ 是以這種方法是可取的。 隻要我們能夠解決如何做到隻請求資料，而不請求圖檔即可。再說一下localStorage消耗的性能問題 --- 首先說明： 購物車一定是從商品來比對購物車的内容，即接收到一個資料，然後周遊購物車即可。一般使用者的購物車不可能有太多商品，是以一個資料循環那麼幾個localStorage，幾乎是不怎麼消耗性能的，這點我覺得不必擔心。 
• 第三、大大提高了使用者體驗。 為什麼這麼說呢?  之前我提到過我的做法的問題，就是點選一個分類請求其中的内容并顯示， 這樣的缺點在于 --- 如果在網絡較差的情況下，我們所得到的内容可能還是原來的，還沒有被替換。 但是如果使用這種方式，一個很大的好處就是 --- 因為已經獲得了所有資料，是以在切換上面資料的更新是很快的，完全不存在延遲的問題，而圖檔的加載就取決于你的網絡情況了，但是大多數情況下，我們并不在意圖檔是否顯示，可能我們隻是看到名字之後就下單了，是以這對于提高使用者體驗的幫助非常的大！   

　　

　　  總而言之，可以采取這種思路！ 使用者體驗必然得到大幅度的提高！！！！

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

• 首先， 應該解決請求時的pageSize問題，如何做到一次性擷取所有的資料？ 
• 如何做到對于其他的分類隻請求資料，而不請求圖檔？
• 是否需要所謂的複選框？ 美團、餓了麼都是沒有的，并且意義可能不大！ 
• 首頁是否需要添加更多的内容呢？   
• 微信小程式的開發需要嗎？ 還是挺願意做一個小程式的。 

　   回答問題：

• 如果商家中的商品有10000條，那麼我們可能傳回10000條資料嗎？ 那是不可能的，是以不可能讓後端做到一下傳回這麼多資料。 另外，如果資料庫有髒資料，那麼顯然也是不适合的，是以任忠鋒師兄的建議是取一個比較大的數字就可以了，比如50條資料， 對于一般的商家而言，50條資料往往就代表了這個分類下的所有資料。
• 隻請求資料，不請求圖檔可以使用 jqury插件 lazyload， 當然對于vue也是一樣的。
• 還是需要複選框的，畢竟如果做好了，那麼後面想要用就用，不想要用就算了。 
• 根據任忠鋒師兄的想法首頁可能需要添加一些優惠資訊。 
• 微信小程式實際上可以在這個項目做完之後着手做了，如果可以實作相同的功能，那麼何樂而不為呢？ 

　　

　　在嘗試這個方法的過程中，我還是不可避免的遇到了問題。 其實也不是問題，隻是我之前的想法可能出現了偏差。 比如說，對于用這個方式我們來分析一下圖檔是怎麼加載的。 即一進入之後首先加載了必須要加載的東西。 

　　并且可以看到加載其他種類的商品資料隻發了3個http請求，并且請求到的資料量是很小的，是以這種思路是絕對劃得來的。   

　　

　　對于餓了麼，我們還可以發現它做的一個比較好的地方，那就是在進入一個店鋪之後，使用者體驗做的是真的很棒，比如我先進入這個店，它此時并沒有擷取圖檔，而是等到擷取了所有的分類之後才開始擷取圖檔。如果不是這樣做，那麼我們很有可能在得到其他分類的時間會非常長。 

　　即進入店鋪，優先擷取所有分類下的所有商品的資料，這是第一步，第二步才是擷取第一個分類下的圖檔。 

轉載于:https://www.cnblogs.com/zhuzhenwei918/p/6931416.html