首頁列表需求梳理

04-30

簡單梳理首先目前現有的需求是首頁無限滾動+內容動態刷新(websocket推送)+定時card數據刷新，目前的做法是首屏數據請求放在redux上，

每次內容動態刷新都會放進一個數組中在組件內再繼續刷新，再接著更新界面，目前來看這個方面確實有問題的，同時在以後的需求中就有可能會很繁瑣並不可控，接下來的處理會將所有的數據都更新在redux上比如目前這個木塊屬於 topic模塊，會有一個屬性list包含所有的列表數據，所有的數據更新與添加刪除操作都會在redux層解決，在到達ui層的時候會是一個直接可用的數據，如果數據是被添加或者被刪除需要給UI同時需要重新計算位置(Card的定位)，並不需要再做處理，現在有個問題是有一個定時數據的更新，比如倒計時同時倒計時會觸發Card的改變，因為這個定時數據的存在如果上層通知UI需要重新修改位置，那麼我在UI層就會有一個判斷nextProps.updatePosition !== this.props.updatePosition, 這樣防止每次定時刷新的時候都會有計算，同時因為定時是通過redux層實現的這樣又會造成一個問題，為了防止當前組件的非必要更新需要在shouldComponentUpdate處做判斷防止出現刷新，甚至其他開發者在編寫其他模塊的時候可能也會需要考慮到該因素的影響，比如Modal模塊，通常因為Modal模塊在最外層所以provider傳不下去，可能需要我們直接context.store直接獲取store屬性，這樣就會引起不必要的開發負擔，這是目前發現的問題，所以總結來看首頁topic目前以及將會有的需求為無限載入+增刪改查數據+定時刷新

所以希望找到一個合理的方案用來處理這個問題，目前的的一個基本方案是數據完全交由redux層解決，loading noMore 載入更多等仍舊放UI層，首先將UI層狀態與數據分離，第二定時採取訂閱推送至，需要更新的組件自行訂閱，並自己處理更新邏輯，這樣就能隔離對其他模塊的影響，

接著是篩選功能，熱點，top篩選，展示不同領域數據等，這些如果前端拿到整個數據來排序，在數據大的情況下會有性能問題，同時以不利於對不用模塊的個性化排序（不是簡單的小數目篩選排序），所以如果用戶點擊熱點，top等都會重新從服務端拿數據，一方面是因為剛剛說的原因，另一方面也是為了獲取最新的數據，這些數據都會被存儲在redux topic模塊下，所以接下來的增刪改查都是對某一個模塊的單獨數據操作，數據操作直接在redux處理，如果是增加或者刪除操作(會影響ui界面的操作)就複製updatePositon: update+當前時間戳，UI層通過判斷updatePositon是否發生變化來確定是否需要更新，如果更希望再次抽象這層，讓其他開發者不用考慮這些影響可以寫一個高階組件來處理這些，包括定時，

目前就是關於首頁的需求梳理與解決方案，在這裡用到的數據結構很普通，

如果需求改變每次不同領域的切換不需要重新請求數據但是相同的Card的數據都需要更新，那麼上面的方式就回造成所有有該Card的列表數據都會map更新一遍，所以目前來看這裡的數據結構又不是很合適了，如果考慮到這個因素再加上不同領域的個性化排序，同時沒個領域都會有無限載入，所以不同領域的載入數據有有可能不同，所以在這裡會再次優化為topic:{hotList: {index: 0, tid: , cardData: {}, sportList: {index: 0, tid, cardData}}這樣一種結構。

目前來看就這樣，接下來會開始優化初步構思是這樣,之後會有一個評論需求複雜度是只增不減,數據之間可能還會具有操作了，此時應該就要上鏈了。