Migración hacia Server Actions: Refactorizando la gestión de identidad

La complejidad en la gestión de estados de usuario crece de forma silenciosa. Lo que comienza como una configuración simple en el frontend suele terminar siendo un laberinto de llamadas API dispersas y estados de Zustand que se desincronizan fácilmente. En el proyecto TuTiendaWeb, decidimos abordar este problema mediante la migración a Server Actions, centralizando nuestra lógica de identidad.

El desafío de la fragmentación de estado

Al trabajar con una arquitectura basada en componentes, es tentador delegar la gestión del perfil del usuario a múltiples hooks de React. Sin embargo, esto genera una fragmentación donde el setting-store y la UI terminan acoplados a implementaciones que deberían ser puramente servidoras.

La migración no solo busca limpiar el código, sino delegar la responsabilidad de la validación y la persistencia directamente al servidor.

Implementación de Server Actions

En lugar de invocar endpoints de API externos desde el cliente, ahora utilizamos Server Actions para encapsular la lógica. Esto nos permite usar herramientas como zod para validaciones robustas antes de que cualquier dato llegue a nuestra base de datos en Firestore:

'use server';

import { z } from 'zod';

const profileSchema = z.object({
  displayName: z.string().min(2),
  bio: z.string().max(200)
});

export async function updateProfile(data: unknown) {
  const result = profileSchema.safeParse(data);
  if (!result.success) return { error: 'Invalid data' };
  
  // Lógica de persistencia en Firestore
  await db.collection('users').doc(userId).update(result.data);
  return { success: true };
}

Beneficios de la centralización

Al refactorizar la capa de configuración, logramos tres objetivos:

1. Reducción de dependencias: Eliminamos el exceso de lógica en los stores de Zustand.
2. Seguridad: La validación mediante esquemas ocurre en el entorno de ejecución del servidor.
3. Mantenibilidad: La interfaz de usuario ahora es puramente reactiva, esperando el resultado del estado retornado por la acción.

Lecciones aprendidas

La migración nos enseñó que la mejor forma de gestionar el estado del usuario no es mediante una sincronización compleja entre cliente y servidor, sino minimizando el puente entre ambos. Al tratar el perfil como una entidad que se actualiza mediante acciones atómicas, el código se vuelve predecible y fácil de testear.

Takeaway: Antes de crear un store global para datos que residen en el servidor, evalúa si una Server Action puede manejar la mutación de forma directa. Menos estado en el cliente significa menos estados inconsistentes que debas depurar.

Generated with Gitvlg.com