Dominando los Formularios en Vue

Soy Justin Schrader y es posible que me conozcan de Internet, tal vez no. Algunos de los proyectos de código abierto en los que estoy involucrado son FormKit, que es de lo que estamos hablando hoy. Arrow.js, que es una alternativa ligera de dos kilobytes a cosas como React y Vue. Otro es AutoAnimate, que es realmente genial. Funciona muy bien con Vue y React y realmente cualquier otro. Te permite animar automáticamente los elementos del DOM que entran y salen del DOM o se mueven. Y luego Vue Formulate, que es el antecesor espiritual de FormKit. Era una biblioteca de Vue 2, todo sobre la construcción de formularios en Vue. Y finalmente, soy socio de una agencia llamada Braid aquí en Charlottesville, Virginia. Eso soy yo.

Esta también soy yo en 2019 mirando un proyecto de cliente masivo que habíamos construido con cientos, tal vez miles de entradas y formularios. Fue increíblemente tedioso de construir, muy difícil de mantener. Y en ese momento estábamos pensando que tiene que haber una mejor manera. Así que hablemos un poco sobre eso porque la sabiduría predominante en el internet en este momento, especialmente en dev Twitter es que los formularios no son difíciles. Los formularios son fáciles. De hecho, Ryan Florence, uno de los creadores de Remix recientemente publicó este tweet y creo que se aplica, ya sabes, él está hablando de remix y react, pero creo que se aplica a cualquier de las grandes bibliotecas que hay. Permíteme leer esto. No creo que debería haber abstracciones de formularios. Los formularios son fundamentalmente interacciones de marcado de usuario, controladores de eventos, gestión de estado, solicitudes entre vistas cayeron en react. ¿Qué hará la biblioteca de formularios aquí? Agrega alguna validación y listo. Sentimiento interesante. Y sabes qué? Fundamentalmente Ryan tiene razón. Los formularios son fáciles. Todo lo que realmente necesitas es una etiqueta de formulario y un par de etiquetas de entrada y voilà, tienes un formulario completamente válido. Um, aquí hay uno. Es un nombre de usuario y contraseña. Esto podría ser un inicio de sesión o un registro.

Y como puedes ver, es increíblemente simple. Ahora, para ser justos, probablemente deberíamos agregar un botón para enviar el formulario. Um, en este caso, agregamos un botón de registro. Así que esto debe ser un formulario de registro.

Y realísticamente, por razones de accessibility, vamos a necesitar algunas etiquetas en ellos. Además, la gente ni siquiera sabrá qué completar si no las ponemos ahí. Así que vamos a hacer eso. Simplemente agregaremos un ID a nuestros campos de entrada porque necesitamos vincularlos semánticamente con los atributos de las etiquetas. Así que simplemente lo agregaremos ahí. Genial. Mira cómo se renderiza nuestro formulario. La gente sabrá cómo completarlo. Estamos listos para continuar.

Aunque, para ser justos, parece un poco como un formulario de inicio de sesión, así que probablemente deberíamos agregar algo de texto de ayuda en esos campos de entrada. Y para hacer eso, todo lo que tenemos que hacer es agregar un ARIA described by en nuestro campo de entrada real. Y luego, dondequiera que pongamos nuestro texto de ayuda, podemos poner un ID, uh, algo como, ya sabes, ayuda de nombre de usuario. Y ahora estamos bien. Ahora estamos listos para comenzar. Aquí vamos. Ahora nuestro formulario comienza a verse mejor. Tenemos texto de ayuda, ya sabes, probablemente podríamos aplicarle algunos estilos, pero se ve bien. Los formularios son fáciles.

Para ser justos, esto aún no hace nada. Así que vamos a agregar un script en la sección head aquí, y simplemente pondremos un at submit. Esto es Vue. Súper fácil. Controlador de envío. Y ahora estamos listos para aceptar realmente estos data y hacer algo con ellos. Y hay un par de formas. Podemos obtener los data correctamente.

Ahora eso funciona. Aunque en Vue nos gusta tener un poco más de control sobre lo que está sucediendo con los campos de entrada. Entonces, realísticamente, probablemente vamos a usar un objeto reactivo con tal vez nuestro nombre de usuario y contraseña como propiedades dentro de él, y luego simplemente usaremos V-model para el modelo del formulario, el nombre de usuario será model, la contraseña, y luego pasaremos todos esos datos del formulario, ya sabes, a la función que realmente lo enviará a la API.

Entonces esto funciona. Um, no veo ningún problema con eso. Bueno, hay una pequeña cosa para ser justos. Cuando llamamos a enviar a la API, no sabemos qué va a suceder. Puede haber errores. Así que probablemente necesitemos manejar los errores que vienen de nuestro backend, pero sabes qué? No hay problema. Somos ingenieros. Estamos preparados para la tarea. Lo vamos a lograr.

Así que echemos un vistazo aquí. Um, todo lo que realmente necesitamos hacer es tener alguna forma de almacenar nuestros errores de forma reactiva. Algo como un ref. Ahora tenemos nuestros errores aquí, y luego pondremos un try-catcher en nuestro enviar a la API y simplemente asignaremos el resultado de esos errores al valor de errores. Y luego en algún lugar dentro de nuestro formulario, tal vez en la parte inferior, cerca de donde la persona hizo clic en enviar. Tendremos algo como VF errores y simplemente mostraremos todos los errores ahí mismo en la parte inferior. Sin problema. ¿Qué es esto aquí? Ah, Grupo Nielsen Norman. Muy respetado. Vamos a, vamos a leer esto. Mantener los mensajes de error junto a los campos en error, minimiza la carga de memoria. Los usuarios pueden ver los mensajes de error mientras corrigen el error en lugar de tener que recordarlo. Entendido. Así que no quieren todos los errores al final del formulario. Les gustaría que se coloquen donde están los campos de entrada reales. Genial.

Genial. No hay problema. Eh, podemos resolver eso. Probablemente, en este punto, para ser justos, este formulario está empezando a verse un poco feo. Probablemente deberíamos envolver algunos de estos, ya sabes, extraerlos en componentes como esta área aquí, por ejemplo, sería mucho mejor si estuviera escrito como un componente separado real.

Así que aquí vamos. Aquí hay un nuevo componente para nuestros campos de entrada reales. Tenemos propiedades definidas. Eh, vamos a aceptar una etiqueta, ayuda. Y ahora vamos a aceptar los errores para poder mostrarlos junto al campo de entrada. Y luego aquí abajo, lo único que veo, ya sabes, la mayoría de esto se está pasando o renderizando errores, pero todavía tenemos este V-model. Eso es un problema, porque, por supuesto, los datos del formulario ya no están en nuestro alcance aquí. ¿Qué necesitamos hacer? Bueno, necesitamos agregar un valor de modelo y luego algo como definir un método para actualizar el valor del modelo. Y en lugar de usar un V-model, ahora necesitamos escuchar los eventos de entrada en el campo de entrada, y necesitamos actualizar un evento llamado update model value con nuestro nuevo valor. Listo.

Hmm. ¿Qué es esto? Tengo otro. Idealmente, toda la validación debería estar en línea. Es decir, tan pronto como el usuario haya terminado de completar un campo, debería aparecer un indicador cercano si el campo contiene un error.

De acuerdo. Mm. Validación. Validación en línea. De acuerdo. Antes de apresurarme y seguir intentando hacer estas iteraciones, vamos a hacer una lista rápida de lo que se debe hacer aquí. Entonces, necesitamos agregar reglas de validación en línea de alguna manera en los propios campos de entrada, supongo. Um, luego necesitamos averiguar cómo obtener la validación desde dentro de esos campos y agregarlos para que sepamos si nuestro formulario es válido antes de que se envíe.

Frustrante. Pero podemos hacer eso. Y luego probablemente necesitemos algún tipo de retroalimentación de carga. Imagino. Quiero decir, ¿qué sucede si tenemos que anidar estos un poco más profundo y tenemos que pasar todas esas propiedades a través de otros componentes? Necesitamos agregar estilos. Este formulario solo tiene dos campos de entrada, literalmente dos campos de entrada. Y la complejidad se está saliendo de control y todavía se ve como basura.

Entonces surge la pregunta, los formularios son fáciles. Vamos a volver a examinar esta hipótesis. De acuerdo. Aquí está el tweet de Ryan Florence nuevamente. No creo que incluso deba haber abstracciones de formulario. Los formularios son fundamentalmente marcado, interacciones de usuario, controladores de eventos, gestión de estado, solicitudes entre vistas, Felton react. ¿Qué haría una biblioteca de formularios aquí? Agregar algunas funciones de validación y listo. Interesante. Creo que lo que Ryan está tratando de decir es que si pensamos en los dos dominios que deben ser manejados por un formulario en un framework, es que la superposición entre ellos no se ve así. Creo que Ryan está diciendo que las personas que construyen bibliotecas de formularios tienen una superposición en sus mentes que se ve algo así, como un poco de lo que hace el framework es un poco de lo que hace el formulario. Y lo que Ryan está diciendo es que en realidad el diagrama de Venn se superpone completamente.

Todo lo que hacen los formularios, los marcos de trabajo también lo hacen, y con eso estoy de acuerdo. La única diferencia es que creo que el dominio del formulario se ve un poco más así. Es una cantidad dramática de trabajo adicional sobre lo que el marco de trabajo está haciendo. Entonces surge la pregunta, ¿marco de trabajo de formularios? Los formularios son fáciles. ¿Huh? Bueno, esto es lo que estoy diciendo. Si los formularios son solo marcado, interacción del usuario, controladores de eventos, gestión de estado, solicitudes, y aún así son difíciles de construir, entonces merecen su propio marco de trabajo. Esto es en lo que estamos gastando todo nuestro tiempo como ingenieros, al menos una parte significativa de él. Tal vez podamos mejorarlo. Por eso creamos FormKit y por eso estoy emocionado y apasionado por ello. FormKit es específicamente un marco de construcción de formularios. Es como un marco de trabajo completo específicamente para este caso de uso. No es una biblioteca de interfaz de usuario. Entonces, FormKit se trata mucho más de la arquitectura de su formulario, asegurándose de que toda la validación y todo lo demás estén juntos, en lugar de ser solo una biblioteca de componentes. Permítanme mostrarles a qué me refiero. Cuando me senté y estaba pensando en todas las características que hay en FormKit y quería asegurarme de cubrirlas todas, decidí comenzar a enumerarlas, hacer una lista rápida de todas ellas. Y ni siquiera terminé antes de darme cuenta de que esto es simplemente demasiado ridículo para caber en una charla de 20 minutos. Así que hoy vamos a hablar solo de cuatro de ellas. Está bien, y te dejo a ti que consultes la documentación de FormKit o si encuentras otro marco de trabajo de formularios, ve a verlos. Aquí están las cuatro cosas de las que quiero hablar. En primer lugar, la elección de tener un componente único para FormKit. ¿Qué significa eso y por qué lo hicimos? En segundo lugar, los valores de entrada se recopilan automáticamente. En tercer lugar, aplicar validación con una sola propiedad, y en cuarto lugar, la generación de formularios. Bien, comencemos con un componente único. ¿Qué queremos decir con eso? Bueno, fundamentalmente, un componente de FormKit es aproximadamente equivalente a la etiqueta de entrada en HTML. Así que si echas un vistazo aquí, tenemos un componente de FormKit de tipo casilla de verificación y eso es aproximadamente equivalente a la etiqueta de entrada de tipo casilla de verificación. Tiene sentido. Ahora, si quieres tener un select en HTML, esta es una etiqueta diferente. Pero en FormKit, sigue siendo el componente de FormKit. Y esto es aplicable a literalmente cada entrada que FormKit proporciona.

De alguna manera, suaviza la API de HTML. Cada input nativo de HTML forma parte del paquete principal de código abierto de Form Kit. Estamos hablando de botones, ruedas de color nativas, selector de fecha nativo, áreas de texto, texto, todas esas cosas que estás acostumbrado a usar en HTML forman parte de él, solo que con algunos superpoderes que Form Kit agrega.

Recientemente, también hemos agregado algunos de estos inputs profesionales de pago que no son nativos. Estamos hablando de cosas como autocompletado, inputs de calificación, repetidores, y así sucesivamente.

Entonces, ¿cómo se ve esto? Aquí tenemos un input de texto de Form Kit, simplemente decimos tipo texto. Y ahora podemos hacer algunas cosas que hacíamos en nuestro ejemplo anterior en HTML nativo y en vista nativa. Tenemos una etiqueta aquí, ayuda para el color favorito, algunos textos de ayuda con eso. ¿Y qué genera? Genera un marcado que se parece notablemente a lo que teníamos antes. Tiene algunas clases de envoltura apropiadas a su alrededor, tiene una etiqueta como puedes ver aquí, generó automáticamente un ID para mi input y luego lo vinculó semánticamente a mi etiqueta. Y hizo lo mismo para el atributo aria-described-by, como mencionamos antes. Y lo aplicó al texto de ayuda. Ahora puedes cambiar el tipo y automáticamente obtienes una salida renderizada diferente del mismo componente. Por ejemplo, en este caso lo cambié por una casilla de verificación y ahora obtengo una casilla de verificación que se está renderizando en esa ubicación. Y aquí puedes ver que hay un decorador de Form Kit porque si alguna vez has tenido que hacer casillas de verificación, sabes que estilizarlas es una pesadilla porque no puedes estilizar la casilla de verificación real en sí. Así que nosotros, los desarrolladores de Form Kit, queríamos facilitar eso. Por defecto, viene con este decorador que te permite hacer casillas de verificación con un aspecto agradable como esta.

Genial. ¿Y qué pasa si quiero hacer múltiples casillas de verificación? Bueno, en ese caso, simplemente puedes usar la propiedad 'options' y pasar las opciones que deseas. La salida renderizada que obtendrás será drásticamente diferente porque, para hacer múltiples casillas de verificación, es bastante complicado en HTML nativo. Técnicamente, deberías tener algo que las envuelva, como un fieldset, para que la accesibilidad sepa que estos inputs son parte del mismo grupo. Y aquí está la salida renderizada para múltiples opciones y se ve algo así, al menos con nuestro tema predeterminado incorporado, y funciona muy bien. ¿Cuáles son las ventajas del enfoque de un solo componente? En primer lugar, la curva de aprendizaje es muy sencilla. Básicamente, ya sabes cómo usar Form Kit si alguna vez has creado un formulario en HTML porque estamos copiando todos esos conceptos. Además, tiene una API consistente. Todos en tu equipo que trabajen en un formulario pueden verlo y entender en general lo que está sucediendo allí porque funciona de la misma manera en todos los inputs. La mayoría de las propiedades son las mismas.

Los componentes se ven iguales. La forma en que pasa los datos de ida y vuelta es la misma. Y de alguna manera, suaviza esas inconsistencias en HTML, ya sabes, cosas como un input que tiene el valor aplicado a través de 'value' versus un área de texto que tiene el valor aplicado como hijo del input en Form Kit. Esto es solo texto de tipo área de texto de Form Kit.

Ok, lo siguiente de lo que vamos a hablar aquí es que los valores de entrada se recopilan automáticamente. Aquí tenemos un formulario de vista tradicional. Tengo un controlador de envío. Estoy modelando la dirección, la línea de dirección, la ciudad, el estado y el código postal. Ninguno de estos es realmente necesario en Form Kit porque lo hace todo por sí mismo.

Así que voy a intentar una demostración aquí, abriré el playground y aquí puedes ver que este es un formulario equivalente. En Form Kit, solo tengo un formulario de tipo Form Kit y luego tengo todos mis inputs aquí abajo. Y para mostrarte de lo que estoy hablando, simplemente voy a extraer del slot predeterminado el valor del formulario, puedes hacer esto con cualquier input de Form Kit. Lo voy a hacer con el formulario y colocaré una etiqueta 'pre' aquí y mostraré el valor. Y como puedes ver, todos los valores del formulario se recopilan automáticamente y se los pasa automáticamente a tu controlador de envío. Eso es bastante ingenioso, pero donde esto realmente se vuelve emocionante es si quieres crear cualquier tipo de estructura.

En mi caso, voy a crear algo como 'address.view' porque quiero reutilizar estas piezas de la dirección. Voy a copiarlas y las pegaré aquí. No voy a usar nada más que eso en la configuración de la plantilla. No voy a usar nada más que eso. Y en este componente, simplemente haré un 'script setup' e importaré 'address' desde 'address.view' y luego lo renderizaré. Y lo genial es que mis valores siguen fluyendo automáticamente y puedo hacer esta anidación a cualquier profundidad. Y si quiero, incluso puedo agruparlos.

Por ejemplo, podría usar un grupo de tipo Form Kit y llamarlo 'name address'. Y simplemente envolveré mi componente de dirección en él, o podría poner este grupo en el componente de dirección. Ahora puedes ver que automáticamente en mi formulario obtuve el nombre de la dirección y todos los valores de mi dirección fluirán directamente debajo de ese espacio de nombres. Esta es una excelente manera de estructurar rápidamente tus datos. Algunas ventajas de recopilar esto automáticamente son que hay menos código innecesario y eso no solo significa menos trabajo, sino también menos oportunidades para errores. Form Kit maneja esto automáticamente por ti.

Entonces simplemente puedes construir tu formulario y luego saber que los data estarán donde se supone que deben estar cuando se supone que deben estar. Esto fomenta la reutilización como viste. Si quisiera tomar un modelo V estándar y aplicarlo a un componente de dirección como ese está bien. No es demasiado difícil. Pero tan pronto como empiezo a anidar eso debajo de componentes repetidos se vuelve realmente complicado porque tengo que pasar esos valores como el valor del modelo y los emisores a través de todos esos componentes y muy pronto voy a tener múltiples canales funcionando de arriba abajo a través de allí y se vuelve bastante difícil de debug. También evita el enlace bidireccional. Te darás cuenta de que no necesité usar V model en ningún lugar. Ahora puedes usar V model si quieres estar claro. Puedes usar V model con Form Kit pero no fue necesario en mi caso. Y si alguna vez has tenido que lidiar con un formulario realmente grande donde estás modelando cosas más complejas que un solo valor escalar, sabes que puede ser realmente difícil hacer eso. Puede haber problemas con bucles infinitos y recursión y cosas así que ocurren porque los objetos son fundamentalmente nuevos incluso cuando tienen los mismos valores.

OK. Aplica validación con una sola propiedad. Esto es bastante autoexplicativo, pero sabes aquí tengo algunas casillas de verificación de algunos sabores de helado y se renderizaría algo así y si quisiera agregar validación a eso, todo lo que necesito hacer es agregar validación igual y luego escribir las reglas de validación. Formkit viene con docenas de reglas de validación predefinidas y todas ellas tienen soporte de internacionalización para los mensajes que producen también.

Así que echemos un vistazo rápido aquí. Y efectivamente, aquí está mi entrada y puedo marcar estas casillas. No pasa nada realmente. Eso es genial, pero luego quiero agregar validación. Digamos que la validación es requerida. Y ahora, cuando marco una casilla y la desmarco, obtengo el mensaje `sabores requeridos`. Bien, y si quiero agregar otra regla, digamos que el mínimo es dos y voy a agregar tres reglas, debo decir que el máximo es tres. Y ahora, cuando comienzo a interactuar con mi formulario, puedes ver que si solo tengo uno, dice `no puede tener menos de dos sabores`. Marco 2, todo está bien, marco 3 y todo está bien, voy al cuarto y no puedes tener más de tres sabores. Y puedo agregar ese tipo de reglas de validación a cualquier entrada en Form Kit. Todas son compatibles de inmediato, incluso si creas tus propias entradas, automáticamente obtienen todo el soporte de validación. Y debo mencionar que la validación en la parte superior del formulario conoce automáticamente los estados de validación de todos los subelementos, por lo que puede detener el envío del formulario hasta que se complete la validación. Si ese es el comportamiento que deseamos.

Algunas ventajas. Nuevamente, la curva de aprendizaje es sencilla. Es tan simple. Estoy seguro de que básicamente has aprendido todo lo que necesitas saber sobre validación al ver eso. La API es consistente. Tu equipo no necesita buscar modelos de validación y otras complejidades. Solo necesitan mirar la entrada y ver qué es. Y el tercer beneficio es que las reglas de validación están ubicadas junto a las entradas en las que se utilizan.

Ok, y luego la última característica de la que quiero hablar, que es un tema en sí mismo, es la generación de formularios. Para generar formularios en form kit, tenemos algo llamado el esquema de form kit. Echemos un vistazo. El esquema de Formkit es un formato de datos serializable en JSON para almacenar la estructura del DOM e implementaciones de componentes, incluidos los formularios de formkit. Es un poco largo, pero veamos qué queremos decir con eso. Aquí hay un simple div de HTML, solo un div con `Hola mundo`.

Ahora podemos representar esto en el esquema utilizando algo como. Ahora esto no es JSON, pero puedes ver que es fácilmente serializable a JSON, solo $EL div y luego children hello world. Si pasáramos ese objeto al esquema de FormKit, en realidad renderizaría el mismo div. Pero, ¿por qué es importante? Bueno, eso es importante porque podemos tomar ese esquema y ponerlo en cualquier lugar, podemos ponerlo en la nube, almacenarlo en una base de datos, enviarlo por la red, construirlo, podemos hacer muchas cosas con él y luego usarlo para generar automáticamente marcado y formularios.

En el esquema de FormKit, hay tres elementos especiales que se pueden renderizar. Uno es un elemento DOM. Simplemente lo haces con el signo de dólar EL. El segundo es el signo de dólar CMP, que renderiza un componente y puedes pasarle props como lo harías con un componente de Vue. Y el tercero es un atajo, que te permite renderizar más rápidamente las entradas de FormKit. También podrías usar el signo de dólar CMP si quisieras, ya que FormKit es solo un componente. Pero lo que realmente lo hace poderoso son las expresiones. El esquema de FormKit admite expresiones reales. ¿Qué queremos decir con eso? Bueno, puedes escribir lógica booleana básicamente en tu JSON, igualdades, y y o, no igual, cosas así. Puedes soportar toda la aritmética, estamos hablando de suma, multiplicación, resta, matemáticas exponenciales, todo eso se puede escribir directamente en tu JSON. Admite llamadas de función, representación condicional, como renderizar esto o esto basado en alguna condición, representación de ranura. Echemos un vistazo a esto. Aquí tenemos un componente de esquema de FormKit y puedes ver que estamos pasando el esquema directamente en él, que es solo este pequeño objeto aquí. El formulario de FormKit tiene una etiqueta de envío y como hijo dentro del formulario tenemos un número.

Ahora, una pieza válida del esquema de FormKit es en realidad solo una cadena, por lo que siempre que comience mi cadena con un signo de dólar, le indica a este pequeño compilador que lo interprete en funciones de renderizado. Entonces, si solo pido, por ejemplo, el valor de mi formulario y la cantidad, esto automáticamente renderizará el valor de mi entrada y puedes ver que es todo reactivo porque lo renderiza a funciones de renderizado de Vue. Y eso no es todo, en realidad puedo escribir aritmética aquí mismo. Así que podría decir, sabes, por algún precio, la cantidad multiplicada por un precio, y aquí tienes, ahora estamos obteniendo valores reactivos renderizados en la página. Sin embargo, lo otro que estamos pasando al esquema de FormKit es este objeto de datos y es solo un objeto reactivo de Vue y solo tiene una cosa en él, tiene esos dólares. Y si miras, los dólares son solo la función de moneda INTL. Entonces, estoy obteniendo el formato USD y en realidad puedo llamar a esa función aquí mismo. Dólares, voy a pasar estos valores directamente a ella y efectivamente ahora estamos obteniendo números formateados. Y si quiero, puedo pasar otros valores también. Por ejemplo, digamos que el precio es, ya sabes, 233. Solo puedo hacer referencia al precio ahora, ahora que lo estoy pasando dinámicamente. Entonces, solo usando el precio del signo de dólar y eso coincide con lo que está en mi objeto dinámico y ahora tengo esto que se renderiza automáticamente. Eso es una mirada muy breve al esquema de FormKit. Me encantaría pasar mucho más tiempo hablando de esto, pero lo dejaremos para otro día. Entonces, nuevamente, esas son solo cuatro de las características que quería cubrir. Hay muchas más y realmente ayuda a construir tus formularios y hacer que sea mucho más fácil, lo que plantea la pregunta, ¿los formularios son fáciles? Es una pregunta muy válida y diría que realmente solo son fáciles si estás usando algo como un marco de formularios. Eso es todo por mi parte. Muchas gracias. Realmente aprecio haber tenido la oportunidad de hablar aquí. Tenemos la documentación en FormKit.com. Puedes seguirme en Twitter en JP Schroeder y el nombre de usuario de Twitter para FormKit es useformkit. Y solo un pequeño anuncio aquí, View School en realidad hizo una serie completa de cursos sobre FormKit, que puedes encontrar en viewschool.io. Así que muchas gracias.