如何在Redux中樂觀地創建實體時處理ID？

我有一個待辦事項列表應用程序通過調度CREATE_TODO_REQUEST動作，這會導致中間件做出POST請求的API，並與CREATE_TODO_SUCCESS通過API返回的新創建TodoItem響應創建TodoItem。這ToDoItem有一個混亂的十六進制ID（如59e52a5ec8dae14f2420a9ef）由我們的數據庫分配給它。如何在Redux中樂觀地創建實體時處理ID？

問題是，有時API可能需要幾秒鐘的時間才能做出響應（特別是當用戶處於弱連接時），所以我希望在服務器完成之前用新的ToDoItem樂觀地更新我們的應用程序狀態處理它。

此模式變得混亂，因爲我所有的TodoItem都在我的Redux商店中按ID索引，它們的順序存儲在ID列表中。在創建ToDoItem之後，這些ID由API生成。

{ 
    byId: { 
     59e52a5ec8dae14f2420a9ef: {...}, 
     59e52a5ec8dae14f2420a434: {...} 
    }, 
    ids: [ 
     '59e52a5ec8dae14f2420a9ef', 
     '59e52a5ec8dae14f2420a434' 
    ] 
}

我的問題是，我應該怎樣分配我的ID急切地創建ToDoItem而我等待API與正確的ID返回新創建ToDoItem？處理這種情況是否存在一個既定模式？

我可以使用隨機數生成器來創建一個臨時ID，並在調度CREATE_TODO_SUCCESS動作（請參閱下面的示例應用程序狀態）時將其替換爲真實ID。

{ 
     byId: { 
      59e52a5ec8dae14f2420a9ef: {...}, 
      59e52a5ec8dae14f2420a434: {...}, 
      "provisional-todo-1": {...} // this is being created on the API rn 
     }, 
     ids: [ 
      '59e52a5ec8dae14f2420a9ef', 
      '59e52a5ec8dae14f2420a434', 
      'provisional-todo-1' 
     ] 
    }

但是這可能需要其中的臨時ToDoItem與那些後來從服務器返回的實際ToDoItem伴生一些複雜的邏輯保持跟蹤。此外，確保在針對臨時ToDoItem s（標記爲完成，編輯，刪除）分派的操作在創建之後應用於正確的「真實」ToDoItems時，存在複雜性。

來源

2017-10-18 Jon Gunter

最簡單的答案是創建一個映射到遠程ID的本地對象。

例如，它可能是這個樣子：

class Todo { 
    constructor() { 
    this.id = 'local' + Todo.globalId; 
    Todo.globalId += 1; 
    this.remoteId = null; 
    } 

    resolve(remoteId) { 
    this.remoteId = remoteId; 
    } 
} 
Todo.globalId = 0;

在終極版，你可以存儲這些藤對象，並使用這些內部跟蹤你的狀態。然後，當API最終返回一個值時，您可以設置remoteId。如果出現故障，您可以刪除本地對象或設置一個標誌。

來源

2017-10-19 00:41:16 AnilRedshift

如何在Redux中樂觀地創建實體時處理ID？

回答

相關問題