Lista de Verificación de Decisiones

Aquí hay las 30 preguntas principales a formular primero cuando alguien solicita un formulario React, junto con sugerencias concisas basadas en sus respuestas (actualizado para React 19 en 2026):

1. ¿Cuál es el propósito del formulario?
2. ¿Cuántos campos y qué tipos se necesitan?
3. ¿Formulario de una página o de múltiples pasos?
4. ¿Qué reglas de validación se requieren?
5. ¿Dónde deben ir los datos al enviar?
6. ¿Hay requisitos especiales de UI/UX o estilos?
7. ¿Requisitos de accesibilidad y móvil?
8. ¿Debería el formulario soportar cargas de archivos?
9. ¿Prefieres TypeScript o JavaScript? ¿Alguna preferencia de gestión de estado?
10. ¿Hay restricciones de pila tecnológica o bibliotecas preferidas?
11. ¿Usarás características de React 19 como useActionState o useFormStatus?
12. ¿Planeas usar acciones de servidor con el formulario?
13. ¿Debería el formulario aprovechar useOptimistic para mejor UX?
14. ¿Alguna necesidad de useFormState o manejo de formulario mejorado en React 19?
15. ¿Quieres que el formulario soporte el manejo asincrónico mejorado de React 19 y transiciones?
16. ¿Cómo debería gestionarse el estado local para valores del formulario y estado de UI?
17. ¿Necesitarás prellenar el formulario con datos existentes de una API?
18. ¿Cómo deberías manejar la obtención de datos durante el envío del formulario o estados de carga?
19. ¿Necesitas sincronización de datos en tiempo real o polling mientras el formulario está abierto?
20. ¿Debería el estado local del formulario sincronizarse con estado global o tiendas externas?
21. ¿Protección contra spam, abuso y bots?
22. ¿CSRF, autenticación y autorización para la acción?
23. ¿Guardado automático, persistencia de borradores o advertencia de "cambios sin guardar"?
24. ¿Visualización de errores a nivel de campo vs resumen vs toast?
25. ¿UX de entrada móvil (teclados, autocompletado, modos de entrada)?
26. ¿Internacionalización (i18n) de etiquetas y mensajes de error?
27. ¿Analítica, seguimiento y métricas de abandono?
28. ¿Estrategia de prueba para el formulario?
29. ¿Idempotencia y prevención de envío doble?
30. ¿Manejo de PII, registro y cumplimiento (GDPR/CCPA/HIPAA)?

1. ¿Cuál es el propósito del formulario?

(inicio de sesión, registro, contacto, encuesta, checkout, configuración, etc.)

Sugerencia: Personaliza campos, validación y flujo posterior al envío para que coincidan exactamente con el caso de uso. Esto asegura que el formulario resuelva la necesidad comercial real en lugar de construir campos genéricos que podrían necesitar remodelación pesada más tarde.

2. ¿Cuántos campos y qué tipos se necesitan?

(texto, email, contraseña, número, seleccionar, checkbox, radio, archivo, fecha, textarea, etc.)

Sugerencia: Prefiere entradas no controladas con características nativas de React 19 para formularios más simples, o usa react-hook-form (no controlado bajo el capó) para necesidades complejas. Esto equilibra el rendimiento con la mantenibilidad mientras aprovecha las fortalezas de React 19.

3. ¿Formulario de una página o de múltiples pasos?

Sugerencia: Una página para menos de 8 a 10 campos. Usa múltiples pasos con stepper y react-hook-form para formularios más largos. Los múltiples pasos reducen la carga cognitiva y mejoran las tasas de finalización para formularios con muchos campos o lógica condicional.

4. ¿Qué reglas de validación se requieren?

(requerido, formato, mín/máx, fortaleza de contraseña, lógica personalizada, tiempo real versus al enviar)

Sugerencia: Usa react-hook-form con zod para validación basada en esquema como la mejor práctica para casos complejos. Para formularios simples, combina validación HTML5 con acciones de servidor React 19 y useActionState.

5. ¿Dónde deben ir los datos al enviar?

(endpoint de API, Firebase, Supabase, estado local, email, etc.)

Sugerencia: Prefiere acciones de servidor nativas con useActionState siempre que el destino sea tu propio backend — manejan estado pendiente, errores y mejora progresiva listos para usar. Para APIs de terceros, usa la API nativa fetch dentro de la acción (salta axios en 2026 — añade tamaño de paquete con poco beneficio ahora que fetch soporta AbortController y streaming).

6. ¿Hay requisitos especiales de UI/UX o estilos?

(Tailwind, shadcn/ui, MUI, Chakra, CSS personalizado, modo oscuro, animaciones)

Sugerencia: Usa shadcn/ui con Tailwind como la opción más popular y accesible en 2026. shadcn/ui ofrece componentes completamente personalizables y accesibles que se ven modernos sin la sobrecarga de tamaño de paquete de bibliotecas de UI más grandes.

7. ¿Requisitos de accesibilidad y móvil?

(etiquetas ARIA, navegación por teclado, soporte de lector de pantalla, diseño responsivo)

Sugerencia: Usa HTML semántico, accesibilidad integrada de react-hook-form y clases responsivas de Tailwind. La accesibilidad adecuada desde el inicio evita correcciones costosas más adelante y asegura cumplimiento con estándares WCAG.

8. ¿Debería el formulario soportar cargas de archivos?

Sugerencia: Usa input type file con react-hook-form y maneja con FormData para la API. Las cargas de archivos requieren manejo especial con multipart/form-data, así que saber esto temprano evita refactorizar la lógica de envío.

9. ¿Prefieres TypeScript o JavaScript? ¿Alguna preferencia de gestión de estado?

Sugerencia: Usa TypeScript con react-hook-form y zod como el default fuertemente recomendado para formularios complejos. TypeScript detecta errores temprano y se empareja bien con los nuevos hooks de React 19.

10. ¿Hay restricciones de pila tecnológica o bibliotecas preferidas?

(Next.js versus Vite, biblioteca de UI existente, preferencia de biblioteca de formularios, necesidades de prueba)

Sugerencia: Usa Next.js 15 con App Router, TypeScript, react-hook-form, zod y shadcn/ui a menos que se especifique lo contrario. Esta pila moderna entrega gran rendimiento, beneficios de SEO y una experiencia de desarrollo suave para la mayoría de formularios de producción.

11. ¿Usarás características de React 19 como useActionState o useFormStatus?

Sugerencia: Usa useActionState para el manejador de envío y resultado (datos, error, pendiente). Usa useFormStatus para cualquier botón de envío anidado o UI pendiente dentro del formulario — lee el estado pendiente del formulario padre sin prop drilling. Son complementarios, no alternativas.

12. ¿Planeas usar acciones de servidor con el formulario?

Sugerencia: Integra acciones de servidor nativas directamente en el prop action del formulario. Esto habilita mejora progresiva y manejo del servidor sin encubrimiento sin llamadas fetch manuales en React 19+.

13. ¿Debería el formulario aprovechar useOptimistic para mejor UX?

Sugerencia: Usa el hook useOptimistic para retroalimentación instantánea de UI al enviar. Proporciona una experiencia de usuario suave mostrando actualizaciones optimistas mientras el servidor procesa los datos del formulario.

14. ¿Alguna necesidad de useFormState o manejo de formulario mejorado en React 19?

Sugerencia: Ten en cuenta que useFormState fue renombrado a useActionState en React 19 — mismo API, nuevo nombre. Combínalo con useFormStatus para estados automáticos pendientes y de error sin bibliotecas de terceros para casos básicos.

15. ¿Quieres que el formulario soporte el manejo asincrónico mejorado de React 19 y transiciones?

Sugerencia: React 19 automáticamente envuelve envíos de action del formulario en una transición — no se necesita startTransition manual para <form action={...}>. Solo usa startTransition explícito para trabajo asincrónico no relacionado con formularios (búsqueda, filtros, cambios de ruta activados desde fuera del formulario).

16. ¿Cómo debería gestionarse el estado local para valores del formulario y estado de UI?

Sugerencia: Usa entradas no controladas con useActionState para formularios simples para minimizar re-renders. Usa react-hook-form para formularios complejos que necesitan control en tiempo real o validación.

17. ¿Necesitarás prellenar el formulario con datos existentes de una API?

Sugerencia: Evita useEffect para obtención inicial — causa parpadeo de carga y waterfalls. Prefiere obtener datos en un Server Component y pasar datos como defaultValues a un formulario Client Component. Para flujos de edición del lado del cliente (p. ej. edición inline), usa useQuery de TanStack Query luego reset() de react-hook-form, o requestFormReset para formularios nativos no controlados.

18. ¿Cómo deberías manejar la obtención de datos durante el envío del formulario o estados de carga?

Sugerencia: En Next.js App Router, acciones de servidor generalmente reemplazan mutaciones del lado del cliente completamente — el estado pendiente viene gratis via useFormStatus. Para configuraciones sin Next.js o APIs de terceros, usa mutaciones de TanStack Query (v5+, anteriormente React Query) para mantener la UI responsiva mientras se obtiene o actualiza datos.

19. ¿Necesitas sincronización de datos en tiempo real o polling mientras el formulario está abierto?

Sugerencia: Integra React Query o SWR para refetch automático y caching. Esto mantiene los datos del formulario frescos sin lógica de actualización manual o valores obsoletos durante sesiones de edición largas.

20. ¿Debería el estado local del formulario sincronizarse con estado global o tiendas externas?

Sugerencia: Los formularios rara vez deberían sincronizarse a estado global durante la edición — eso crea bugs de datos obsoletos y validación. Envía resultados, luego actualiza la tienda (Zustand, Jotai, o Redux Toolkit). Solo sincroniza durante la edición para borradores genuinos entre componentes (p. ej. un wizard dividido entre rutas).

Recomendación default rápida: Para formularios simples: Entradas nativas no controladas + useActionState + useFormStatus + shadcn/ui + Tailwind en Next.js. Para formularios complejos: TypeScript + react-hook-form + zod + shadcn/ui + Tailwind, opcionalmente combinado con hooks de React 19.

Esta lista de verificación asegura que recopiles toda la información necesaria de antemano para construir un formulario que cumple con las necesidades del usuario mientras aprovechas las características más recientes de React 19 para rendimiento y experiencia del usuario óptimos.

21. ¿Protección contra spam, abuso y bots?

Sugerencia: Para formularios públicos (contacto, signup, comentarios), agrega un campo honeypot plus rate limiting en la acción de servidor. Agrega Cloudflare Turnstile o hCaptcha solo si ves abuso real — dañan la conversión. Nunca confíes solo en verificaciones del lado del cliente.

22. ¿CSRF, autenticación y autorización para la acción?

Sugerencia: Las acciones de servidor en Next.js 15 incluyen protección CSRF integrada para POSTs de mismo origen. Siempre recomprueba autenticación y autorización dentro de la acción de servidor (no confíes en la puerta del cliente). Lanza o redirige si no está autorizado.

23. ¿Guardado automático, persistencia de borradores o advertencia de "cambios sin guardar"?

Sugerencia: Para formularios largos (configuración, multi-paso), debounce-guarda a localStorage o al servidor cada pocos segundos. Usa beforeunload (o el patrón useBeforeUnload de Next) para advertir en estado sucio. El formState.isDirty de react-hook-form hace esto trivial.

24. ¿Visualización de errores a nivel de campo vs resumen vs toast?

Sugerencia: Errores inline bajo cada campo para validación; un resumen en la parte superior para lectores de pantalla (con aria-live="polite"); toast solo para resultados a nivel de envío (éxito/error de servidor). No muestres los tres para el mismo error.

25. ¿UX de entrada móvil (teclados, autocompletado, modos de entrada)?

Sugerencia: Establece inputMode, autoComplete y enterKeyHint correctamente — inputMode="numeric" para OTP, autoComplete="one-time-code" para códigos SMS, autoComplete="email" para email. Esta única línea de atributos mejora dramáticamente las tasas de finalización móvil.

26. ¿Internacionalización (i18n) de etiquetas y mensajes de error?

Sugerencia: Mantén todas las cadenas dirigidas al usuario (etiquetas, placeholders, mensajes de validación) en tu catálogo i18n. Con Zod, usa la opción errorMap para traducir mensajes de validación, o llama tu función i18n dentro de mensajes .refine().

27. ¿Analítica, seguimiento y métricas de abandono?

Sugerencia: Rastrea form_start (primer focus), form_field_error, form_submit_attempt y form_submit_success. La tasa de abandono por campo es la métrica de formulario más valiosa — muestra exactamente dónde los usuarios se rinden.

28. ¿Estrategia de prueba para el formulario?

Sugerencia: Usa Vitest + React Testing Library para pruebas unitarias (validación, interacciones de campo). Usa Playwright para end-to-end (envío + ronda de acción de servidor + redirigir). Prueba los caminos infelices: errores de validación, fallo de red, race conditions en envío doble.

29. ¿Idempotencia y prevención de envío doble?

Sugerencia: Deshabilita el botón de envío mientras está pendiente (useFormStatus().pending). Para acciones de pago o destructivas, genera una clave de idempotencia en el cliente y pásala al servidor para que los reintentos no dupliquen la operación.

30. ¿Manejo de PII, registro y cumplimiento (GDPR/CCPA/HIPAA)?

Sugerencia: Nunca registres valores de formulario sin procesar en reportadores de errores (Sentry, Datadog) — extrae o cifra con hash PII antes de registrar. Para datos de salud/financieros, valida solo en el servidor y evita almacenar estado intermedio en localStorage.

Referencias cruzadas

• Entradas Controladas vs No Controladas — para la elección controlada/no controlada en detalle
• React Hook Form, RHF + Zod — para formularios complejos
• Formularios con Server Action, Formularios Optimistas — para patrones nativos de React 19
• Visualización de Errores de Formulario, Accesibilidad de Formularios — para detalles de UX