2017-02-24 19 views
1

我們正在創建一個React應用程序,該應用程序在多個位置具有基本的CRUD操作列表。基本的例子,當然是:在web應用程序中樂觀添加列表項的模式是什麼?

  • 填寫輸入有名稱的項目,點擊提交
  • 發送請求到服務器上成功
  • 消防回調
  • 更新列表使用時應對項目數據

我想這個操作是完全樂觀:

  • 填寫輸入有名稱的項目,點擊
  • 更新列表與項目使用給定的名稱提交
  • 發送請求到服務器
  • 列表中的成功
  • 更新項目
  • 消防回調與響應數據

因此,在第一個示例中,我們只是將一個項目從響應和更新應用程序狀態。在第二個例子中,我們做了這個項目,當響應回來時,我們需要找到正確的項目。

這些項目從服務器返回時有id。如果item有一個id,那麼更新當然很簡單。第二個例子的問題是,我們不知道該項目的後端ID。

我個人通過給出一個前端id來解決這個問題,該前端id僅用於引用回調上的右元素。我和我的同事不太喜歡這種方法,因爲它有點......凌亂。

什麼是處理這種情況的適當的,有效的模式?

+0

你的技術聽起來像是你需要做什麼。如果在保存項目之前無法確定ID,則可以在前端上執行的唯一操作是創建元素,保留某種引用,執行AJAX調用,然後在獲得響應後更新該項目從服務器。它不必是一個全局變量,你可以將它保留在AJAX回調的閉包中。 –

回答

1

首先我很高興你已經找到了你的項目持樂觀態度UI的地方;)

關於你的問題:你在做什麼的確是一個完全有效的解決方案。設置前端ID是完全沒問題的。但是,在類似的情況下,我有點不同。而不是更新最後一步的項目,我會再次更新整個列表。與此相關的一點是,無論如何您都會收到完整列表的回覆,那麼爲什麼不使用它呢?它解決了兩個問題:

  • 無需依靠前端ID或任何其他方式標記/存儲項目的事項;
  • 萬一有可能對不同客戶端的列表進行多線程更新(在客戶端獲取列表並點擊submit之間的時間範圍內),更新整個列表將使其保持最新狀態;

請注意,儘管更新大型列表可能會對性能產生影響。同時,在獲得響應之後,您不需要解析列表,因此可以節省一些時間。

所以比較兩種解決方案,並根據對用戶的最好的結果的決定;)

相關問題