所以我想使用這三種技術。我的想法是有一個reducer來處理我所有的實體,並由normalizr提供幫助。構造redux,redux-saga和normalizr
終極版,傳奇會聽ENTITIES_REQUESTED
行動,運行的請求的實體,並且使得ENTITIES_RECEIVED
行動,這將通過它調用normalizr並存儲在entities
切片實體減速處理一個傳奇。
對於刪除一個實體,必須發生兩件事:實體必須從狀態中移除,並且必須發生副作用,這將從服務器中刪除該實體(端點:我知道有些人會聲稱從狀態是也副作用,但我不認爲這個概念)。
所以我可以有一個ENTITY_REMOVED
的動作,它會從狀態中刪除實體,並且會聽到這個消息,它會處理api調用。
現在,讓我們說我有一個表,具有表的批量刪除功能。該表由一個減速器「供電」,該減速器接受動作DATA_OPTIONS_SET
。 Reducer會更新當前頁面,過濾器等等。還有一個來自這個監聽器的傳說,並調用API返回新的數據集。
我想要一個批量刪除功能,它在高層次上刪除所有的實體,當完成時刷新表格。
如果我遍歷要刪除的實體併發送一個ENTITY_REMOVED
操作,我將無法知道這些刪除操作何時完成,以便我可以刷新表格。
如果我手動調用刪除實體的傳奇,ENTITY_REMOVED
將永遠不會被分派,因此實體不會從商店中刪除。
這是否意味着我的架構不正確,我在某個地方出現了錯誤的轉向?
我不喜歡關於ENTITY_REMOVE_REQUEST的事情是,它的行爲在應用程序的狀態方面沒有意義。唯一的目的是開始一個副作用,這對我來說似乎很尷尬。 – blockhead
在應用程序狀態中它表示可能失敗的動作(或計算)序列。因爲只有當對服務器的網絡請求成功時纔想更新狀態。如果您不檢查網絡操作是否成功,您的應用程序狀態可能與服務器的狀態不同。我認爲這樣的組織會導致非常明確的傳奇故事,但是如果你找到了一些更好的解決方案,我會很樂意學習 – MadNat
我認爲這個傳奇可以通過簡單地發佈補償措施來處理失敗的情況,如果出現問題。 – blockhead