Validando la Web: La Evolución de la Validación de Formularios

Hola a todos. Estoy emocionado de estar con ustedes hoy para hablar sobre la validación de la web, la evolución de la validación de formularios. Los formularios pueden no ser el tema más atractivo, pero son donde ocurre el dinero en nuestras aplicaciones, así que estoy emocionado de estar aquí y mostrarles un nuevo enfoque para la validación de formularios. Quiero agradecer al React Team Summit por tenerme y también por esta oportunidad.

Antes de comenzar con el tema de esta charla, echemos un breve vistazo a cómo evoluciona la web. Así que al principio, Sir Tim Berners-Lee y su equipo inventaron HTML y lanzaron el primer sitio web, dando nacimiento a la World Wide Web. Unos años más tarde, desde principios de los noventa hasta los 2000, en este punto la web era mayormente estática, pero con la introducción de la etiqueta form en HTML2, todo cambió. Fue nuestro primer paso real hacia la interactividad. Desde entonces hasta 2015, este período se transformó en la era de Web 2.0, trayendo verdaderas experiencias interactivas a través de aplicaciones sociales y contenido generado por el usuario.

Por primera vez, las personas estaban en el centro de la web. Desde entonces hasta ahora, Web 2.0 maduró y comenzamos a transicionar a Web 3.0, con un mayor enfoque en la descentralización, aprovechado por tecnologías blockchain y una mayor propiedad del usuario de datos y activos digitales. Echando un vistazo al futuro, creo que todos podemos estar de acuerdo en que la IA y las integraciones de IA estarán en todas partes y cambiarán fundamentalmente la forma en que interactuamos con la web. Lo que es fascinante en medio de toda esta evolución es cómo la humilde etiqueta form ha permanecido consistentemente importante a través de todas estas etapas hasta el día de hoy.

Soy Luiz Oliveira, soy ingeniero de personal en XGeeks y puedes encontrar más sobre mí en mi sitio luizfilipppt.com. Por cierto, PT no significa entrenador personal. No sé por qué, pero me preguntan esto mucho. Realmente significa Portugal, el país de donde soy. Esta charla fue realmente inspirada por Evitar, cuya charla el año pasado cambió completamente mi perspectiva sobre la validación de formularios, algo simplemente hizo clic cuando lo escuché hablar. Y estoy aquí hoy para compartir algunos de esos conocimientos con ustedes. Evitar es una gran persona y un gran ingeniero trabajando en Meta. Y si estás interesado en React, te recomiendo encarecidamente seguir su trabajo.

Seamos honestos. Los formularios son donde ocurre el dinero en nuestras aplicaciones. Son cómo los usuarios ingresan datos, realizan compras e interactúan con nuestros sistemas. Como puedes ver en el diagrama de flujo que aparece en la pantalla, la validación de formularios es mucho más compleja de lo que parece a primera vista. Comenzamos con el envío del formulario, validamos entradas, verificamos si los campos son obligatorios, validamos en el servidor. Por cierto, si no estás validando en el servidor, siéntete libre de dejar esta charla y volver más tarde, porque la validación en el servidor es crucial para la validación de formularios.

Volviendo al contenido. Entonces mostramos mensajes de error, esperamos que los usuarios corrijan la entrada, y este ciclo puede continuar una y otra vez. Podemos repetir esto múltiples veces. Y todos estos flujos intrincados crean desafíos significativos, como requisitos de estructura compleja que son difíciles de mantener, asegurar la consistencia de la validación en diferentes partes de nuestras aplicaciones, gestionar tanto las validaciones del lado del cliente como del servidor, manejar varios escenarios de validación y casos límite, proporcionar mensajes de error significativos a nuestros usuarios, y retroalimentación que los guíe a través de la experiencia. Y cuando los formularios fallan, literalmente perdemos dinero. Los usuarios abandonan las compras, las aplicaciones quedan incompletas y las tasas de conversión se desploman. Esta complejidad es exactamente por qué creo que necesitamos mejores enfoques para la validación.

Echemos un vistazo al panorama actual de la validación, y puede llegar a ser bastante abrumador. Si miras este resultado de búsqueda de npm, dice que hay más de 1,000 paquetes relacionados con la validación de formularios, y esta es solo la forma en que npm muestra los resultados. Hay más de 10,000 paquetes relacionados con la validación de formularios. Y esto nos dice dos cosas. Una es que la validación de formularios es un desafío generalizado, la otra, no hay una única solución que se ajuste a todas las necesidades. Existen diferentes enfoques de validación, pero probablemente los más utilizados son los paquetes de validación de esquemas y los paquetes de validación de frameworks. Los primeros son excelentes para la validación del lado del servidor y las estructuras de datos, pero se sienten un poco, no sé, desconectados de la experiencia del usuario, ya que los usuarios realmente no escriben en un esquema.

Los segundos, específicos de frameworks, son geniales, pero a veces pueden parecer demasiado opinados, y siempre te atan a algún framework o a algún patrón. Lo que los desarrolladores realmente necesitan es algo que sea flexible, reutilizable y mantenible que pueda manejar escenarios complejos sin sacrificar la experiencia del desarrollador o el rendimiento. Echemos un vistazo a VEST. VEST fue creado por Avatar y adopta un enfoque nuevo y fresco para resolver algunos de estos desafíos. Se inspiró en los frameworks de pruebas unitarias y trae esos patrones familiares a la validación. Es fácil de aprender, especialmente si lo has usado antes. Es agnóstico al framework, con características inteligentes, potentes y optimizaciones de rendimiento listas para usar. Es completamente reutilizable en entornos de cliente y servidor, resolviendo el clásico problema de duplicación de validación.

Y ahora reproduciré un breve video que muestra la sorprendente similitud entre el código de prueba de Jest y el código de validación de VEST. Así que comenzamos con Jest, donde usamos términos como describe, groups, tests, y expect que verifica resultados. Luego, al pasar a VEST, describe se convierte en VEST create, lo verás al final del video, y expect se convierte en enforce, que aplica reglas de validación. VEST también toma un parámetro adicional en cada validación, que es el nombre del campo a validar. Y por supuesto, todo el conjunto de validación recibe los datos del formulario para validar. Esta estructura es muy similar a Jest, solo con algunos detalles nuevos, haciendo que el cambio sea fácil de entender. Y este enfoque familiar significa que podemos ponernos al día rápidamente, y nuestra lógica de validación se vuelve clara y mantenible.

Al igual que las pruebas, nuestras validaciones ahora expresan exactamente lo que esperamos de los datos. Veamos una de las características de VEST, cómo separa limpiamente la lógica de validación de tu código de UI. Veamos este ejemplo de código para entender por qué esto es importante. Como podemos ver, tenemos secciones distintas y claramente separadas. Tenemos nuestro conjunto de validación, donde importamos las funciones del curso de VEST, create, test y enforce. Definimos nuestra lógica de validación de una manera completamente agnóstica a la UI. Y nuestra regla de validación de contraseña simplemente establece que la contraseña debe tener al menos ocho caracteres de longitud.

Debajo de eso, en un archivo de componente separado, gestionamos el estado del formulario con el use state de React. Ejecutamos la validación contra nuestros datos actuales del formulario. Renderizamos nuestro componente de UI con los campos del formulario. Y mostramos errores cuando la validación falla. Así que esta separación nos da varios beneficios importantes. Nuestra lógica de validación vive completamente independiente de las preocupaciones de la UI. Puedes reutilizar la misma validación en diferentes componentes o incluso en diferentes plataformas. Los cambios en la UI no afectarán tus reglas de validación, y las pruebas se vuelven dramáticamente más simples ya que la lógica de validación está completamente aislada.

Los nuevos miembros del equipo pueden ponerse al día rápidamente y entender los requisitos de validación sin tener que profundizar en el código de la UI. En aplicaciones complejas, esta separación se vuelve aún más valiosa a medida que la complejidad crece. Ahora, echemos un vistazo a una de mis características favoritas de VEST, la validación asincrónica. En aplicaciones del mundo real, a menudo necesitamos validar contra fuentes de datos externas, como por ejemplo, un servidor. Un ejemplo clásico de esto es verificar si un nombre de usuario está disponible o si ya está tomado. Si miramos este ejemplo de código, VEST hace que la validación asincrónica sea sorprendentemente sencilla. A la izquierda, tenemos nuestro código de validación con dos características clave. Tenemos el only, que es la función de palabra clave only, que recibe el campo actual y nos permite validar solo un campo a la vez, lo cual es perfecto para esas validaciones on-blur.

En segundo lugar, observe test.memo, que almacena en caché el resultado de la llamada al servidor o cualquier fuente de datos externa y solo vuelve a ejecutar esta validación cuando ese valor cambia. En nuestro componente externo a continuación, usamos suit.isPending. Le pasamos el nombre del campo para que podamos obtener fácilmente un estado de carga que nos permita proporcionar retroalimentación inmediata al usuario mientras se completa la validación asincrónica. VEST maneja toda la complejidad de gestionar estados pendientes, almacenar resultados en caché y asegurar que las validaciones se ejecuten en paralelo cuando sea posible. Los usuarios obtienen retroalimentación inmediata y el código se mantiene limpio y mantenible.

El ejemplo de UI a la derecha muestra lo que experimentará el usuario. Cuando escriben un nombre de usuario, ven la validación ocurriendo en tiempo real, incluyendo la verificación contra la fuente de datos externa. Si el valor ya está en la caché de VEST, entonces la validación es instantánea. El video está en bucle, pero puedes notar que la primera vez que se verifican los valores pith y ptr aparece un cargador mientras se realiza la verificación. Pero la segunda vez que estos valores aparecen en la entrada, la retroalimentación es inmediata.

Otra característica poderosa de VEST es la capacidad de compartir la lógica de validación entre tu código de cliente y servidor mientras se mantiene el estado de validación entre ellos. Echemos un vistazo a otro ejemplo de código. Tenemos nuestra lógica de validación compartida que se utiliza en ambos entornos. En este caso, tenemos una validación simple de nombre de usuario que verifica si está vacío, y luego el mismo conjunto de validación se importa y utiliza en ambos códigos de cliente y servidor. En nuestro servidor, recibimos datos externos de una solicitud post. Ejecutamos el conjunto de validación contra los datos. Serializamos el resultado de todo el estado de validación a JSON y lo enviamos al cliente. Luego, en nuestro código de cliente, tenemos un componente de React responsable de gestionar el estado. Cuando recibimos la respuesta del servidor, la usamos para restaurar el estado de validación, y esto nos permite retomar exactamente donde lo dejamos en el servidor.

Este patrón es increíblemente útil para varios casos de uso diferentes. Validación cliente-servidor, donde validamos datos críticos en ambos lados usando las mismas reglas. Persistencia, podemos guardar el estado de validación entre sesiones de usuario o pasos en formularios de múltiples pasos. Para depuración, ya que tienes el estado completo de validación al solucionar problemas, la depuración se vuelve mucho más fácil. Este enfoque resuelve uno de los problemas más frustrantes en el desarrollo y en la validación externa, que es mantener la lógica de validación consistente a lo largo de la pila.

Con VESC, podemos escribir nuestro código de validación una vez y usarlo en todas partes. Ahora echemos un vistazo a otra característica de VESC. Estados de advertencia. A veces necesitamos más que una simple validación de aprobación o falla. VESC introduce un concepto poderoso llamado estado de advertencia que nos da un punto intermedio entre campos válidos e inválidos. Observando este ejemplo de código, en el conjunto de validación anterior, estamos usando la palabra clave warn la función warn. Dentro de nuestra prueba de contraseña, y esto simplemente dice que queremos que esta contraseña tenga un número, pero no es un requisito estricto. Sugerimos agregar el número para fortalecer la contraseña.

En el componente a continuación, obtenemos tanto errores como advertencias. Podemos unirlos para mostrar todos los mensajes al usuario. Pero si el formulario solo tiene advertencias, aún se puede enviar. Si tiene errores, bloquean el envío. Y en el video de demostración, ves cómo esto crea una experiencia de usuario mucho mejor. En lugar de bloquear envíos por problemas no críticos, podemos guiar a los usuarios hacia mejores prácticas sin realmente frustrarlos. Podemos crear experiencias de validación progresivas. Podemos implementar cosas como indicadores de fortaleza de contraseña. Podemos sugerir mejoras mientras aún permitimos el envío. También podemos diferenciar entre debe arreglar y debería considerar arreglar. Y la sutil distinción entre errores y advertencias crea una experiencia más matizada y amigable para el usuario. Todas estas cosas respetan el tiempo de nuestros usuarios mientras aún fomentan las mejores prácticas.

Piensa, ¿cuántas veces has abandonado un formulario debido a una validación demasiado estricta? Probablemente te ha pasado antes, y los estados de advertencia ayudan a mitigar ese problema. Otro desafío común en la validación de formularios es manejar la validación de campos relacionados. Eso significa que la validez de un campo depende de otro. Un ejemplo clásico, el que traigo aquí, son los campos de confirmación de contraseña.

Así que echando un vistazo al ejemplo de código, tenemos nuestras validaciones estándar de contraseña en la parte superior, requerir verificación de longitud, y luego la sección destacada muestra un patrón poderoso omitido usando skip when. Le decimos a Vest que omita la validación del campo de confirmación hasta que el usuario realmente comience a escribir en él. Luego validamos que la confirmación coincida con la contraseña. Y este patrón crea una experiencia de usuario más natural. No queremos mostrar errores de confirmación antes de que el usuario haya comenzado a escribir en la confirmación.

El formulario a la izquierda muestra lo que experimenta el usuario. Pueden completar su nombre de usuario y contraseña primero, y solo cuando comienzan a escribir en el campo de confirmación, Vest comienza a validar esa relación entre los campos. Pero la confirmación de contraseña no es el único ejemplo. Hay varios casos de uso comunes donde esta validación de campos relacionados es importante. Rangos de estado, donde una fecha de finalización debe ser posterior a una fecha de inicio. Validaciones de direcciones donde un código postal debe coincidir con una ciudad o un estado. Campos de cantidad donde un pedido mínimo debe ser menor que algún número máximo. Formularios de múltiples pasos con dependencias entre los pasos.

Así que Vest hace que todas estas relaciones sean fáciles de expresar y mantener mientras mantenemos nuestra lógica de validación clara incluso a medida que la complejidad crece. Al concluir hoy, quiero dejarles algunos pensamientos clave sobre la validación de formularios. Los formularios son realmente nuestra conexión más fuerte con los usuarios. Son cómo los usuarios interactúan con nuestras aplicaciones de la manera más directa y significativa. Cuando creamos formularios, estamos creando conversaciones entre nuestras aplicaciones y nuestros usuarios.

Y seamos honestos una vez más. Los formularios son los generadores de dinero de nuestras aplicaciones. Son cómo los usuarios se registran, realizan compras, envían información y se convierten en usuarios leales de nuestros productos y aplicaciones. Así que cuando las experiencias de formularios son malas, estamos perdiendo dinero. Literalmente perdiendo dinero. Los usuarios abandonan nuestras aplicaciones. Dejan nuestros productos. Por eso la validación de formularios merece nuestro amor y atención. No es solo un requisito técnico.

Es una parte crítica de la experiencia del usuario que impacta directamente en el éxito de nuestras aplicaciones. Trivest adopta un enfoque fresco a este desafío al traer esos paradigmas de prueba familiares a la validación. Hace que nuestro código, como mostré, sea más mantenible, nuestra lógica de validación más aislada, por lo tanto más reutilizable, y en general las experiencias de usuario mejoran. Les animo a probar Trivest en su próximo proyecto. Ya sea que estén construyendo un formulario de contacto simple o un formulario complejo de múltiples pasos en alguna aplicación compleja, realmente creo que un enfoque rápido puede ayudarles a crear mejores validaciones con menos esfuerzo. Pruébenlo y vuelvan a mí y denme su opinión.

Así que al terminar esta charla, quiero agradecerles a todos por acompañarme. Espero que hayan encontrado algunas ideas útiles para llevar a sus propios proyectos. Una última cosa, asistiré al evento Live React Summit en Ámsterdam, así que si van a estar allí, me encantaría conectar en persona. Ya sea que quieran profundizar en el desarrollo de React o simplemente quieran tomar una bebida y charlar, por favor no duden en contactarme. Tienen todas las formas de contactarme en mi sitio. Gracias nuevamente por su atención. Espero verlos en Ámsterdam. Gracias.