Formularios escalables en Vue

Hola, soy UJSlive, y muchas gracias por venir a mi charla, Formularios escalables en Vue. Ahora, la escalabilidad plantea una pregunta de inmediato. ¿Qué es la escalabilidad? Y generalmente cuando pensamos en escalabilidad, pensamos en herramientas de backend, ¿verdad? Desde el lado del servidor, podría parecer como balanceadores de carga y escalabilidad horizontal versus vertical. Tal vez las solicitudes por segundo en una aplicación web tradicional sean la forma en que piensas en la escalabilidad, escalabilidad horizontal versus vertical, cosas así.

Pero hoy quiero hablar de un tipo diferente de escalabilidad. Y eso es en el lado del cliente. ¿Qué significa la escalabilidad en tu código del lado del cliente? En tu código de Vue, ¿qué significa la escalabilidad? Bueno, significa cosas como la reutilización de código y el tamaño de tu organización juega un papel, qué tan grande puede ser una organización que use tu código del frontend y el número de desarrolladores por proyecto podría ser una buena métrica clave para poder medir tu escalabilidad. ¿Funciona este código del frontend genial para un equipo de cinco personas? ¿Y para un equipo de 100 personas? Y este es uno de los impulsores clave detrás de Vue 3. Recientemente, en un podcast, Evan Yu dijo que Vue 2 tiene problemas de escalabilidad. Tenemos un producto Vue enorme y tenemos estos componentes enormes que nadie quiere tocar más. No sabemos cómo extraer y reutilizar las cosas. Interesante.

Entonces, usemos lo que Evan está diciendo. Pero primero, rápidamente, ¿quién soy yo? Mi nombre es Justin Schrader. Puedes seguirme en las redes sociales en JPSchrader. Y si me conoces, probablemente sea por una de estas herramientas de código abierto en las que he creado o en las que estoy involucrado, FormKit, Arrow.js, AutoAnimate, Tempo y Drag'n'Drop. Las últimas dos, Tempo y Drag'n'Drop, son completamente nuevas. Si no las has probado, deberías echarles un vistazo. Tempo es una especie de alternativa a Day.js o Date.fns y Drag'n'Drop es una biblioteca muy fácil de usar para arrastrar y soltar. Pero eso es suficiente sobre mí. Volvamos a lo que Evan estaba diciendo. Frontends escalables. Básicamente, creo que si destilamos lo que Evan está diciendo sobre un frontend escalable y lo que sabemos intuitivamente, podemos llegar a una especie de rúbrica para medir la escalabilidad. En primer lugar, creo que debería permitir la reutilización de código, una buena reutilización de código. Todos sabemos que esto es algo cierto. Cuando escribes código, deberías poder reutilizarlo de manera efectiva y eficiente en todo tu equipo, y eso es parte de lo que hace que el código sea escalable. Además, debería fomentar las mejores prácticas. Los frontends escalables deberían fomentar las mejores prácticas. Tu código no es muy escalable si, para agregar accesibilidad, requiere una reescritura completa. También debería ser accesible para todos los niveles de habilidad.

Esto es realmente importante cuando lo piensas, especialmente con un equipo grande. Cuanto más grande sea tu equipo, es más probable que no solo esté compuesto por un grupo de ingenieros front-end súper senior. No, es más probable que haya una gran diversidad de niveles de habilidad. Algunas personas son completamente nuevas y otras pueden llevar mucho tiempo haciéndolo. Un buen front-end escalable debería funcionar bien para todas esas personas. Todos deberían encontrarlo accesible.

Y finalmente, ¿es propicio para un equipo de desarrolladores? Esto es un resumen de lo que estamos diciendo aquí. ¿Cuántas personas puedes tener en los front-end para que sigan funcionando eficientemente? Creo que esto es quizás uno de los principales impulsores detrás del éxito de Tailwind, es el hecho de que cualquiera puede usar Tailwind y no tienes que volver a aprender todos los nombres de clases que existen en un proyecto existente. Puede haber miles de ellos. Tienes un conjunto estandarizado. Cualquiera puede entrar y hacer modificaciones. Saben que las modificaciones se limitan a algo local, y así sucesivamente. Esta charla no trata sobre Tailwind, pero quiero decir que creo que esa es una de las razones por las que se puede afirmar que Tailwind es escalable.

De acuerdo. Entonces, veamos los front-ends. Y aproximadamente, podemos dividirlos en dos categorías diferentes, ¿verdad? Tenemos cosas como sitios web, y luego tenemos cosas como aplicaciones. Y los sitios web son ricos en contenido. Son, ya sabes, tienen una interactividad mínima y una lógica empresarial limitada. Entonces, estás pensando en algo como un blog o algo así. Esos son sitios web.

Las aplicaciones, por otro lado, son las que impulsan Internet. Las máquinas comerciales. Son las cosas que nos permiten hacer algo en la web. Y son altamente interactivas. Tendrían, ya sabes, muchas formas diferentes de ingresar información en ellas. Son complejas en términos de lógica. Ejecutan aplicaciones empresariales completas. Estamos pensando en CRMs y CMSs. Y básicamente, hacen un uso extensivo de los forms. De hecho, hacen un uso tan intensivo de los forms. Realmente podrías llamarlos simplemente forms. Sí, técnicamente son aplicaciones, pero gran parte de lo que hacen es la entrada y salida de la información que está en ese arbitraje ocurre en el medio de los forms, los forms web.

Entonces, veamos un poco más de cerca estas aplicaciones/forms. ¿Cómo los vamos a implementar? Bueno, el Plan A siempre debería ser simplemente usar la API FormData, porque eso es lo que está integrado en el navegador. Entonces, ya sabes, utiliza la plataforma. Tiene validación nativa. Son 0 kilobytes de JavaScript, porque no estás enviando nada, no estás enviando ningún JavaScript al front-end. Y funciona, ya sabes, técnicamente con cualquier servidor. Desafortunadamente, todos tienen un plan hasta que les golpean en la boca, según Mike Tyson. Y creo que voy a estar de acuerdo con él, al menos en esto. La realidad es que la API FormData no es tan clara. Si la examinamos de cerca, veremos que esta idea de que utiliza la plataforma. Bueno, eso es cierto.

Pero la plataforma ni siquiera puede estructurar datos básicos. Así que vamos a tener que agregar algo a eso. ¿Qué tal la validación nativa? Bueno, sí, tiene validación nativa. Pero básicamente solo estamos hablando de, ya sabes, un puñado de reglas de validación. De lo contrario, también tendrás que enviar algo de JavaScript al front-end. 0 kilobytes de JavaScript, eso ni siquiera es realista, porque no tiene interactividad sin JavaScript. Ni siquiera puedes hacer algo tan básico como, ya sabes, un autocompletado o un repetidor o algo así sin JavaScript. Así que no es muy realista. ¿Qué tal funciona con cualquier servidor? En realidad, eso tampoco es cierto. Ni siquiera hay un analizador de cuerpo estándar. Tu API probablemente ya usa JSON, así que ahora solo estamos agregando complejidad adicional.

Bien, plan B, ¿qué más vamos a hacer? Bueno, no vamos a usar la API FormData. Probablemente vamos a usar Componentes de Formulario y hacer que envíe JSON estructurado. Examinemos un poco más los Componentes de Formulario, porque creo que aquí la mayoría de ustedes probablemente han tenido problemas en el pasado al crear sus aplicaciones. Los Componentes de Formulario son una gran idea. Nos permiten escribir formularios y entradas de formulario, por ejemplo, que tienen una marcación accesible. Podrías tener una validación realmente agradable en lugar de esa interfaz nativa un poco tosca que aparece. Podrías tener reglas de validación agradables en línea con un estilo encantador. Puedes usar entradas no nativas, cosas como autocompletados y selectores de opciones elegantes, seleccionadores de fecha, y así sucesivamente. Puedes tener props para personalizar. Y por supuesto, en el caso de Vue, incluso tienes la capacidad de usar vModeling en tus componentes. Puedes vModel directamente en un componente y obtener información de él y enviar información a él. Así que podría verse algo así. Aquí hay solo una entrada de texto. Imagino que casi todos ustedes han escrito una de estas en algún momento. Aquí vamos a definir un modelo. Estos son los datos que entran y salen. Nuevamente, dijimos que vamos a usar vModel. Entonces, alguien que use la entrada de texto podría usar vModel en la entrada de texto. Tenemos el valor aquí y luego lo usamos en el input que está dentro de allí.

Entonces vamos a utilizar vModel para ese valor. Y mira, estamos haciendo algunas cosas buenas para la accesibilidad. Tenemos un atributo for en la etiqueta, que está vinculado al ID aquí. Y tenemos algunos elementos DOM condicionales agradables aquí dentro. Si hay algún texto de ayuda, entonces vamos a mostrar el texto de ayuda, e incluso vamos a utilizar este aria-described-by para asegurarnos de tener comentarios accesibles en nuestro texto de ayuda. Y luego la forma en que realmente usamos esto en nuestra aplicación es bastante sencilla. Vamos a importar ese componente y lo vamos a utilizar.

Entonces aquí puedes ver que estamos definiendo nuestros datos de formulario como un gran objeto ref. Y aquí vamos a utilizar vModel para alguna propiedad de eso. Ahora, si miras aquí, puedes ver que estamos añadiendo un montón de clases en él. Así que aquí hay una clase externa, una clase de entrada, una clase de etiqueta, y así sucesivamente. Y luego estamos pasando cualquier error que necesitemos a través de él. Bien, vamos a medir esto según nuestra rúbrica aquí. ¿Permite reutilizar código? Por supuesto que sí. ¿Fomenta las mejores prácticas? Sí, viste que teníamos accesibilidad ahí, ¿verdad? Eso es bueno. Está fomentando las mejores prácticas. ¿Es accesible para todos los niveles de habilidad? Creo que utilizar la entrada de texto no es tan difícil. ¿Es propicio para un equipo de desarrolladores? Claro.

Bueno, intentemos reutilizar nuestra entrada de texto y veamos cómo se maneja esto. Dice que permite reutilizar código. Vamos a intentar reutilizarlo y ver cómo funciona. Así que aquí está nuestra entrada de texto. Y puedes ver que tiene un montón de clases. No queremos deshacernos de ellas. Así que aquí estamos remodelando. Tenemos una etiqueta de ayuda ID. Ahora llamaremos a este componente user.view y solo tendremos un nombre y un apellido. Bastante simple. Bien, ahora tenemos dos entradas de texto. Estamos reutilizando nuestro componente, nombre y apellido.

Ahora es posible que notes algo de inmediato aquí. Tenemos todos estos data, nombre, apellido y los errores para el nombre y apellido, que no están en nuestro componente. Así que vamos a tener que conectarlos. Así que volvamos a un nivel superior. Ahora estamos en nuestra app.view y vamos a intentar usar ese componente de usuario que acabamos de crear. Así que aquí puedes ver que podemos hacer algo como V model y podemos tener múltiples V models en Vue 3. Entonces vamos a hacer V model para el apellido. Vamos a hacer V model para el nombre y luego vamos a pasar los errores del apellido y los errores del nombre.

Bueno, no está mal, pero en realidad probablemente se vea algo más así, donde tenemos muchos valores y muchos eventos que se emiten y se desenfocan. Esto se llama prop drilling, donde tenemos un montón de información que tenemos que pasar a través de múltiples capas de nuestros componentes. Así que tomemos esto y veamos nuestra rúbrica aquí. Bueno, en primer lugar, creo que es justo decir que los forms son difíciles. Hay muchas cosas sucediendo dentro de este formulario. Básicamente, los componentes están manejando una pequeña parte de ello. Tenemos code de plantilla, entradas no nativas y accessibility. Esos fueron manejados bastante bien por nuestro componente, pero hay un montón de otras cosas sucediendo allí. ¿Permite la reutilización de code? Un poco. ¿Cómo fomenta las best practices? Hasta cierto punto, un poco. Aún así, lo hizo mucho más desafiante. ¿Es beneficioso para todos los niveles de habilidad? Diría que usar ese componente de usuario de la manera en que lo estamos haciendo allí en el lado derecho no es muy amigable para el usuario, ni propicio para un equipo de desarrolladores. Creo que esto va a fallar. Francamente, esto va a fallar. No estamos haciendo un buen trabajo en nuestra rúbrica de frontend escalable aquí. ¿Cómo podemos mejorar? Bueno, creo que primero debemos admitir que los componentes no son suficientes. ¿Hay una solución? ¿Hay alguna forma de hacer que los forms no se descompongan cuando se usan en equipos grandes? ¿Algún modo de crear ese componente de usuario de manera que sea fácilmente reutilizable? Bueno, creo que sí y creo que es utilizando un árbol de formularios dedicado. Permíteme explicar un poco más de qué estoy hablando. Tomemos básicamente lo que teníamos en nuestro ejemplo aquí en el lado izquierdo. Tenemos un formulario. Tenemos un usuario dentro del formulario. Tenemos dos componentes de entrada de texto y dentro de ellos muestro qué elementos DOM están allí.

Ahora podríamos simplemente dibujar esto básicamente como un pequeño árbol, un pequeño árbol general aquí. Tenemos el formulario. Luego tenemos el componente de usuario, dos componentes de entrada de texto, y luego tenemos un montón de elementos DOM debajo. Así que ahora hemos dibujado un árbol para esto. Curiosamente, la única parte de esto que realmente importa para el formulario es esto. Es un árbol muy simple, solo un formulario y dos entradas. Esa es realmente la forma fundamental o el árbol fundamental que representa nuestro formulario debajo. Y lo interesante es que HTML nativo realmente entendió esto desde el principio. Sabía que cuando estabas escribiendo tu DOM, el árbol del formulario sería una subpieza de ese DOM. El problema es que eso fue en 1995. Eso fue hace mucho tiempo. En 1995, la gente pensaba que esta era una forma atractiva de vender a los desarrolladores. Así que mucho ha cambiado desde entonces y desafortunadamente la especificación realmente no se ha actualizado en absoluto.

Entonces, ¿cuáles son algunas de esas limitaciones de cómo funcionan los datos básicos del formulario? Bueno, en primer lugar, no puedes estructurar los datos. No está rastreando ningún tipo de estado, estado de validez, etc. Las claves de los datos del formulario no son únicas. Entonces, si tengo dos entradas de nombre o dos nombres dentro de mi formulario, se enviarán datos duplicados. No puedes rehidratar un formulario. Entonces, si tengo un árbol de formulario complicado y coloco información en la parte superior, no se prellenará automáticamente mi formulario. Necesito conectar todo eso manualmente. La experiencia de validación es bastante deficiente. No puedes enviar errores al frente. No puedes modificar el comportamiento de entrada. Hay muchos problemas. Y es por eso que creamos FormKit. FormKit pretende ser una solución integral para los formularios, no solo enviando un montón de componentes de interfaz de usuario. FormKit intenta abordar la amplitud de los problemas de los formularios y lo hace de dos maneras. Primero, envía componentes. Entonces, en este caso, vamos a manejar esas cosas que son adecuadas para ser abordadas por componentes con componentes. Pero luego, y enviamos, deberíamos decir, enviamos cada entrada de formulario. Cada entrada de formulario nativa viene con componentes que automáticamente tienen cosas como texto de ayuda, atributos ARIA, etc., para asegurarnos de que sean accesibles. También enviamos un montón de elementos turbocharged, cosas que no vienen nativamente en HTML, como entradas con máscaras y menús desplegables, etc. Y esos son parte de nuestros complementos de pago. Pero todo el resto de este conjunto de problemas se resuelve con una arquitectura única de árbol. Quiero hablar más sobre eso. Tomemos nuestro ejemplo aquí. Este es nuestro, ya sabes, reutilizado. Tenemos nuestra entrada de texto y la estamos reutilizando con este componente de usuario. Y voy a convertir esto a FormKit. En primer lugar, voy a tomar mi formulario externo y voy a decir tipo de formulario FormKit. Y luego este usuario aquí, voy a eliminar todas las vinculaciones, todas ellas. Y simplemente decir componente de usuario. Y luego ese componente de usuario se vería algo así.

Tendría un tipo de texto FormKit, nombre y un tipo de texto FormKit, apellido. Y ya está. Eso es todo. Todos los data fluyen automáticamente desde los padres al hijo. Te darás cuenta de que no hemos usado vModel en nada en el usuario. Forman automáticamente parte del árbol del formulario y funcionarán sin problemas, incluyendo cosas como agregar reglas de validación. Si quieres obtener los datos de tu formulario, solo tienes que poner un controlador de envío aquí y tus datos fluirán automáticamente allí, estructurados de la misma manera en que se estructuraron. Así que obtendrás tu nombre y apellido. Y, por supuesto, puedes modificar eso aún más.

Digamos que quiero que el nombre sea una subclave y tener datos estructurados debajo de eso de el nombre y apellido. Bueno, para hacer eso, solo tengo que volver a mi componente de usuario y envolverlo en lo que llamamos un grupo. Entonces, tipo grupo, y tiene su propio nombre. Y ahora tenemos datos correctamente estructurados. De acuerdo. Ahora, si quiero poner validación aquí, solo tengo que poner una propiedad de validación. ¿Cómo se ve eso? Esto es lo que está sucediendo básicamente. Tenemos un árbol de formulario que se ve así. Tenemos un formulario y eso se representa aquí por este nodo. Pero luego tenemos este componente de usuario. Y es interesante porque el componente de usuario realmente no hace nada más que estructurar aún más mi código. Lo he dibujado aquí, pero realmente no significa nada para el árbol del formulario. Al igual que todos esos elementos DOM no significan nada para los datos del formulario, no significa nada. Y luego dentro de aquí tenemos un grupo.

Ahora, ¿qué pasa si quiero cambiar esto de alguna manera? Bueno, simplemente podría agregar, digamos un tipo número, y eso se registraría automáticamente como parte de mi árbol de formulario. Y si quiero complicarlo un poco más, podría tener algunos datos de matriz y puedo usar una lista para eso. En FormKit, una lista es una matriz de información. Aquí tengo un select y una casilla de verificación y eso se registraría automáticamente en mi árbol de formulario. No se requiere ninguna configuración adicional aquí. Estos se registrarán automáticamente en mi formulario de tipo FormKit y tendrán el flujo de datos. Te darás cuenta de que no necesitamos pasar propiedades ni eventos arriba y abajo de la cadena para que funcione.

De acuerdo, mostrar es mejor que contar, así que voy a hacer una demostración muy rápida para darte una idea de cómo puedes usar esto en realidad. Así que déjame iniciar esto. Lo que vamos a hacer es crear un pequeño CMS en Nuxt. Así que déjame ir aquí.

De acuerdo. Aquí puedes ver un sitio web muy simple. Tiene un héroe de página de inicio. Tiene una cita destacada. Tenemos una llamada a la acción y una tabla de precios y un pie de página. Y si voy a la página de edición de esta sección, puedes ver cómo se construye esta página. Es solo un formulario grande, antiguo y aburrido. Y si veo el code de este formulario grande, antiguo y aburrido, se ve algo así. Tengo una forma de obtener información del backend. Puedes ver aquí mismo, estoy obteniendo información. Esto es solo un almacén de clave-valor, que es algo que puedes hacer de forma predeterminada con Nuxt. Y luego aquí abajo, tengo un formulario de tipo FormKit y simplemente un grupo doloroso de campos. Aquí tengo el título de la página y el slug de la página, y esta es una página larga, larga de formularios.

Ahora, diría que esto no es tremendamente accesible. Es un poco difícil ver dónde están todas las piezas y las partes. Así que lo que voy a hacer es reemplazar esto con componentes. Así que podría recortar, por ejemplo, esta llamada a la acción aquí, podría simplemente eliminar eso. Y ahora aquí arriba, puedes ver que lo he puesto en un componente que tiene exactamente lo mismo, llamada a la acción. Así que voy a hacer eso con todos estos. Y puedes ver aquí que tengo detalles de la página, héroes del editor, testimonios del editor, y así sucesivamente. Y puedes ver lo que hay dentro de estos son secciones muy simples que simplemente tienen sus propias citas destacadas y demás. Lo siento, estas secciones del editor aquí. Solo tienen sus propias entradas de form kit, testimonio, precios, y así sucesivamente. De acuerdo, muy simple. Pero ahora, todos son parte de mi formulario y te darás cuenta, nuevamente, que no tengo que hacer ninguna prop drilling o enlace de modelo ni nada parecido. Y si vienes aquí y actualizas esta página, notarás que todo se rehidrata exactamente como debería ser.

Todos los data fluyen hacia donde se supone que deben ir. Y funciona. Así que si quisiera actualizar algo en esta página, se guardaría automáticamente y estaría disponible en la página de inicio. Pero eso no es particularmente emocionante porque quiero poder tener una experiencia similar a un CMS. Y eso también es muy fácil de hacer. Solo voy a ir a mis pequeños fragmentos de código aquí y copiar esto para que podamos verlo. Entonces, aquí, lo único que voy a hacer es tener un repetidor de tipo kit de formularios llamado secciones. Y un repetidor es exactamente lo que suena en FormKit. Y luego, dentro de aquí, voy a tener una pequeña entrada de radio que te permite elegir qué tipo de sección quieres tener. Y luego renderizará uno de esos componentes, uno de estos componentes que vimos anteriormente, ya sea detalles de la página, editor de héroes, y así sucesivamente, utilizando la etiqueta de componente de vistas. Entonces, si guardo esto, ahora puedes ver que en realidad tengo algo que se parece un poco a un CMS real. Tengo mi sección de la página de inicio, mi testimonio. Puedo reordenarlos si quiero. No creo que quiera. Voy a poner eso de nuevo en la parte superior. Y si guardo esta página, debería funcionar. Aquí, déjame cambiar mi imagen por un escritorio. Ahora también notarás que se crearon automáticamente estas secciones. Así que podría agregar otra sección aquí y decir que quiero tener otro panel de precios o digamos que quiero tener un testimonio aquí abajo. Esto es realmente genial. Vamos a guardar eso. Y luego lo único que necesito hacer es asegurarme de que mi frontend ya no esté renderizando directamente cada uno de estos componentes, sino que en su lugar haga básicamente lo mismo y simplemente haga algo como un V4. Entonces aquí puedes ver un componente con un V4 en él. De acuerdo, ahora solo tengo que obtener ese mapa de componentes, pegarlo aquí. Ahora, si vengo aquí, puedes ver que está cargando mi sitio de la manera que me gustaría que lo haga. De acuerdo, eso fue una mirada rápida a cómo funciona el árbol de formularios de Form Kit. Así que vamos a revisar según la rúbrica aquí. ¿Habilitamos la reutilización de code? Absolutamente, de manera muy, muy sencilla. ¿Cómo fomentamos las best practices? Definitivamente se fomentan las best practices. De hecho, en Form Kit, se aplican porque proporcionamos todo el DOM accesible por ti.

¿Es accesible para todos los niveles de habilidad? Literalmente no puedo imaginar que sea más fácil. Si hay una forma de hacerlo más fácil, queremos hacerlo. ¿Y es propicio para un equipo de desarrolladores? Sí, absolutamente. De hecho, esa es una de las razones por las que usamos un solo componente, para que sea increíblemente fácil de aprender. Todo lo que necesitas hacer es cambiar el tipo.

Ahora, antes de despedirme, quiero mencionar rápidamente el esquema de Form Kit. Esta es una de las características favoritas de la gente. Te permite básicamente serializar tus componentes y tus forms como JSON. Aquí puedes ver que podemos hacer elementos del DOM, componentes y atajos. Y aún más poderoso es que puedes escribir lógica en tu JSON. Cosas como lógica booleana y llamadas a funciones aritméticas, todo eso se puede escribir directamente en JSON.

Me encantaría mostrarte más, pero tengo que despedirme. Muchas gracias. Me encantaría que me siguieras en JPSchrader y echaras un vistazo a algunos de estos proyectos geniales, incluido Form Kit. Y un saludo a Vue School, ellos hicieron un curso completo sobre Form Kit. Esa es una excelente manera de comenzar si te preguntas cómo. Muy bien. Muchas gracias. Entonces, la pregunta fue, ¿con qué frecuencia usas Form Kit? Las respuestas fueron siempre aún no, pero quiero intentarlo y a veces. Así que sí, no muchas personas lo han usado todavía, pero están muy emocionadas por probarlo. ¿Tienes algún comentario? Sí, creo que eso es más o menos lo que esperaría. Somos un proyecto relativamente nuevo. Y si he aprendido algo sobre los desarrolladores, es que les lleva mucho tiempo adoptar alguna nueva tecnología porque la necesitan en su próximo proyecto. ¿Verdad? Alguien escuchó sobre Form Kit hoy por primera vez, seguro. Y no lo van a usar en su próximo proyecto. Ni siquiera lo usarán en el siguiente siguiente proyecto porque no es uno con muchos formularios. Pero cuando llegue el próximo proyecto con muchos formularios, entonces recordarán, oh, sí, había esa herramienta de la que escuché una vez. Y aparecerá. Así que sí, creo que eso es más o menos lo que esperaría. Es lo más importante para dar visibilidad a algunas cosas para que la gente lo sepa.

Y como dijiste, sí, lo recuerdo como un poco de PTSD, como, oh, sí, recuerdo a Justin. Bueno, recuerdo que hace un año, cuando estábamos en, no recuerdo dónde, Ámsterdam o algo así, alguien hizo una encuesta en el escenario y fue como un 10% de las personas habían escuchado alguna vez el nombre de Form Kit antes. Nadie ni siquiera había oído hablar de él. Así que el hecho de que algunas personas lo estén usando un año después, estoy bastante contento. Siempre es agradable cuando las personas usan tu producto.

¿También crees que hay una consideración de estabilidad que las personas podrían tener en cuenta antes de cambiar o adoptar la herramienta? Sí, probablemente. Tuvimos nuestro lanzamiento 1.0 en, creo que fue en septiembre u octubre. Así que ha sido 1.0 durante menos de un año en este momento. Pero ahora es bastante estable y funciona sin problemas.

De acuerdo. Te deseo lo mejor. Gracias. Pasemos a las preguntas y respuestas. Entonces, la primera de Daniel, actualmente uso vValidate. ¿Cuáles serían las principales ventajas de Form Kit en comparación con vValidate? Quiero una razón para considerar el cambio. Claro. Buena pregunta. vValidate y Form Kit probablemente tienen, diría yo, la mayor superposición que existe. Donde trazaría la línea es que vValidate se centra mucho más en la validación, aunque también realiza alguna agregación de datos. Y Form Kit está destinado a ser una solución integral para los formularios. Ya sea que se trate de estructuras extremadamente anidadas y repetidores, y la capacidad de aplicar validación en el backend donde sea necesario, ya sea crear entradas personalizadas que no se ajusten a un molde, pero que luego puedas reutilizar en cualquier lugar. Y luego lo que hablamos en esta charla hoy, creo que es particularmente único donde puedes crear un componente lleno de entradas de Form Kit y luego puedes reutilizar ese componente en cualquier lugar dentro de otro formulario sin necesidad de hacer ningún enlace. No necesitas pasar props con los valores. No necesitas pasar la validación. No necesitas pasar las reglas. No necesitas pasar nada de ese tipo de cosas de arriba a abajo. Esas relaciones se establecen automáticamente para ti y se manejan en general. Incluso cosas como complementos. Si quieres tener un complemento en un formulario determinado que pueda pasar automáticamente a un componente secundario sin necesidad de pasarlo por props. Esos son algunos de los aspectos únicos.

Y luego, por supuesto, Form Kit incluye los elementos del DOM. Así que es un poco más como una biblioteca de interfaz de usuario en ese caso, donde realmente incluimos un montón del HTML, para que también sea accesible de forma predeterminada. Sí. Sí. El prop drilling es realmente lo peor. Voy a responder, proponer dos preguntas de una vez. ¿Qué tan compatible es Form Kit con bibliotecas como Beautify y PrimeView? ¿Funcionan bien juntas? Sí. Buena pregunta. Así que hay un poco de trabajo que debes hacer para envolver cualquier componente que vayas a usar en Form Kit. Muchas personas ya han hecho esto. Por ejemplo, en Beautify o PrimeView, sé que alguien ya escribió un envoltorio de PrimeView alrededor de Form Kit que cualquiera puede usar. Y en Beautify, hay algunos de ellos, aunque en realidad estamos en medio de escribir nuestro propio envoltorio oficial de Beautify. Así que esas cosas se volverán más fáciles con el tiempo. Pero sí, puedes tomar básicamente cualquier componente, incluido tu propio componente, y luego simplemente llamar a Create Input en él y funcionará. Sí. Perfecto. Una rápida. ¿Form Kit admite TypeScript? Sí, Form Kit. Hay tanto TypeScript. Son páginas y páginas de TypeScript. Perfecto. Pero sí, básicamente sí. ¿Maneja la validación en el backend? Esa es una gran pregunta. Entonces, la validación en el backend te permite enviarla donde quieras. Y cuando hay un error que se envía de vuelta al frontend, te permite colocar esos mensajes de error en cualquier parte de tu marcado. Así que si tienes un mensaje de error que está en el segundo elemento repetidor del campo de correo electrónico, puedes colocarlo fácilmente, desde el lugar donde recibiste los errores, de vuelta en allí. En este momento, en realidad no estamos realizando ninguna validación en el backend a menos que elijas usar Zod, que tenemos un complemento oficial para, y luego puedes reutilizar tu Zod en el backend y el frontend. Sí. OK. Perfecto. Sí, eso es todo en cuanto a preguntas. Gracias nuevamente por tu participación y por todas esas respuestas. Y sí, nos vemos en otro evento de Vue.js AI. Te deseo un día increíble. Seguro que lo tendrás. Adiós. Muy bien.