Agregar categorias al actualizar una prenda

[josueJouvin]

Revisando el swagger y los types que me da el DTO no tiene o no recibe el campo de categorias

[IvanM9]

No es necesario. Se implementó los endpoints para agregar o quitar las categorías de las prendas de manera independiente

[josueJouvin]

No es necesario. Se implementó los endpoints para agregar o quitar las categorías de las prendas de manera independiente

Osea que si el se elimina una categoria de una prenda tengo que utilizar el endpoint de deactivate-category y si lo agrego una nueva a la prenda utilizar la de add-category?

aunque es un array la parte de seleccionar categorias ya que se puede agregar muchas categorias a una prenda.

o hay algo que no estoy comprendiendo o entendiendo?

[IvanM9]

La decisión de mantener separados add-category y deactivate-category responde a varios principios de diseño:

1. Gestión explícita de estado: Usamos soft-delete en wardrobeCategory, donde cada relación tiene un status. Los endpoints respetan este ciclo de vida sin ambigüedades.

2. Validaciones contextuales: Cada operación valida su estado específico (no puede desactivar algo ya desactivado, no puede agregar algo ya activo). Esto hace la API más robusta.

3. Atomicidad: Cada operación es pequeña y atómica. No hay riesgo de fallos parciales.

4. Flexibilidad del cliente: El cliente tiene control granular para cambios puntuales, sin mantener el estado completo.

[josueJouvin]

La decisión de mantener separados add-category y deactivate-category responde a varios principios de diseño:

1. Gestión explícita de estado: Usamos soft-delete en wardrobeCategory, donde cada relación tiene un status. Los endpoints respetan este ciclo de vida sin ambigüedades.
2. Validaciones contextuales: Cada operación valida su estado específico (no puede desactivar algo ya desactivado, no puede agregar algo ya activo). Esto hace la API más robusta.
3. Atomicidad: Cada operación es pequeña y atómica. No hay riesgo de fallos parciales.
4. Flexibilidad del cliente: El cliente tiene control granular para cambios puntuales, sin mantener el estado completo.

Entiendo los patrones mencionados, pero no me hace sentido aplicarlos en este caso de uso específico (formulario de edición) porque implica múltiples peticiones, y esto se puede manejar de dos formas:

Opción 1: Petición por cada cambio inmediato

• Usuario cambia categoría → petición inmediata
• Agrega otra → otra petición
• Elimina una → otra petición más
• Resultado: N peticiones mientras edita (3, 5, 10... dependiendo de los cambios)

Opción 2: Acumular y enviar al hacer click en "Guardar"

• Usuario hace todos sus cambios
• Click en "Guardar" → X peticiones secuenciales (una por Id modificado o eliminado)
• Resultado: Estados de loading super complejos en el frontend, calcular diffs manualmente, posibles fallos parciales

Aunque React Query maneja de una manera supercorrecta y eficiente los estados de loading y error

• Calcular diffs en el frontend (qué agregar vs qué eliminar)
• Fallos parciales (¿qué pasa si la petición 3 de 5 falla?)
• Complejidad innecesaria solo para guardar un formulario

Inconsistencia con el POST
En el POST ya aceptan arrays:

jsonPOST /api/wardrobe
{ "categoryIds": ["cat1", "cat2", "cat3"] }

¿Por qué en el PATCH no? Si puedo crear con múltiples categorías de una vez, debería poder actualizar igual.

Mi punto
El patrón de categoryId individual que propones tiene sentido para otro tipo de integraciones (webhooks, acciones en tiempo real, integraciones externas), pero no para un formulario donde:

1. El usuario ya sabe que debe hacer click en "Guardar"
2. Espera que todo se guarde en una sola operación atómica
3. El contexto es: "quiero que esta prenda tenga estas categorías" (estado final), no "agrega esto, elimina aquello"

Ejemplo simple:

• Tengo: ["cat1", "cat2", "cat3"]
• Quiero: ["cat1", "cat4", "cat5"]
• Envío: ["cat1", "cat4", "cat5"] en 1 petición

El backend calcula: mantener cat1, agregar cat4 y cat5, desactivar cat2 y cat3

Básicamente el frontend dice "quiero este estado final" y el backend hace la magia con sus validaciones y soft-delete.

nose que te paresca o hacemos discodo en la noche