Vue Form Validations con Vest

¡Hola! Soy Aviatar. Soy un ingeniero de front-end en Facebook, y soy el autor de VEST. VEST es un marco de validación de formularios inspirado en bibliotecas de pruebas unitarias como Mocha o Jest. Entonces, si has hecho incluso un poco de pruebas unitarias en tu carrera, creo que te sentirás muy a gusto trabajando con VEST.

Hoy, quiero mostrarte cómo podemos usar VEST para mejorar la forma en que escribimos validaciones de formularios en nuestras aplicaciones de Vue. Pero antes de comenzar a hablar sobre VEST en sí, quiero mencionar un poco la motivación detrás de VEST y qué me llevó a escribir VEST para empezar.

En mi experiencia escribiendo formularios y construyendo formularios antes de usar VEST, tenía un gran problema de falta de estructura. Entonces, estaba tratando de agregar validaciones al formulario, y no estaba seguro de dónde debería poner la lógica de validación. ¿Debería ponerlas dentro de un manejador de cambios? ¿Debería ponerlas en algún lugar de mi característica en una biblioteca compartida? ¿Cómo lo escribo? ¿Cómo evito que sea demasiado específico para mi característica? Y no hay una estructura específica que las validaciones deban seguir.

Así que terminé haciéndolo funcionar escribiéndolo en algún lugar entre mis manejadores y mi característica. Pero luego, cuando quería hacer cambios y mantener la característica, como agregar más campos en la característica, o hacer que los campos dependieran unos de otros o incluso eliminar un campo, era muy, muy difícil porque todo estaba atado a la característica. Y porque todo es muy específico para la característica, también era muy difícil reutilizarlo. Así que para tomarlo y usarlo en un formulario diferente o una característica diferente, como el campo de contraseña tanto en restablecer contraseña como en iniciar sesión.

Así que todo esto me llevó a pensar en una solución. Y hace un par de años, cuando estaba trabajando con un empleador anterior, acabábamos de comenzar a escribir pruebas unitarias para nuestras aplicaciones. Y vi que los patrones que tienen las pruebas unitarias, que tenemos esa suite de pruebas con describe y expect. Y se veía muy similar a la forma en que estaba pensando sobre la validación de formularios en mi mente. Porque las pruebas unitarias son declarativas por naturaleza, por lo que puedes describir exactamente lo que quieres que suceda. Y junto con eso, son muy buenas para expresar lo que hay en comparación con cómo debería ser. Así que pones una función en una prueba, y lo mismo ocurre con la validación de formularios.

Así que quiero que mis valores, mis datos, pasen por algunas pruebas. Y todo parece muy relevante para el mundo de la validación de formularios. Por supuesto, no es exactamente lo mismo, y la terminología es diferente, y no ejecutamos pruebas unitarias en producción. Pero con algunos ajustes de diseño, pude idear algo que aún es muy similar a la forma en que escribimos pruebas unitarias, y sigue siendo muy relevante para la validación de formularios. Y la estructura que ideé es esta. Primero creamos una suite que está separada de nuestro código de características, y le añadimos un callback. Dentro del callback, añadimos nuestras pruebas, similar a las pruebas unitarias, con un campo adicional o un parámetro adicional, que es el nombre del campo que estamos validando. Así que en este caso tenemos test, y estamos probando ese nombre de usuario. Y luego tenemos el error que el usuario recibirá en caso de un fallo de validación. Así que el nombre de usuario debe tener al menos tres caracteres.

Y dentro del callback de esa prueba, tenemos nuestras afirmaciones. Así que similar a assert o expect, hacemos cumplir que data.username es más largo que dos, o cualquier validación que tengamos allí. Y quiero mostrarte cómo funciona con una aplicación Vue real en vivo.

Solo nota, estoy usando aquí, la API de opciones, pero podría funcionar con la API de composición igual de bien. Sin cambios en absoluto al mejor código.

Así que esta es nuestra aplicación. Es una aplicación muy básica sin ninguna validación en absoluto aún. Y agregué algunos componentes de entrada que están allí solo para el estilo. Agregué algunos nombres de clase. Así que agregué un nombre de clase para error. Lo convierte en rojo. Déjame solo refrescar. Bien, lo convierte en rojo. Agregué un nombre de clase para advertencia. Eso lo convierte en naranja y uno para éxito. Eso lo convierte en verde. Y junto con eso, también agregué algunos props. Así que uno para errores. Y toma un array de strings. Y cuando se muestra, muestra el error en el campo. Y lo mismo para advertencias. También agregué un spinner de carga, porque vamos a hacer algunas validaciones asíncronas más adelante en el camino. Así que loading true. Y vamos a ver un spinner. Así que eso es todo lo que ya tenemos aquí. También tenemos la función de validación, que está vacía. Toma el nombre y el valor del campo que estamos validando. Y vamos a crear nuestra suite. Así que source. Y vamos a importar create de vest.

Y haré const suite equals create. Y exportaré por defecto esa suite. Así que export default suite. Ahora importa esta suite en mi formulario. Así que import suite from suite. Y la usaré dentro de mi función validate. Así que suite, y la llamaré. Ahora almacenaré el resultado de la validación en nuestros datos. Así que res equals suite.get. Y también la actualizaré cada vez que haya un cambio en la función validate. Así que this.res equals el resultado de suite. Y tomemos el valor y el nombre y también pasemos el this.input. Así que pasemos todo. Y el nombre del campo que estamos validando.

De vuelta a la suite, escribamos nuestra primera prueba. Así que primero tomemos los datos, que están vacíos en este momento. Y tomemos test y enforce. Ahora escribir la primera prueba es muy simple. Probemos que username y digamos que si falla, el usuario dirá que el nombre de usuario es obligatorio. Y luego enforce que data.username no esté vacío. Si vuelvo al formulario y ya tengo esto aquí, solo iré al input y haré errors equals y luego res.getErrors o el campo username. Y si empiezo a escribir y luego elimino todo, veré que el nombre de usuario es obligatorio. Que es lo que escribimos.

Dupliquemos esto para password también y vamos a escribir el resto de nuestra prueba. Así que otra para username y podemos tener múltiples pruebas para el mismo campo y no tienen que estar en la misma función, lo que hace que sea muy fácil entender lo que está pasando. Así que username debe tener al menos tres caracteres de longitud, más de dos. Hagamos lo mismo para password.

Ahora, si lo notaste, el campo de contraseña comienza a iluminarse cada vez que escribo dentro de username, lo cual no es el resultado esperado. En realidad, queremos que solo se active para sí mismo. Y esto es realmente fácil. Simplemente importemos only y only nos permite especificar los campos que queremos validar en cualquier momento dado. Así que ejecutemos only. Y recuerda, estamos pasando el nombre del campo que estamos validando a la suite. Podemos tomarlo aquí, campo actual, y pasarlo a only. Y ahora, cada vez que escribo dentro de cualquiera de los campos, solo se iluminará.

Ahora agreguemos algo de color. Vest no es un marco de UI, pero te da algunas utilidades de UI, para que puedas estilizar tu aplicación. Hagamos import class names desde vest class names. Y lo que hace la utilidad class names es que te da la capacidad de especificar qué nombres de clase deben aparecer en qué estado de validación. Así que haré un valor calculado, y usaré... Y devolveré class names y le pasaré el resultado de la validación. Y también las clases que quiero que aparezcan en cualquier etapa. Así que si es válido, quiero que sea success. Y si es no válido, quiero que sea error. Y si es warning, quiero que sea warning. Así que ahora puedo tomar los class names y ponerlo en la clase. Así que class equals CN, esa es nuestra propiedad, con el campo Username. Y si empiezo a escribir, veremos que es rojo y luego es verde. Así que hagamos lo mismo para Password. Y esto está sucediendo igual.

Ahora, ¿qué pasa si queremos algunos campos de advertencia? Así que, por ejemplo, la fuerza de la contraseña no debería bloquear el envío del formulario, pero debería notificar al usuario que hay un problema. Hagámoslo. Tenemos la función de validaciones de advertencia. Solo tenemos que llamar a la función warn de Vest. Así que probemos la contraseña. Y digamos que es débil, que no tiene números. La contraseña es débil.

Tal vez añade un número y hagamos Matches, que toma una expresión regular. Y hagamos, tiene del 0 al 9. Y ahora, todo lo que tengo que hacer es simplemente añadir warn a esto, lo que indica que este es un campo de advertencia. Y mientras escribo, verás que después de cinco caracteres, se vuelve naranja, pero no estamos viendo el mensaje de validación. Y esto es porque solo estamos tomando los errores de validación. Así que tenemos que duplicar esto y decir, Get Warnings.

Y si empiezo a escribir ahora, Password is weak. Tal vez añade un número. Cool. A veces también queremos tener validaciones async. Por ejemplo, si el username ya está tomado, queremos verificar eso en lugar de dejar que el usuario envíe y solo entonces decírselo. Y todo lo que tenemos que hacer en VEST es simplemente devolver una promesa o un test async dentro de nuestra suite.

Así que simplemente lo haré. Tengamos una función mock que implemente una lógica de does user exist. Así que async function does user exist. Toma un username. Y si el username es igual a algún usuario, deberíamos lanzar un error, throw new error. Y también hagamos que espere un segundo, obtendré el paquete npm wait. Así que a wait, wait for one second. Y todo lo que tengo que hacer ahora es escribir un test que devuelva does user exist. Así que test username, username already taken. Y solo necesito devolver does user exist y llamarlo con data dot username. Ahora, si empiezo a escribir aquí, algún usuario, notarás que no pasa nada. Y esto es porque best necesita informar de vuelta al formulario que la validación se completó. Y aquí está esperando un segundo. Así que todo lo que tenemos que hacer y tal vez primero añadamos un spinner. Así que sabemos qué está pasando, añadamos una nueva propiedad de datos. Así que username loading es igual a false. Este es el valor por defecto. Y ahora hagamos si name, así que si el campo que estamos validando es username, hagamos que this dot username is loading sea igual a true.

Y ahora solo para hacerlo funcionar, hagamos loading igual a his name is loading. Así que solo para ver bien, tenemos el spanner, y ahora necesitamos cancelarlo cuando la validación se complete. Así que hagamos que empecemos done, open this dot res dot done, done es una función que nos da un callback cuando la validación se completa. Y todo lo que tenemos que hacer es this dot res equals sweet dot get nos da el resultado actual de la validación. Y también cancelemos username is loading. Así que these that username loading equals false. Así que ahora si escribo si escribo algún usuario, se supone que obtendremos usernames already taken. Y eso es todo. Eso es todo lo que tienes que hacer para la validación async.

Pero, por supuesto, se puede mejorar. Porque si te das cuenta, verás que empiezo a escribir. Aunque la validación está fallando para la validación más corta, por ejemplo, debe tener al menos tres caracteres, todavía estamos mostrando el spinner, lo que significa que todavía estamos yendo al servidor, lo cual no es una gran idea, porque podría ser una validación async muy costosa. Y para evitar eso, podemos simplemente decirle a best que omita una validación según algunos criterios. En este caso, siempre que la validación esté fallando desde el principio. Así que en nuestro caso, usemos skip when. Y nos permite decir cuándo queremos omitir algo y estamos tomando un skip when y nuestro criterio es el sweet dot GET, que nos da el resultado de la validación tiene errores para username. Así que siempre que username esté fallando, no ejecutes lo que sea que esté dentro de ese callback. Y si hago esto, OK, intentemos escribir algo. E, A, sin spinner, L, hay un spinner, por lo que no estamos validando la validación async antes de que esté lista.

Ahora hagamos un usuario de nuevo y es correcto, pero ahora estoy agregando otro carácter y fuimos al servidor y ahora es válido y lo quitaré. Y fuimos al servidor de nuevo, aunque sabemos que la validación ya está fallando porque ya la hemos visto fallar para el mismo usuario. Nuevamente, podría ser una validación costosa y podemos manejarla con memoization dentro de VEST. Y todo lo que tenemos que hacer es tomar nuestro test y hacer test.memo y luego simplemente agregar nuestras dependencias. Así que en nuestro caso, queremos memoizarlo por el username, así que data.username. Así que mientras el username no cambie o mientras el username se repita, la validación nos dará inmediatamente la misma respuesta sin ir al servidor. Y este es el ejemplo. Así que algún usuario, vamos al servidor, estoy agregando un carácter, y si lo quito, verás que obtuvimos una respuesta inmediata. Y ahora verás que el formulario es válido, todo está bien, solo quiero agregar una cosa más. Quiero deshabilitar el envío antes de que el formulario sea completamente válido. Y esto es fácil de hacer, todo lo que tenemos que hacer es ir a nuestro template nuevamente, y luego agregar disable a nuestro botón de submit, y decir que queremos deshabilitar cuando res no es válido, así que no res es válido. Y déjame ver, oh, deshabilitado, está bien. Y ahora está deshabilitado, y si escribo algo, algún usuario uno, perfecto, y password, example uno, y solo nota que la advertencia no impide el envío del formulario, una advertencia no calificada como inválida, que es justo lo que buscamos. Y así, dentro de, creo, seis líneas de lógica dentro de Vue, pudimos validar este formulario completamente con muchas, muchas validaciones complejas, lo cual es bastante impresionante, creo.

Y, hemos visto algunas de las características que VEST tiene, pero no todas. Hay algunas más, y hay validación de campos cambiados tras la interacción, lo cual hemos hecho. Múltiples validaciones por campo, validaciones de advertencia. Podemos tener validación de campos interdependientes, por lo que podemos tener tests que dependen uno del otro. Tenemos validaciones asíncronas, y también podemos memoizarlas. Podemos agrupar tests y anidar tests dentro de grupos, por ejemplo, cuando tenemos un formulario de varios pasos. Entonces, en general, tenemos validaciones estructuradas. Estas son algunas de las características de VEST, pero no todas. Incluso con todas esas características y toda esta complejidad, VEST sigue siendo menos de seis kilobytes cuando está mini-zipped. Creo que esto hace que VEST sea uno de los frameworks de validación más pequeños y potentes que existen.

Estoy realmente emocionado trabajando con VEST. Disfruto escribiendo validaciones de formularios con VEST. Te agradezco por acompañarme hoy. Si estás emocionado con VEST hoy, no dudes en contactarme en Twitter, o incluso ir a la página de GitHub, o incluso enviar un PR, mejorando la documentación para Vue, o incluso mejorando y agregando algo de código. Realmente lo aprecio. Muchas gracias por acompañarme hoy. Que tengas un gran día.

Pero primero, veamos los resultados de la pregunta de la encuesta que hizo, que fue sobre nuestro consumo de café. Parece que todos nosotros, o la gran mayoría de nosotros, tenemos un problema de cafeína, yo incluido. Creo que Amitar y yo tuvimos la misma respuesta. Si te gustaría compartir cuál es nuestro problema. Sí. Así que, no se trataba de tu problema de cafeína. Se trataba de mi problema de cafeína, solo para aclarar. Y sí, mi opción fue la tercera, mientras que seguro, bebo café, definitivamente. Así que sí, solo estaba tratando de sentirme cómodo con mi consumo, para dejarlo claro. Bueno, estás en buena compañía porque soy buena compañía y eso es lo que importa.

Bien, pasemos a algunas preguntas. Primera pregunta, lo siento. No quiero destrozar tu nombre, pero tus iniciales son J H. ¿Cómo maneja la API la lógica de validación asíncrona? Por ejemplo, la validación depende de alguna otra API asíncrona como solicitudes HTTP. Así que esto es algo que mostré en mi presentación. La pregunta probablemente se hizo antes de esa parte. Y todo lo que tienes que hacer es simplemente pasar, en lugar de solo pasar una función de validación, simplemente pasas una función asíncrona o devuelves una promesa. Y si esa función rechaza o lanza un error, entonces una validación falla y funciona exactamente igual que con cualquier otra validación síncrona. Genial. Bien, siguiente pregunta de Saffity. Lo siento si estoy destrozando nombres, realmente lo siento. ¿VEST soporta la validación de esquemas JSON o tiene integración con validadores de esquemas JSON, como AJV? Así que VEST, como concepto general, no es una biblioteca de validación de esquemas, aunque se integra con cualquier cosa. Y solo como una nota rápida, Enforce, la función de aserción dentro de VEST, tiene funciones de validación de esquemas muy extensas.

No es la forma más recomendada porque la forma en que creo que los formularios deberían validarse es a través de diferentes pruebas para cada campo, pero estas son compatibles. Y si estás usando validaciones de esquemas en tus formularios, entonces sí, por supuesto que puedes usar las mismas validaciones de esquemas dentro de tu prueba. Así que mientras lance un error o devuelva un booleano, puedes ponerlo dentro de tu prueba de validación.

Genial. La siguiente pregunta de Organized Chaos. Me gustan las personas que tienen palabras normales. De todos modos, la pregunta es, muy interesante usar patrones de prueba para la validación de formularios. Parece bastante factible. ¿Has encontrado algún inconveniente al escribir las pruebas u otros escollos? Sí, muchos de ellos. Así que, escribir VEST no fue simple porque estaba tratando de tomar algunos patrones que vienen de un mundo completamente diferente al mundo de la validación de formularios. Y los principales problemas que enfrentaba es que las pruebas unitarias son básicamente sin estado. Así que cada vez que las ejecutas, todo el estado se genera una y otra vez. Y lo que tuve que hacer para que VEST realmente valiera la pena y no solo desperdiciara tu tiempo gestionando tu propio estado es tener un estado interno que retenga los resultados de validación para cada uno de los campos que se validan. Y luego solo tienes que hacer la parte agradable de escribir las validaciones personalizadas.

Okay. La siguiente pregunta es de Anonymousio. Uso Nuxt, Beautify y Jest. Si uso BEST, ¿qué tal la integración de Nuxt, Beautify y Vuex y todas las bibliotecas? Vaya, eso fue mucho nombre dropping. Nuxt, Beautify y Vuex, y todas las bibliotecas. Mm-hm. Y todas ellas. En realidad, debido a que VEST es un framework que toma un valor, toma una entrada y devuelve un resultado de validación, puedes integrarlo con cualquier cosa y no está intencionalmente atado a un framework específico o a una biblioteca específica, por lo que es muy versátil y puedes usarlo en muchos conceptos y aspectos diferentes y en muchos contextos diferentes. Así que puedes usarlo con Nuxt, sin Nuxt, o puedes usarlo con Vuex, o si estás viniendo de React, puedes simplemente migrar tus validaciones y no tener que cambiar cosas solo para integrarte con un framework específico.

Bien, y de hecho tenemos una pregunta de nuestro maravilloso moderador de preguntas hoy, así que un saludo a todo el arduo trabajo de... Voy a destrozar esto. Lo siento mucho. Pero la pregunta es, ¿VEST admite la validación de tipos de archivo o planean aplicarla? Oh, sí, esa es buena. Y esto es algo que he visto en muchos otros frameworks también o bibliotecas para validación, y típicamente, algunos de ellos lo hacen, pero típicamente no admiten algún tipo de validaciones. VEST es uno de ellos, de los frameworks que no admiten estas validaciones. Y es cierto para la validación de tipos de archivo o cualquier validación de medición de archivo, es cierto para la validación de correo electrónico, y es cierto para algunas otras. Y la razón es que estas son muy centradas en el negocio y específicas del negocio. Y cada vez que intentas validar algo que es específico de cualquier tamaño de archivo, cualquier tipo de archivo, VEST tendría que conocer mucho de tu negocio para simplemente tomar esas decisiones si es válido o no. E incluso si no, tendría que venir con mucha sobrecarga que muchos usuarios no necesitarían. Lo mismo para el correo electrónico. He estado en lugares donde, por ejemplo, no se permiten alias de correo electrónico, como el más después de tu nombre de usuario, y algunos lugares donde solo se permite para las direcciones de correo electrónico de la propia empresa. Y VEST no puede saber esto. Así que te da las decisiones para tomar respecto a validaciones específicas de negocio. Y lo bueno de VEST es que las afirmaciones se pueden extender con frameworks personalizados y bibliotecas personalizadas. Así que, por ejemplo, si usas una biblioteca que ya maneja la validación de tipos de archivo, puedes simplemente hacer enforce dot extend, y darle esa entrada, y funcionará como cualquier otra validación dentro de VEST. Muy bien.

Bien. La siguiente pregunta es que VEST tiene una interfaz funcional, y usualmente cuando se trabaja con VUE se espera que las cosas sean más reactivas. ¿Tiene VEST una interfaz reactiva? Oh, genial. Así que solo tengo que decir que vengo de un fondo de React originalmente, y creo que una de las cosas más agradables de VUE es su modelo de reactividad. Creo que es realmente agradable cómo las cosas se actualizan y cómo funcionan de esta manera. La verdad es que quiero agregar una interfaz reactiva a VEST. Pero requiere bastante investigación, y creo que es algo que VEST debería tener, o al menos un puente, que funcione con el modelo de reactividad de VUE. Esto es algo para lo que me encantaría tener algunas contribuciones de la comunidad. Así que si sabes algo sobre el modelo de reactividad de VUE, o si solo quieres aprender sobre y colaborar en ello, estoy dispuesto. Creo que esta es definitivamente la audiencia adecuada para eso.

Otra pregunta de OrganizedChaos, mencionaste que llevas un seguimiento del estado interno de VEST. ¿Has expuesto formas de borrar eso programáticamente? Sí. Bien, lo haré un poco más largo. Así que VEST tiene múltiples formas de limpiar la caché de validación. Una es que puedes simplemente descartar el suite y generar uno nuevo, y obtendrás un estado limpio. Así que solo crea un nuevo suite. Las otras dos formas son básicamente, puedes hacer suite.reset, esta es una función que cuando la llamas, todo el estado se borra. Y la otra, si por ejemplo, quieres eliminar un campo específico en caso de que tengas validaciones dinámicas, como que el usuario agregó algún elemento y ahora tienes que ejecutar validaciones sobre él, y luego el usuario lo eliminó, entonces puedes hacer suite.remove y especificar el nombre del campo que quieres eliminar, y entonces solo ese campo se elimina. Usualmente no tienes que hacer ninguna de esas, pero a veces sí. Y cuando lo haces, tienes tanto reset como remove.