Validaciones de Formularios en Vue 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. Así que si has hecho aunque sea un poco de pruebas unitarias en tu carrera, creo que te sentirás como en casa trabajando con VEST.

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

En mi experiencia escribiendo formularios y construyendo formularios antes de usar VEST, tuve un gran problema de falta de estructura. Estaba tratando de agregar validaciones al formulario y no estaba seguro de dónde debía colocar la lógica de validación. ¿Debería ponerlas dentro de los controladores de cambio? ¿Debería ponerlas en algún lugar de mi función en una biblioteca compartida? ¿Cómo lo escribo? ¿Cómo evito que sea demasiado específico para mi función? 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 controladores y mi función. Pero luego, cuando quería hacer cambios y mantener la función, como agregar más campos en la función o hacer que los campos dependan entre sí o incluso eliminar un campo, era muy, muy difícil porque todo estaba vinculado a la función. Y debido a que todo es muy específico de la función, también era muy difícil aprovecharlo nuevamente. Por ejemplo, tomarlo y usarlo en un formulario diferente o en una función diferente, como el campo de contraseña en restablecer contraseña e iniciar sesión.

Todo esto me llevó a pensar en una solución. Y hace un par de años, cuando trabajaba 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 descripciones y expectativas. Y se parecía mucho a la forma en que estaba pensando en 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 buenos para expresar lo que hay en comparación con cómo debería ser. Entonces pones una función en una prueba, y lo mismo ocurre con la validación de formularios.

Entonces 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 llegar a algo que todavía 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 se me ocurrió es esta. Primero creamos una suite separada del código de nuestra función y agregamos un callback a ella. Dentro del callback, agregamos nuestras pruebas, similares a las pruebas de pruebas unitarias, con un campo adicional o un parámetro adicional, que es el nombre del campo que estamos validando. Entonces, en este caso, tenemos una prueba y estamos probando el nombre de usuario. Y luego tenemos el error que el usuario recibirá en caso de un fallo de validación. El nombre de usuario debe tener al menos tres caracteres.

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

Solo ten en cuenta que aquí estoy usando la API de opciones, pero también podría funcionar con la API de composición sin ningún cambio en el código de VEST.

Entonces esta es nuestra aplicación. Es una aplicación muy básica sin ninguna validación todavía. Agregué algunos componentes de entrada que están allí solo para el estilo. Agregué algunos nombres de clase. Agregué un nombre de clase para error. Lo convierte en rojo. Permíteme refrescar. Ok, se vuelve rojo. Agregué un nombre de clase para advertencia. Eso lo vuelve naranja y uno para éxito. Eso lo vuelve verde. Junto con eso, también agregué algunas props. Una para errores. Toma una matriz de cadenas. Y cuando se muestra, muestra el error en el campo. Lo mismo para las advertencias. También agregué un spinner de carga porque más adelante vamos a hacer algunas validaciones asíncronas. Entonces, loading es verdadero. Y vamos a ver un spinner. Eso es todo lo que 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 creemos nuestra suite. Fuente. Y vamos a importar create de VEST.

Y haré const suite equals create. Y exportaré por defecto esa suite. Entonces, exportar por defecto suite. Ahora importaré esta suite en mi formulario. Entonces, importar suite desde suite. Y la usaré dentro de mi función validate. Entonces, suite, y la llamaré. Ahora almacenaré el resultado de la validación en nuestro data. Entonces, res equals suite.get. Y también lo actualizaré cada vez que haya un cambio en la función validate. Entonces, this.res equals el resultado de suite. Y tomaré el valor y el nombre y también pasaré el this.input. Entonces, pasemos todo. Y el nombre del campo que estamos validando.

Volviendo a la suite, escribamos nuestra primera prueba. Entonces, primero tomemos el data, que está vacío en este momento. Y tomemos test y enforce. Ahora escribir la primera prueba es muy simple. Probemos que el nombre de usuario y digamos que si falla, el usuario dirá que el nombre de usuario es obligatorio. Y luego hacer cumplir que data.username no esté vacío. Si vuelvo al formulario y ya tengo esto aquí, solo iré al campo de entrada y haré errores equals y luego res.getErrors o el campo username. Y si comienzo a escribir y luego elimino todo, veré que se requiere el nombre de usuario. Que es lo que escribimos.

Dupliquemos esto también para la contraseña y continuemos escribiendo el resto de nuestras pruebas. Así que otro para el nombre de usuario y podemos tener múltiples pruebas para el mismo campo y no tienen que estar en la misma función, lo que facilita mucho entender qué está pasando. Entonces, el nombre de usuario debe tener al menos tres caracteres más largo que dos. Hagamos lo mismo para la contraseña. Y digamos que la contraseña debe tener al menos cinco caracteres. Entonces, más largo que o igual a cinco. Y ahora, si actualizo y comienzo a escribir, veremos que obtenemos el mensaje de validación para el nombre de usuario y también para la contraseña.

Ahora, si te has dado cuenta, el campo de contraseña se ilumina cada vez que escribo dentro del campo de nombre de usuario, lo cual no es el resultado esperado. En realidad, queremos que solo se ilumine 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 escriba dentro de cualquiera de los campos, solo se iluminará. Ahora agreguemos algo de color. VEST no es un marco de interfaz de usuario, pero proporciona algunas utilidades de interfaz de usuario para que puedas dar estilo a tu aplicación. Importemos 'class names' de 'vest class names'. Y lo que hace la utilidad 'class names' es darte la capacidad de especificar qué nombres de clase deben aparecer en qué estado de validación. Así que haré un valor computado 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. Entonces, si es válido, quiero que sea 'success'. Y si es inválido, quiero que sea 'error'. Y si es una advertencia, quiero que sea 'warning'. Así que ahora puedo tomar los nombres de clase y ponerlos en la clase. Entonces, class equals CN, esa es nuestra propiedad, con el campo de nombre de usuario. Y si comienzo a escribir, veremos que se vuelve rojo y luego verde. Hagamos lo mismo para la contraseña. Y esto está sucediendo de la misma manera. ¿Qué pasa si queremos algunos campos de advertencia? Por ejemplo, la fortaleza 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.

Quizás agreguemos un número y hagamos Coincidencias, que toma una expresión regular. Y hagámoslo, tiene del 0 al 9. Y ahora, todo lo que tengo que hacer es agregar 'warn' a eso, lo cual indica que este es un campo de advertencia. Y a medida que escribo, verás que después de cinco caracteres, se vuelve naranja, pero no estamos viendo el mensaje de validation. Y esto se debe a que solo estamos tomando los errores de validation. Así que tenemos que duplicar esto y decir 'Get Warnings'.

Y si comienzo a escribir ahora, la contraseña es débil. Quizás agreguemos un número. Genial. A veces también queremos tener validaciones asíncronas. Por ejemplo, si el nombre de usuario ya está en uso, queremos verificar eso en lugar de permitir que el usuario envíe el formulario y solo luego informarle. Y todo lo que tenemos que hacer en VEST es simplemente devolver una promesa o una prueba asíncrona dentro de nuestra suite.

Así que simplemente lo haré. Tengamos una función simulada que implemente la lógica de si el usuario existe. Entonces, función asíncrona 'does user exist'. Toma un nombre de usuario. Y si el nombre de usuario es igual a 'some user', deberíamos lanzar un error, lanzar un nuevo error. Y también hagámoslo esperar un segundo, obtendré el paquete 'wait'. Así que espera, espera un segundo. Y todo lo que tengo que hacer ahora es escribir una prueba que devuelva si el usuario existe. Entonces, prueba 'username', 'username already taken'. Y solo necesito devolver 'does user exist' y llamarlo con 'data.username'. Ahora, si comienzo a escribir aquí, algún usuario, notarás que no sucede nada. Y esto se debe a que VEST necesita informar al formulario que se completó la validation. Y aquí está esperando un segundo. Así que todo lo que tenemos que hacer y tal vez primero agreguemos un spinner. Para que sepamos qué está sucediendo, agreguemos una nueva propiedad de datos. Entonces, 'username loading' es igual a falso. Este es el valor predeterminado. Y ahora hagamos esto, si el campo que estamos validando es el nombre de usuario, hagamos que 'this.username is loading' sea igual a verdadero.

Y ahora, solo para hacer que funcione, hagamos que 'loading' sea igual a 'his name is loading'. Así que solo para ver, tenemos el spinner, y ahora necesitamos cancelarlo cuando se complete la validation. Entonces, hagamos que comience 'done', abramos 'this.res.done', 'done' es una función que nos da una devolución de llamada cuando se completa la validation. Y todo lo que tenemos que hacer es 'this.res' igual a 'sweet.get' nos da el resultado de validation actual. Y también cancelamos 'username is loading'. Entonces, establecemos 'username loading' en falso. Ahora, si escribo 'some user', se supone que debemos obtener 'username already taken'. Y eso es todo. Eso es todo lo que tienes que hacer para la validation asíncrona.

Pero por supuesto, se puede mejorar. Porque si te fijas, verás que comienzo a escribir. Aunque la validation está fallando para la validation más corta, por ejemplo, debe tener al menos tres caracteres, todavía estamos mostrando el spinner, lo que significa que todavía estamos consultando al servidor, lo cual no es una gran idea, porque podría ser una validación asíncrona muy costosa. Y para evitar eso, simplemente podemos decirle a VEST que omita una validation según ciertos criterios. En este caso, siempre que la validation esté fallando desde el principio. Entonces, en nuestro caso, usemos 'skip when'. Y nos permite indicar cuándo queremos omitir algo y tomamos un salto cuando y nuestro criterio es sweet dot GET, que nos da el resultado de validation tiene errores para el nombre de usuario. Entonces, cada vez que el nombre de usuario esté fallando, no ejecutes lo que está dentro de esa devolución de llamada. Y si hago esto, OK, intentemos escribir algo. E, A, sin spinner, L, hay un spinner, por lo que no estamos validando la validation asíncrona antes de que esté lista.

Ahora hagamos nuevamente una prueba de usuario y está correcta, pero ahora estoy agregando otro carácter y fuimos al servidor y ahora es válida y lo eliminaré. Y fuimos al servidor nuevamente, a pesar de que 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 nuestra prueba y hacer test.memo y luego simplemente agregar nuestras dependencias. Entonces, en nuestro caso, queremos memoizarlo por el nombre de usuario, así que data.username. Mientras el nombre de usuario no cambie o mientras se repita el nombre de usuario, la validación nos dará inmediatamente la misma respuesta sin ir al servidor. Y este es el ejemplo. Entonces, algún usuario, vamos al servidor, agrego un carácter y si lo elimino, verás que obtenemos 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 esté completamente válido. Y esto es fácil de hacer, todo lo que tenemos que hacer es ir a nuestra plantilla nuevamente y luego agregar disable a nuestro botón de envío y decir que queremos deshabilitarlo cuando res no sea válido, es decir, no res es válido. Y déjame ver, oh, deshabilitado, okay. Y ahora está deshabilitado, y si escribo algo, algún usuario uno, perfecto, y contraseña, ejemplo uno, y solo nota que la advertencia no evita el envío del formulario, una advertencia no calificada como inválida, que es justo lo que buscamos. Y así, en solo, 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 tiene Vest, pero no todas. Hay algunas más, y hay validación de campos cambiados al interactuar, lo cual ya hemos hecho. Múltiples validaciones por campo, validaciones de advertencia. Podemos tener validación de campos interdependientes, por lo que podemos tener pruebas que dependen una de otra. Tenemos validaciones asíncronas y también podemos memoizarlas. Podemos agrupar pruebas y anidar pruebas dentro de grupos, por ejemplo, cuando tenemos un formulario de varios pasos. 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 menor de seis kilobytes cuando se comprime. Creo que esto hace de VEST uno de los marcos de validación más pequeños pero más poderosos que existen.

Estoy realmente emocionado trabajando con VEST. Disfruto escribiendo validaciones de formularios con VEST. Agradezco que te hayas unido hoy. Si estás emocionado acerca de 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 excelente día.

Pero primero, veamos los resultados de la pregunta de la encuesta, que se trataba de nuestro consumo de café. Parece que todos nosotros, o la gran mayoría de nosotros, tenemos un problema de cafeína, incluyéndome a mí. Creo que Amitar y yo tuvimos la misma respuesta. Si quieres compartir cuál es nuestro problema. Sí. 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, sin duda, beber café. Así que sí, solo trataba 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.

Ok, pasemos a algunas preguntas. Primera pregunta, lo siento. No quiero arruinar tu nombre, pero tus iniciales son J H. ¿Cómo maneja la API la lógica de validación asíncrona? Por ejemplo, si la validación depende de alguna otra API asíncrona como solicitudes HTTP. Esto es algo que mostré en mi presentación. Probablemente la pregunta se hizo antes de esa parte. Y lo único que tienes que hacer es pasar, en lugar de pasar solo una función de validación, simplemente pasas una función asíncrona o devuelves una promesa. Y si esa función es rechazada o arroja un error, entonces la validación falla y funciona exactamente igual que con cualquier otra validación sincrónica. Genial. Ok, siguiente pregunta de Saffity. Lo siento si estoy arruinando los nombres, de verdad lo siento. ¿VEST admite la validación de esquemas JSON o tiene integración con validadores de esquemas JSON, como AJV? 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 afirmació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 pienso que los formularios deben validarse es a través de diferentes pruebas para cada campo, pero estas son compatibles. Y si estás utilizando validaciones de esquema en tus formularios, entonces sí, por supuesto que puedes usar las mismas validaciones de esquema dentro de tu prueba. Mientras arroje 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 problema al escribir las pruebas u otras dificultades? Sí, muchos de ellos. Escribir VEST no fue sencillo porque estaba tratando de llevar algunos patrones que provienen de un mundo completamente diferente al mundo de la validación de formularios. Y los principales problemas a los que me 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 valga la pena y no solo desperdicie 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.

De acuerdo. La siguiente pregunta es de Anonymousio. Yo uso Nuxt, Beautify y Jest. Si uso VEST, ¿cómo se integra con Nuxt, Beautify y Vuex y todas las bibliotecas? Vaya, eso fue mucho nombre. Nuxt, Beautify y Vuex, y todas las bibliotecas. Mm-hm. Y todas ellas. En realidad, debido a que VEST es un marco que toma un valor, toma una entrada y devuelve un resultado de validación, puedes integrarlo con cualquier cosa y no está intencionalmente vinculado a un marco específico o a ninguna 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 vienes de React, simplemente puedes migrar tus validaciones y no tener que cambiar las cosas solo para integrarlo con un marco específico.

De acuerdo, y en realidad tenemos una pregunta de nuestro maravilloso moderador de preguntas hoy, así que un agradecimiento 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 planeas aplicarla? Oh, sí, eso es una buena pregunta. Y esto es algo que he visto en muchos otros marcos y 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 marcos que no admiten estas validaciones. Y esto es cierto para la validación de tipos de archivo o cualquier medida 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 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 sobre tu negocio para tomar esas decisiones si es válido o no. E incluso si no lo fuera, tendría que venir con mucha redundancia que muchos usuarios no necesitarían. Lo mismo ocurre con el correo electrónico. He estado en lugares donde, por ejemplo, no se permiten alias de correo electrónico, como el signo más después de tu nombre de usuario, y en algunos lugares solo se permite para las direcciones de correo electrónico de la propia empresa. Y VEST no puede saber esto. Por lo tanto, te brinda las decisiones que debes tomar con respecto a las validaciones específicas del negocio. Y lo bueno de VEST es que las afirmaciones se pueden ampliar con marcos y bibliotecas personalizadas. Por ejemplo, si usas una biblioteca que ya maneja la validación de tipos de archivo, simplemente puedes hacer enforce.dot.extend y darle esa entrada, y funcionará como cualquier otra validación dentro de VEST. Muy bien.

De acuerdo. La siguiente pregunta es si VEST tiene una interfaz funcional, y generalmente cuando se trabaja con VUE se espera que sea más reactiva. ¿VEST tiene una interfaz reactiva? ¡Oh, genial! Solo quiero decir que vengo originalmente de un fondo de react, y creo que una de las cosas más agradables de VUE es su modelo de reactividad. Creo que es realmente agradable cómo se actualizan las cosas 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 en lo que me encantaría recibir contribuciones de la comunidad. Entonces, si sabes algo sobre el modelo de reactividad de VUE, o si simplemente quieres aprender y colaborar en ello, estoy interesado. Creo que definitivamente esta es la audiencia adecuada para eso.

Otra pregunta de OrganizedChaos, mencionaste que llevas un seguimiento del estado interno de VEST. ¿Has expuesto formas de borrarlo programáticamente? Sí. De acuerdo, lo explicaré un poco más. Entonces, VEST tiene varias formas de borrar la caché de validación. Una forma es descartar la suite y generar una nueva, y obtendrás un estado limpio. Simplemente crea una nueva suite. Las otras dos formas son básicamente, puedes hacer suite.reset, que es una función que cuando la llamas, se borra todo el estado. Y la otra, si por ejemplo, quieres eliminar un campo específico en caso de que tengas validaciones dinámicas, como cuando el usuario agrega un elemento y ahora tienes que ejecutar validaciones en él, y luego el usuario lo elimina, puedes hacer suite.remove y especificar el nombre del campo que deseas eliminar, y solo se eliminará ese campo. Por lo general, no tienes que hacer ninguna de estas dos cosas, pero a veces sí. Y cuando lo haces, tienes tanto reset como remove. De acuerdo, última pregunta, pero siento que esta podría ser larga. ¿Por qué debería usar VEST en lugar de vValidate o VULIDATE? Sí, sí, gracias por eso. Solo quiero decir que ambas opciones son geniales. Quiero decir, tienen su reputación por una razón. Son buenas y se adaptan a la audiencia de VUE, y son muy similares a muchas otras frameworks y bibliotecas que he visto en otros lugares. Entonces, si las estás usando y te funcionan, no deberías cambiar. Nunca debes cambiar una tecnología que funciona cuando no tienes una buena razón para hacerlo. Pero VEST tiene algunas ventajas cuando quieres usarlo. Y una de ellas es que la sintaxis es bastante única. Se inspira en otro lugar, y creo que hace que sea muy fácil expresar cosas que en otras frameworks son bastante complejas. Y esto es algo en lo que VEST es realmente bueno. Además, VEST está separado de la lógica de tu interfaz de usuario. Entonces, si, por ejemplo, tu aplicación usa un framework y una parte diferente de tu aplicación usa, como, por ejemplo, React, o no sé qué. Tienes, como, una aplicación multi-framework o un microfrontend, puedes compartir tus validaciones porque puedes usar las mismas funciones de VEST, la misma suite de VEST. Además, si tienes multiplataforma, móvil o Node.js o lo que sea, simplemente puedes compartir cosas. Es muy fácil porque todo está separado. Y esto es algo que creo que ni VValidate ni VValidate te ofrecen. Eso es justo. Sí. Sí. Muy bien. Muchas gracias, Eviatar. Fue muy esclarecedor.