各位前端先進好
過去經驗:
以前小弟在處理表單操作的時候, 每一次表單的新增/修改/刪除資料都是直接呼叫相對的API處理(也就是新增一筆資料後, 就將資料POST到後端, 修改一筆, 就將資料PUT到後端...)
目前情境:
但現在小弟目前在遇到一個雲端系統服務專案, PM目前預期的介面的設計變成是在表單的下方多了Save跟Cancel的按鈕. 使用者在表單所進行的新增/修改/刪除都必須在前端紀錄, 等到使用者按下Save的時候, 再比對原本的表單, 看有新增/修改/刪除哪些資料發送 POST/PUT/DELETE API. 一次更新, 如果使用者按下cancel則還原表單內容
以過去的操作方式來說,
優點:
目前新的設計
優點:
缺點:
目前小弟私心還是傾向用第一種設計模式, 當然也是希望能夠讓開發邏輯簡單, 但如果最後是要第二種操作模式, 不知道板上的大大們有沒有類似的經驗分享? 目前小弟想到的還是只能頂多用lodash提供的method 去比對資料後, 分類資料在發送相對應的API.
說真的,這樣的操作方式並沒有你想像中的那麼麻煩。
大多數來來說,會一筆一筆更新並非是技術上做不到,而是考量資料的安全性。
但其實早就有等同對應的方式來達到你要的東西。
正常來說,一般每一筆資料一定得要有對應的主鍵值或是及複合鍵值。
一但資料有做任何變更時。可以做如下的應用
第一種方式,就將其主鍵id做記錄。
不過這招有一定的危險性。其一就是換頁的麻煩。畢竟只是單純記錄要變更的id。實際更新的值還是存在頁面上等待發送。所以一但換頁就會不見的問題。
第二種方式就是你說的方式。就一筆一筆直先送入後端。比較常用的招式是先生成暫存檔資料。
但這招的缺點,就是很容易殘留無用的資源。只要程式沒寫好的情況下。
最後一招其實也算是結合第一二招處理。我以前比較喜歡用這招。
就是會將更新的值。額外儲存到前端緩存區。按儲存時才依這邊的資料送進去。
感覺有一種 PM 要導入 MySQL+Redis 的 fu!
兩種方法差別就在於批次傳送/單次傳送
批次處理是一次傳送大量的資料過去,然後等待處理
單次傳送是一次送一筆資料過去,然後等待處理
撰寫的時機點在於要評估<<user工作性質>>.去選擇...
如果是機台測試紀錄,那我可以做完一的資料再一次傳送
如果是進出貨,就要一筆單子傳送...