Comment gérer les ID lors de la création optimiste d'une entité dans Redux?

Question

J'ai To-Do List application crée une TodoItem en envoyant une action CREATE_TODO_REQUEST, ce qui provoque un middleware pour faire une demande POST à une API et répondre avec CREATE_TODO_SUCCESS avec le nouveau TodoItem retourné par l'API. Ce/Cette ToDoItem a un ID hexidecimal désordonné (comme 59e52a5ec8dae14f2420a9ef) par notre base de données. Le problème est que parfois l'API peut prendre quelques secondes pour répondre (en particulier si l'utilisateur est sur une connexion faible), donc je voudrais mettre à jour de manière optimiste notre état d'application avec le nouveau ToDoItem avant que le serveur soit terminé le traiter.

Ce modèle est en désordre, car tous mes TodoItem sont indexés par ID dans mon magasin Redux et leur commande est stockée dans une liste d'ID. Ces ID sont générés par l'API après la création d'un ToDoItem.

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

Ma question est, quel ID dois-je céder mes avidement créé ToDoItem, tandis que je l'API pour retourner le nouveau ToDoItem avec une pièce d'identité appropriée? Existe-t-il un modèle établi pour gérer ce type de situation?

Je pourrais utiliser un générateur de nombres aléatoires pour créer un ID provisoire et le remplacer par l'ID réel lorsque l'action CREATE_TODO_SUCCESS est envoyée (voir l'exemple d'application ci-dessous).

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

Mais cela pourrait nécessiter une piste de maintien de la logique complexe dont ToDoItem provisoire est associée à ToDoItem réelle s qui sont ensuite renvoyés par le serveur. De plus, il y a de la complexité à s'assurer que les actions distribuées contre les ToDoItem s (marquées comme étant complètes, éditées, supprimées) sont appliquées au bon "vrai" ToDoItem s après leur création.

Answer 1

La réponse la plus simple consiste à créer un objet local avec un mappage vers l'ID distant.

Par exemple, il pourrait ressembler à ceci:

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

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

Dans Redux, vous pouvez stocker ces objets Todo, et les utiliser en interne pour suivre votre état. Ensuite, lorsque l'API revient finalement avec une valeur, vous pouvez définir remoteId. En cas d'échec, vous pouvez supprimer l'objet local ou définir un indicateur.