想做一個通知元件,基於MVVM,所有資料走json。清單頁帶過濾和搜尋功能。通知詳情帶上一條下一條切換。
希望能實現在無過濾和搜尋條件下時,在詳情頁內直接做到全局的上一條下一條切換;而在有過濾條件或搜尋條件時,上一條下一條在搜尋結果列表中切換。
這是我自己想出來的方案。
在整個組件初始化時,就把本用戶下的所有通知(ID)取到本地,記到全局[store.list.all],之後當點擊詳情頁時,前端把要點擊的條目id作為參數做ajax請求,這樣詳情頁就有當前通知id,所有通知id列表。這樣的話詳情頁就可以很輕鬆的知道上一條的id、下一條的id。
當有篩選或搜尋條件時,記到全域[store.list.filter],方法同上。
優點:上一條下一條會變得非常容易實現,而且列表頁每次翻頁不需要請求資料。
缺點:如果這個使用者的通知清單非常長,那麼初始化和搜尋的時候,需要請求並記錄到[store.list]中的資料就會非常大,首頁速度可能會非常慢,而且效能會變糟。
公司以前產品的方案。
列表頁做分頁查詢,每次請求使用page+row做參數,以一頁row條,查詢第page頁的方式查詢(例如page=3,row=10,就表示查詢第31-40條)。過濾和搜尋功能同樣。
之前的產品未實現上一條下一條切換。
不過按照這個思路繼續搞下去的話,大概會這樣:
無過濾搜索條件下,發送當前id作為參數,並帶上next或previous參數,這樣數據庫查詢時可以依靠select * from foo where id = ( select min(id) from foo where id > 4)
這個方式去查詢。
有過濾搜尋條件下,這個就比較噁心了,自己沒想出什麼好主意,大概是從列表頁點進詳情頁時保存一下搜尋狀態(這個可以做到,返回按鈕就有保存這個狀態) ,之後上一條下一條時,除了id、next,也帶上搜尋條件做查詢。就是ajax請求api寫起來會比較噁心。
優點:清單頁分頁,使用者有多少通知都不怕。
缺點:列表頁翻頁時也要請求和查詢,查詢條件複雜,後端負擔大,詳情頁上一條下一跳的ajax請求會比較難寫。
目前就這兩種思路,各有優缺點。
大家還有沒有其他思路?
想做一個通知元件,基於MVVM,所有資料走json。清單頁帶過濾和搜尋功能。通知詳情帶上一條下一條切換。
希望能實現在無過濾和搜尋條件下時,在詳情頁內直接做到全局的上一條下一條切換;而在有過濾條件或搜尋條件時,上一條下一條在搜尋結果列表中切換。
這是我自己想出來的方案。
在整個組件初始化時,就把本用戶下的所有通知(ID)取到本地,記到全局[store.list.all],之後當點擊詳情頁時,前端把要點擊的條目id作為參數做ajax請求,這樣詳情頁就有當前通知id,所有通知id列表。這樣的話詳情頁就可以很輕鬆的知道上一條的id、下一條的id。
當有篩選或搜尋條件時,記到全域[store.list.filter],方法同上。
優點:上一條下一條會變得非常容易實現,而且列表頁每次翻頁不需要請求資料。
缺點:如果這個使用者的通知清單非常長,那麼初始化和搜尋的時候,需要請求並記錄到[store.list]中的資料就會非常大,首頁速度可能會非常慢,而且效能會變糟。
公司以前產品的方案。
列表頁做分頁查詢,每次請求使用page+row做參數,以一頁row條,查詢第page頁的方式查詢(例如page=3,row=10,就表示查詢第31-40條)。過濾和搜尋功能同樣。
之前的產品未實現上一條下一條切換。
不過按照這個思路繼續搞下去的話,大概會這樣:
無過濾搜索條件下,發送當前id作為參數,並帶上next或previous參數,這樣數據庫查詢時可以依靠select * from foo where id = ( select min(id) from foo where id > 4)
這個方式去查詢。
有過濾搜尋條件下,這個就比較噁心了,自己沒想出什麼好主意,大概是從列表頁點進詳情頁時保存一下搜尋狀態(這個可以做到,返回按鈕就有保存這個狀態) ,之後上一條下一條時,除了id、next,也帶上搜尋條件做查詢。就是ajax請求api寫起來會比較噁心。
優點:清單頁分頁,使用者有多少通知都不怕。
缺點:列表頁翻頁時也要請求和查詢,查詢條件複雜,後端負擔大,詳情頁上一條下一跳的ajax請求會比較難寫。
目前就這兩種思路,各有優缺點。
大家還有沒有其他思路?
方案一的致命一擊: 如果一個使用者用10W條通知。
方案二的致命一擊:不停的增加查詢條件的複雜度,對儲存壓力增加。
======
中庸方案
一次讀取N天資料(前提是N天的資料量基本上可控,否則此方案不實現)。
可靠方案
使用Elasticsearch