Los formularios no tienen por qué ser complicados

Rate this content
Bookmark

Por qué los esquemas de validación de formularios son malos para los desarrolladores y los usuarios, y cómo podemos solucionarlo!

20 min
22 Oct, 2021

Video Summary and Transcription

Andy Richardson, un ingeniero de software en GraphCDN, presenta Fielder, un proyecto destinado a simplificar la creación de formularios en React. Fielder permite un esquema de formulario descentralizado y lógica onSubmit, lo que facilita el manejo de la validación asíncrona. Elimina la necesidad de elevar la lógica condicional y simplifica la representación y validación. Se recomienda explorar la biblioteca Fielder, pero aún no es estable para producción. El orador enfatiza la importancia de ser veraz y aborda las capacidades de rendimiento y renderizado de Fielder.

Available in English

1. Introducción a los Formularios y Fielder

Short description:

Soy Andy Richardson, un ingeniero de software en GraphCDN. Nos especializamos en el almacenamiento en caché en los puntos finales de GraphQL. Visita chandyrichardson.com para obtener más información.

Vaya, qué introducción. Gracias, Yanni. Sí, como dijo Yanni, mi nombre es Andy Richardson, hoy hablaré sobre algunos forms. Soy un ingeniero de software actualmente en GraphCDN. Hacemos cosas bastante interesantes con el almacenamiento en caché en los puntos finales de GraphQL, así que si te interesa ese tipo de cosas, definitivamente échale un vistazo. Y sí, puedes encontrarme en línea, así que en chandyrichardson.com probablemente aparezca. Genial. Mi jefe dijo que no hice una declaración lo suficientemente grande sobre GraphCDN, así que ahí tienes, Max. Si también quieres obtener más información, él hizo una charla hoy temprano, esta mañana, sobre GraphCDN y lo que hacemos, así que definitivamente échale un vistazo.

2. Rethinking Form Design in React Development

Short description:

Los formularios deben proporcionar una experiencia de usuario simple, guiada, receptiva y rápida. React maneja actualmente los formularios de manera diferente, con los formularios como enfoque principal en lugar de los campos progresivos. Comencé un proyecto llamado Fielder para explorar una solución donde el esquema del formulario y la lógica onSubmit no estén centralizados. Permítanme mostrarles las piezas y ejemplos.

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.

3. Creando Formularios Excelentes con Fielder

Short description:

El objetivo final es proporcionar una solución para crear formularios excelentes sin tener que elevar todo al principio. Las piezas clave son el formulario, el campo y la progresión. Se mostrarán ejemplos para demostrar su uso.

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.

4. Agregando Validación Asíncrona a los Formularios

Short description:

Agreguemos validación asíncrona a nuestros formularios utilizando Fielder. Con Fielder, la función de validación se llama cuando hay un evento de envío, lo que facilita el manejo de la validación asíncrona. Esto elimina la necesidad de elevar la lógica condicional en la declaración y enrutamiento del formulario, simplificando el código y mejorando la mantenibilidad.

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.

5. Formularios, Validación y Renderizado

Short description:

El usuario proporciona una región y, dependiendo de la selección (Reino Unido o EE. UU.), se le pide que ingrese su té o café favorito, respectivamente. Los formularios para el Reino Unido y EE. UU. tienen su propia lógica de validación, eliminando la necesidad de lógica condicional. El componente de ruta maneja el renderizado de diferentes pasos y los ordena según sea necesario.

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á.

6. Renderizado y Formularios Dinámicos

Short description:

El último paso es tener un componente de ruta que componga los diferentes pasos y los ordene según sea necesario. Manejamos la presentación y validación en el DOM, eliminando la necesidad de lógica de bifurcación en varios lugares. Tratar los formularios como más dinámicos simplifica el proceso. Echa un vistazo a Fielder si estás interesado en explorar esta dirección.

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.

QnA

Pasión por los formularios de la ONU y preguntas del público

Short description:

¿Por qué te apasionan los formularios de la ONU? El problema de un cliente con formularios ramificados me llevó a explorar esto. Ignorar a mi pareja mientras trabajaba en formularios me comprometió a encontrar una solución. Ahora, pasemos a las preguntas del público.

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.

Favorite Tea and Q&A

Short description:

Fuiste mucho más rápido de lo esperado. ¿Cuál es tu té favorito? Me gusta el té de menta. React hook form y CreateFielder tienen enfoques diferentes para la validación y la lógica de envío. El formulario de localización de pasajeros del Reino Unido es frustrante, especialmente en dispositivos móviles.

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.

React Native Support and Origin Story

Short description:

El tema de los formularios gubernamentales es bastante bueno porque te obligan a hacer un campo por página. Con Fielder, los tipos que almacenamos son básicamente lo que se pasa desde el elemento de entrada. El soporte de React Native requiere apuntar la biblioteca en la dirección correcta. Mi problema fue más el lado técnico de las cosas, la implementación, en lugar de usar formularios.

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í.

Code Snippets, Slides, and Fielder Performance

Short description:

Hubo algunas preguntas sobre fragmentos de código y animaciones, pero el orador no pudo recordar la herramienta específica. El orador mencionó que terminó sus diapositivas ayer y enfatizó la importancia de ser veraz. Fielder maneja bien el rendimiento y el re-renderizado, y la validación síncrona es síncrona para evitar estados de validación incómodos.

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.

Fielder Library Status and Project Availability

Short description:

Eso es solo para validación asíncrona. Cualquier cosa sincrónica es instantánea. Hay un repositorio con una prueba de rendimiento. El estado actual de la biblioteca Fielder se recomienda para revisar, pero no es estable para producción. Agregar nuevos campos a los formularios puede causar problemas si todos los campos tienen el mismo nombre. El orador mantendrá el proyecto durante algunos meses más. Fielder se puede encontrar buscando en línea, en GitHub o en NPM.

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úsqueda de Fielder y Conclusión

Short description:

Cuando busques Fielder, debería aparecer en cualquier motor de búsqueda. El orador duda que tenga una alta clasificación, pero han puesto mucho esfuerzo en mejorar su visibilidad. Pasemos a la siguiente parte.

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!

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2022React Summit 2022
160 min
React at Scale with Nx
WorkshopFree
The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.
We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries.