Considere el siguiente flujo:
Tengo una página con una lista de "productos" y un modal para crear un solo "producto". Abro el modal, llene el formulario y envíe el formulario.
En este punto, envío una acción CREATING_PRODUCT, agrego el producto a la tienda y envío la solicitud http al servidor.
Cierro el modal y muestro la lista de resultados con el nuevo producto.
Supongamos que recibo una respuesta de error del servidor.
Comportamiento deseado:
Me gustaría mostrar un error, eliminar el proyecto de la lista, volver a abrir el modal y mostrar el formulario ya completado.
Pregunta
¿Cómo puedo encontrar ese proyecto y eliminarlo de la lista? No tengo una identificación (o una combinación de propiedades únicas) para encontrar ese proyecto en la tienda. No veo una forma limpia de vincular una solicitud/respuesta a ese objeto de "producto" en la tienda.
Solución posible
El cliente agrega un "requestId" al proyecto antes de agregarlo a la tienda. En caso de error de respuesta, envío un "CREATE_ERROR" genérico y elimino el proyecto con ese ID de solicitud de la tienda.
Extra
Mismo problema con editar y eliminar. Por ejemplo, durante una eliminación, ¿debería mantener una referencia al proyecto eliminado con el ID de solicitud en la tienda, hasta que la solicitud http sea exitosa?
Apuesto a que es un problema con una solución común, pero no puedo encontrar ejemplos. ¡Gracias!
En general, su tienda Redux debe modelarse como una base de datos relacional, en el sentido de que cada vez que tenga una lista de modelos de datos, cada elemento de la lista debe tener su propio identificador. Esto ayuda mucho cuando se trata de esquemas de datos más complejos.
Probablemente debería almacenar sus proyectos como un objeto, algo como:
{ // ...other store properties projects: { "_0": { // ... project properties } "_1": { // ... project properties } // ...more projects... }, } De esta manera, cada vez que necesite meterse con un proyecto existente, puede simplemente hacer referencia a su id y usar projects[id] para acceder a ese proyecto. Esto también resolvería los casos de edición y eliminación, ya que simplemente podría pasar las ID como identificadores.
Me gusta este breve artículo sobre por qué su tienda Redux debe ser mayormente plana y por qué los datos siempre deben tener identificadores. También habla sobre el uso de selectores para "ocultar" sus ID, lo que puede o no ser útil para usted.
En su caso, dado que obtiene ID de un servidor, podría tener un prefijo de ID que indique valores no guardados. Entonces, el objeto de su projects se convertiría en algo como:
projects: { "_0": { // ... } "_1": { // ... } "UNSAVED_2": { // ... } }De esta manera, podría identificar fácilmente los valores no guardados y manejarlos cuando ocurra un error, aún así obtener los beneficios de generar ID temporales en el lado del cliente para revertir los cambios en caso de error, y también advertir a su usuario si intenta abandonar su aplicación. mientras que sus datos aún no se han sincronizado, solo verifique si hay alguna ID "NO GUARDADA" :)
Cuando recibe una respuesta del servidor, puede cambiar el ID "UNSAVED_suffix" por un ID real.