Los formularios no tienen por qué ser complicados

Pero sin más preámbulos, los formularios. Entonces, lo primero que quiero que hagan es simplemente pensar en una buena experiencia de formulario. Todos hemos tenido malas experiencias de formulario, muy confusas y desordenadas. Pero cuando pensamos en buenas experiencias de formulario, probablemente pensamos en un viaje simple, una experiencia guiada para saber a dónde ir a lo largo del formulario. Y también algo que sea receptivo y rápido de usar.

Creo que el peor escenario es tener que retroceder en un formulario porque cometiste un error al principio. Entonces, si lo ponemos en un flujo ideal, casi como un viaje del usuario, estamos pensando en completar un campo, recibir una notificación si cometiste un error, idealmente lo antes posible, y luego algún tipo de progresión. Y una progresión puede ser pasar al siguiente campo, puede ser la siguiente página en el formulario si es un formulario de varias páginas, o puede ser la progresión final que es el envío.

Y esto es lo que parece actualmente en React cuando creamos formularios, lo cual es muy, muy diferente. En lugar de tener estos campos progresivos que son lo principal en lo que pensamos, en su lugar tenemos los formularios como lo principal en lo que pensamos, y metemos todo en un formulario desde el principio. Y es un poco extraño porque eso no es realmente lo que hacemos con React. Por lo general, si tenemos cosas que suceden en varias páginas o algo así, no pondríamos toda esa lógica en un solo lugar, pero con los formularios en este momento, lo hacemos.

Entonces esto me hizo pensar, ¿hay alguna manera de hacer un formulario donde no necesitemos poner el esquema en un solo lugar? ¿No necesitamos poner la declaración onSubmit en un solo lugar? ¿Y qué pasa si hacemos eso dinámicamente a medida que avanzamos como una unidad de usuarios que pasan por los campos y demás? Sí, eso es exactamente lo que quería intentar. Y hace aproximadamente un año y medio, comencé un proyecto llamado Fielder con el objetivo de probar algo así. Y quiero mostrarles las piezas y también mostrarles algunos ejemplos y ver qué opinan ustedes.

El objetivo final no es realmente hacer que la gente use Fielder. Es solo para que en el próximo proyecto en el que trabaje, no tenga que lidiar con formularios terribles porque todos ustedes han impulsado una nueva biblioteca que soluciona este problema. Entonces, sí, esta es una solución propuesta, pero no importa demasiado qué biblioteca la implemente.

Entonces, las piezas. Si queremos crear un gran formulario y no queremos tener que elevar todo al principio del formulario, lo primero que tenemos es el formulario. Pero la gran diferencia aquí es que esto es muy, muy simple. Es solo una amalgama de estado y estará en la parte superior del árbol de componentes. Y una vez que lo declaramos, lo olvidamos.

Lo siguiente es el campo y este es nuestro ciudadano de primera clase. Aquí montamos el campo, le damos alguna validación, le damos un valor inicial y eso es básicamente cómo diseñamos nuestros formularios con campos en lugar de con un solo formulario grande. Y finalmente, tenemos la progresión. Y podríamos pensar en esto como un onSubmit y definitivamente es un onSubmit, pero también puede ser un onProgress. Entonces, si pensamos en un asistente, si alguno de ustedes está familiarizado con eso, un formulario donde hay varias páginas y simplemente avanzas, generalmente queremos proteger eso tanto como queremos proteger esa declaración final de envío porque no hay nada peor, como dijimos, que tener que volver atrás en un formulario y corregir algo en otro lugar. Queremos proteger eso y evitar que ocurra la progresión. Entonces, sí, hay un ejemplo, pero también podemos tener algún tipo de progresión que no sea un envío. Genial.

Bien, les voy a mostrar algunos ejemplos. Entonces, vamos a trabajar con código y veamos qué podemos hacer con esas tres cosas. Primero, espero que puedan ver esto. Sí, es lo suficientemente grande. Tenemos un campo de nombre de usuario y queremos llenarlo con un valor y si el usuario cambia ese campo o intenta enviarlo y no hay ningún valor allí, queremos mostrar algún tipo de error. Entonces, los componentes de presentación están fuera del camino, eso es una charla completamente diferente. Lo primero que vamos a hacer es declarar nuestro campo. Bastante sencillo. Y luego agregamos nuestra validación. Y en este caso, como no nos importa el evento particular en el que estamos validando, simplemente vamos a verificar el valor y si no está allí, lanzamos un error. Y luego, como pueden ver más abajo, presentamos ese error cuando ocurre. Y finalmente, solo queremos proteger eso. Queremos asegurarnos de que se cumpla esa validación antes de permitir cualquier tipo de envío. Genial.

Entonces, ahora vamos a mezclar un poco las cosas. Tomemos lo que ya tenemos y agreguemos algo de validación asíncrona. A veces esto puede ser bastante complicado. Creo que con Formic, tendrías que hacer un onSubmit, que verifica, hace validación asíncrona, y luego escribe tus propios errores, o algo así. Pero, en nuestro caso, este es el único cambio. Porque todo está ubicado en un campo, simplemente se le dice al campo, oye, hay un evento de envío, y se llama a la función de validación. Y luego, simplemente decimos, okay, bueno, si es una validación de envío, vamos a devolver una promesa, que verifica si el nombre de usuario está ocupado. Si lo está, entonces lanzamos un error. Si no, retornamos, y luego la llamada a handle submit continuará y enviará. Y luego, sí, en este caso también, la única diferencia ahora es que solo queremos mostrar que estamos verificando que el nombre de usuario está ocupado. Entonces, esos son dos ejemplos aún bastante básicos, y realmente no demuestran por qué tener cosas acopladas a los campos en lugar de los formularios es realmente valioso. Creo que el branching es cuando eso comienza a cambiar. Si alguna vez has intentado hacer un formulario, que técnicamente es más de un formulario, y necesitas dividirlo según los valores del usuario, probablemente te hayas frustrado mucho con la mayoría de las bibliotecas de formularios. Y eso se debe a que se espera que elevemos toda esa lógica condicional en el formulario cuando declaramos el formulario. Pero luego también tenemos esa lógica condicional en nuestro enrutamiento, y se convierte en un lío y es muy difícil de mantener.

Este primer ejemplo de un formulario, el usuario proporciona una región. Y luego, si eligen el Reino Unido, se les pide que ingresen su té favorito. Si eligen EE. UU., entonces se les pide que ingresen su café favorito. Ahora veamos un ejemplo de eso. Primero, vamos a crear ese pequeño microcomponente que realiza la selección de región. Nada demasiado emocionante. Tenemos un campo que toma la región. Y poblamos el valor. Y luego lo llamamos onComplete. No te preocupes por eso por ahora. Volveremos a eso más adelante. Pero eso es solo algo para avanzar al siguiente paso del formulario. Ahora, en nuestro formulario del Reino Unido, porque solo queremos validar si tomamos esa ruta de bifurcación, no necesitamos preocuparnos por elevarlo y luego hacer mucha lógica condicional. En su lugar, simplemente montamos nuestros campos y agregamos nuestra validation. Y de manera similar, con el formulario de EE. UU., lo mismo exacto. Y lo bueno de esto es que, porque estamos haciendo nuestra validation en tiempo de renderizado y nuestro envío en tiempo de renderizado cuando estamos siguiendo esa ruta en lugar de forma prematura, realmente no necesitamos agregar ninguna lógica condicional. Porque si tomamos la ruta del formulario del Reino Unido, entonces nunca vamos a renderizar ese campo de todos modos. Por lo tanto, la validation no se aplicará.

Entonces es mucho más sencillo. Y el último paso ahora es simplemente tener ese componente de ruta que simplemente compone esto. Así que maneja la presentación de esos diferentes pasos y luego los ordena de la manera necesaria. Entonces puedes ver aquí, renderizamos nuestra selección de región en el primer paso. Eso luego llamará a onComplete. Y luego pasamos al segundo paso. Y aquí es donde comenzamos a hacer nuestra bifurcación. Y esta es la única bifurcación que hacemos.

Entonces, si piensas en ese ejemplo inicial con Formik, tienes tu onSubmit, que tendrá que bifurcarse si estás cambiando diferentes puntos finales para llamar. Y también con tu validation, también tendrás que tener esa lógica condicional en tu validation. Y luego, cuando renderices, también tendrás que hacer esa lógica de bifurcación nuevamente. Porque estamos manejando la presentación y la validation en el DOM, en el árbol de componentes, realmente no necesitamos bifurcarnos en ningún otro lugar que no sea cuando estamos renderizando. Y eso es un poco el secreto, en realidad.

Creo que esto es una de esas cosas que habría facilitado mucho las cosas. Y creo que simplemente hemos seguido, como comunidad, por este camino de tener formularios como esta gran entidad. Y creo que tal vez podría ser mucho más simple si los tratamos como más dinámicos. Así que básicamente puedes olvidarte de esto. Y puedes olvidarte de esto, toda esta bifurcación en esquemas y en envíos. Y en su lugar, simplemente puedes bifurcarte cuando estás renderizando y declarar la validation como lo harías si no estuvieras bifurcando. Así que sí. Eso es todo, realmente.

Si hubiera una resumen para esto, no es necesariamente echa un vistazo a Fielder, aunque definitivamente lo recomendaría si te parece interesante. Pero más bien es que veamos si podemos hacer que los formularios sigan más esta dirección. Porque creo que tiene mucho potencial. Gracias.

Gracias Andy. Ahora, si me sigues por favor hasta el salón de preguntas y respuestas. Tenemos algunas preguntas difíciles para ti. Sígueme.

Oh sí. ¿Quieres un poco de agua? Oh hombre, me encantaría un poco de agua. No trajimos cerveza. Creo que ese habría sido el momento adecuado. ¿Eran las 6 PM cuando empezaba? Sí, creo que algo así. Sí. Muy bien.

De acuerdo, primera pregunta antes de pasar a las preguntas de Sli.do. ¿Qué pasa con los forms de la ONU? ¿Qué? ¿Por qué? Quiero decir, como desarrollador, entiendo que tiene que haber una forma de hacer las cosas. Quiero decir, como desarrollador, entiendo que es algo básico. Tienes que hacerlo. Pero, ¿por qué te apasiona esto? No lo sé. Quiero decir, tenemos que hacerlo. Así que Yanni lo sabe. Tenemos un cliente que en realidad estaba tratando de resolver este problema exacto. Y tenían forms que se ramificaban constantemente. Y tuvieron una pesadilla tratando de elevar toda esa lógica de ramificación. Así que eso es lo que me metió en esto. Y luego de eso, supongo que es solo, no sé, cuando pasas tanto tiempo ignorando a tu pareja porque estás trabajando en forms, es como si tuvieras que seguir adelante ahora. Tienes que comprometerte. De lo contrario, ella tiene preguntas. Así que sí, no. Creo que el problema inicial que tuvimos con ese cliente realmente me impactó. Y eso es algo que realmente quería explorar. Genial. Muy bien, tenemos un montón de preguntas aquí del público.

Y también, tienes una nueva razón para ser una de mis personas favoritas. Fuiste mucho más rápido de lo esperado, así que hemos compensado por llegar tarde. Entra. Yo iré.

De acuerdo. Entonces, ¿cuál es tu té favorito? Oh, esa es una buena pregunta. Me gusta el té de menta. Oh, genial. Mi mamá solía darme té en un biberón, lo cual probablemente es lo más estereotípicamente británico. Eso también explica muchas cosas. Sí, sí. Pero no, el té de menta es mi favorito actual. Genial.

De acuerdo, vamos a responder esta pregunta técnica. ¿Has probado el formulario de gancho de React? ¿Y por qué usar CreateFielder? ¿Cuál es la deficiencia en Nexus en lugar del arte? No, es una buena pregunta. Eso salió un poco después de que comenzara a trabajar en este tipo de cosas. Y definitivamente toma algunos de esos enfoques para declarar la validación y la lógica de envío más abajo en un formulario. Aún así, hace mucho hoisting. Cosas como validar al cambiar, validar al salir, no se puede hacer eso en un campo. Tienes que hacerlo en todo el formulario y declararlo. Así que creo que definitivamente es un paso en la dirección correcta, sin duda.

Genial. Esta es la pregunta más popular. Lo siento, tengo que hacerla. No es técnica. ¿Has tenido alguna experiencia con el formulario de localización de pasajeros del Reino Unido y podrías arreglarlo, por favor? Vaya. ¿Es este el que hay que completar para entrar? Sí, cuando vienes al Reino Unido, tienes que completar este formulario. Y es una experiencia muy frustrante, especialmente en dispositivos móviles. Sí, no lo hice en el móvil. He tenido experiencia con eso.

No fue muy divertido. Inusualmente, el tema de los formularios gubernamentales es bastante bueno porque en realidad te obligan a hacer un campo por página, lo cual resulta ser bastante agradable. Pero sí, personalmente no he tenido mucha experiencia con eso aparte de usarlo una vez.

Genial. Entonces, ¿cómo funciona esto con TypeScript? ¿Puede funcionar con TypeScript? ¿Se puede obtener type safety con este enfoque? Creo que, para ser honesto, esto es algo en lo que no he trabajado en los últimos meses debido a los cambios de roles. Pero estoy bastante seguro de que hemos conectado algunas cosas para que cuando declares un nombre de campo, sepamos con qué tipos estamos trabajando. Lo único que mencionaría es que, al menos con Fielder, los tipos que almacenamos son básicamente lo que se pasa desde el elemento de entrada. Entonces, si estás usando un elemento de entrada numérico, eso aún devuelve una cadena. Así que lo almacenaremos como una cadena. Si quieres cambiarlo a algún tipo de entero o algo así, puedes hacerlo en el momento de enviar el formulario.

Genial. ¿Esto funciona con React Native? ¿Hay algo específico del DOM aquí, sabes? Sí, no, funciona con React Native. No fue muy sencillo, pero sí, funciona.

Genial. ¿Qué tuviste que hacer para que funcionara en React Native? ¿Cuál es la cosa específica de la plataforma aquí? Bueno, Kadi, si está en la audiencia, podría saberlo porque la molesté mucho. Sí, resulta que, quiero decir, también lo notarás, los controladores de cambio en React Native son básicamente todos tienen un nombre diferente para cada elemento. Aquí es onChange, luego es onSelect en otro lugar, y así sucesivamente. Entonces, para el soporte de React Native, porque no hay una biblioteca estándar para los elementos de formulario, se trata principalmente de que solo necesitas apuntar la biblioteca en la dirección correcta, si tiene sentido para la biblioteca que elijas. Pero hay documentación detallada al respecto.

Genial. Muy bien, esto es un poco abierto. Ya lo mencionaste antes con un proyecto en el pasado, pero ¿cuál es el contexto del peor formulario que has experimentado y cuál fue lo más frustrante? Básicamente, supongo que la pregunta es, ¿cuál es tu historia de origen? ¿Qué te convirtió en un bromista o en un Batman? Oh hombre, tenía 10 años, y me estaba registrando en Facebook. No, estoy bromeando. No. Para ser honesto, creo que mi problema fue más el lado técnico de las cosas, la implementación, en lugar de usar formularios. Solo lo enfoqué como una historia de usuario porque pensé que sonaría mejor como una historia. Pero en términos de responder a tu pregunta, creo que es una solución técnica, realmente, en lugar de una solución para el usuario. Pero no hay una gran historia jugosa donde te arrancabas los pelos y llorabas en medio de la noche, ¿sabes? No soy lo suficientemente extraño como para inventar eso en el momento. Pero si lo fuera, 100% crearía una historia de origen. Volveré a ti con un post o algo así.

Genial. Muy bien. Veamos si hay un par de preguntas más. Hay muchas preguntas que son un poco, no diría que están relacionadas con el tema. Pero, ¿qué usaste para crear tus fragmentos de código y animaciones? Oh, esa es una buena pregunta. Lo encontré ayer. Eso fue código. ¿Alguien puede decirlo en voz alta? Alguien lo va a saber aquí. ¿Qué es eso? Sí. Claro. Vamos con eso. Algo así. Sí. ¿Code Hike? No estoy seguro. Lo tuitearé. Es una excusa para seguirme.

Andy, ¿estás diciendo que hiciste tus diapositivas ayer? Digo que terminé mis diapositivas ayer. Terminé mis diapositivas esta mañana. La mayoría de nosotros no lo admitimos. Pero Andy aquí, ya sabes, dice la verdad y solo la verdad.

¿Cómo maneja Fielder el rendimiento y el re-renderizado? ¿Hay algo en particular que debas hacer? ¿Hay algún problema que tuviste que resolver? No. Entonces, una cosa en la que trabajé para asegurarme fue que la validación síncrona es síncrona. Y eso es cierto. Eso es algo que intenté contribuir a Formic antes de comenzar a trabajar en esto. Y no pude hacerlo simplemente porque había muchas cosas sucediendo en ese momento. Pero sí. Entonces, la validación síncrona es síncrona. No obtendrás esos estados incómodos en el medio donde la validación es verdadera, pero luego ocurre el evento de cambio. Entonces, la validación aún no se ha ejecutado.

Eso es solo para validación asíncrona. Cualquier cosa sincrónica es instantánea. Y hay un repositorio con una prueba de rendimiento. Entonces, si quieres compararlo con Formic, si te interesan las pruebas de rendimiento, entonces está eso. No puedo decir que realmente haya tenido un problema de rendimiento al renderizar formularios, al menos uno que requiriera pruebas exhaustivas. Así que me alegra que existan.

Sí. Sí. Definitivamente hay una casilla de verificación que puedes agregar en el readme de tu repositorio, la biblioteca de formularios más rápida. Oh sí, me gustan los números al menos. Exactamente. Bueno, creo que eso nos lleva a la siguiente pregunta aquí, que es cuál es el estado actual de la biblioteca Fielder. ¿Recomiendas que la usemos, dijiste. ¿Estarías bien si otra biblioteca ocupara su lugar? Totalmente, sí. Sí, ¿cuál es el estado del proyecto? ¿Recomendarías usarlo? ¿Lo usarías tú mismo? Recomendaría echarle un vistazo. Lo he usado yo mismo para un par de proyectos. Creo que sí, definitivamente diría que la gente lo pruebe, pero no sientas que es estable para producción. Hay un caso de uso que no está cubierto, que es cuando agregas nuevos campos a los formularios a medida que avanzas, agregas más, agregas más, agregas más. Básicamente, el problema con eso es que si declaras campos y usas el nombre como identificador único, entonces si todos tus campos tienen el mismo nombre, simplemente se sobrescriben entre sí. Entonces, si lo necesitas para algo así, tal vez piensa de otra manera. Pero fuera de eso, es bastante estable. Lo estaré manteniendo durante algunos meses más, al menos. Genial.

Muy bien, y terminemos aquí con una pregunta fácil. Alguien te la ha dejado muy fácil. ¿Dónde podemos encontrar tu proyecto, Andy? ¿Mis proyectos? ¿Como Fielder y demás? Fielder, sí, sí. Si buscas Fielder en línea. ¿Les estás diciendo que lo busquen en Google? Básicamente, sí, en Google. Sí, eso es exactamente. Sí, hay un sitio de documentación y cosas así. Pero en GitHub o si buscas en NPM Fielder o lo que sea.

Básicamente, en cualquier motor de búsqueda que puedas encontrar, busca Fielder, probablemente aparecerá. Realmente lo dudo. Si escribes Fielder, ¿alguien puede escribirlo rápidamente y ver qué sucede? Porque estoy bastante seguro de que no te dará una, creo que te dará un jugador de béisbol o algo así. Creo que estará en la primera página, porque pasé mucho tiempo, mucho tiempo haciendo renderizado del lado del servidor para que funcione para que Google realmente me clasifique en algún lugar que no sea la página 50, así que sí.

Muy bien, resolveremos eso fuera del escenario. Creo que es hora de seguir adelante. Muchas gracias, Andy. Sí, muchas gracias. Sí, fue genial hablar contigo. Lo aprecio, amigo. ¡Salud!