2016-09-15 79 views
1

所以我想使用這三種技術。我的想法是有一個reducer來處理我所有的實體,並由normalizr提供幫助。構造redux,redux-saga和normalizr

終極版,傳奇會聽ENTITIES_REQUESTED行動,運行的請求的實體,並且使得ENTITIES_RECEIVED行動,這將通過它調用normalizr並存儲在entities切片實體減速處理一個傳奇。

對於刪除一個實體,必須發生兩件事:實體必須從狀態中移除,並且必須發生副作用,這將從服務器中刪除該實體(端點:我知道有些人會聲稱從狀態是副作用,但我不認爲這個概念)。

所以我可以有一個ENTITY_REMOVED的動作,它會從狀態中刪除實體,並且會聽到這個消息,它會處理api調用。

現在,讓我們說我有一個表,具有表的批量刪除功能。該表由一個減速器「供電」,該減速器接受動作DATA_OPTIONS_SET。 Reducer會更新當前頁面,過濾器等等。還有一個來自這個監聽器的傳說,並調用API返回新的數據集。

我想要一個批量刪除功能,它在高層次上刪除所有的實體,當完成時刷新表格。

如果我遍歷要刪除的實體併發送一個ENTITY_REMOVED操作,我將無法知道這些刪除操作何時完成,以便我可以刷新表格。

如果我手動調用刪除實體的傳奇,ENTITY_REMOVED將永遠不會被分派,因此實體不會從商店中刪除。

這是否意味着我的架構不正確,我在某個地方出現了錯誤的轉向?

回答

0

如下我會接近你的問題:創建刪除佐賀這將

  1. 等待實體ID ENTITIY_REMOVE_REQUEST行動參數
  2. 調用適當的端點從服務器
  3. 如果API調用刪除實體是成功發送ENTITY_REMOVED操作,它將從狀態中刪除實體。

當然,這不是唯一的選擇,很多細節將取決於你的api是如何構建的。您可以派發一個操作,它將從服務器獲取所有實體,並使用新的實體列表更新整個狀態,或者可以批量傳遞所有需要在單個API中刪除的實體請撥打第2點。

+0

我不喜歡關於ENTITY_REMOVE_REQUEST的事情是,它的行爲在應用程序的狀態方面沒有意義。唯一的目的是開始一個副作用,這對我來說似乎很尷尬。 – blockhead

+0

在應用程序狀態中它表示可能失敗的動作(或計算)序列。因爲只有當對服務器的網絡請求成功時纔想更新狀態。如果您不檢查網絡操作是否成功,您的應用程序狀態可能與服務器的狀態不同。我認爲這樣的組織會導致非常明確的傳奇故事,但是如果你找到了一些更好的解決方案,我會很樂意學習 – MadNat

+0

我認爲這個傳奇可以通過簡單地發佈補償措施來處理失敗的情況,如果出現問題。 – blockhead