Server Actions: mutations sin API Routes

Una mutación debe validar en el servidor aunque el formulario ya limite la entrada. La interfaz puede enviar nombre, pero la acción debe comprobar tipo, longitud y autorización antes de cambiar datos. Así se separa la comodidad del formulario de la confianza en la entrada.

Ejemplo resuelto

'use server';
export async function renombrar(formData: FormData) {
  const entrada = formData.get('nombre');
  if (typeof entrada !== 'string') return { ok: false, error: 'Nombre inválido' };
  const nombre = entrada.trim();
  const autorizado = true; // sesión ficticia del aula
  if (!autorizado || nombre.length < 3 || nombre.length > 80) return { ok: false, error: 'Entrada rechazada' };
  return { ok: true, nombre };
}

La acción no persiste todavía: primero devuelve un resultado verificable.

El literal autorizado = true es una simulación de aula, no autenticación. Una aplicación real recupera una sesión confiable en el servidor y comprueba el permiso sobre el producto en cada acción. Para visualizar este resultado devuelto, conecta la función mediante useActionState en un componente cliente con la firma (estadoAnterior, formData); un simple <form action={renombrar}> no muestra automáticamente {ok,error}.

Pruébalo

1. Envía el nombre Tinta azul.

2. Repite con una cadena vacía.

3. Cambia la autorización ficticia a false.

4. Registra la respuesta de cada caso.

Comprueba tu resultado

Error frecuente: confiar solo en required del formulario. Corrección: repetir validación y autorización en la acción.

Ejercicio: prueba AB, Tinta azul y autorización falsa; el primero debe rechazarse por longitud, el segundo aceptarse y el tercero rechazarse aunque el nombre sea válido.