Detectando estáticamente errores en aplicaciones de React con TypeScript y ESLint

Rate this content
Bookmark
Slides

Existen herramientas increíbles que te brindan una excelente seguridad de tipos. Pero cuando llegas a la obtención del lado del cliente, las cosas se vuelven salvajes. Incluso si tienes un backend perfectamente tipado, pierdes la información de tipos durante la comunicación del lado del cliente. Sí, puedes usar GraphQL o protobuf y generar tipos, pero... ¿qué tal si te digo que hay una manera más fácil? ¡Una forma que te permite desarrollar tus aplicaciones de manera más fluida que con REST o GraphQL? ¿Cómo? ¡RPC! Saluda a la máxima productividad con una experiencia de desarrollo fantástica.

21 min
05 Dec, 2022

Video Summary and Transcription

Esta Charla explora las herramientas de análisis estático para JavaScript y TypeScript, centrándose en la detección de errores con TypeScript y ESLint. Se enfatiza la importancia de la comprobación de tipos y la ampliación de las reglas recomendadas. La Charla también profundiza en reglas específicas de ESLint y proporciona ejemplos de código para demostrar su uso. Se destacan las ideas proporcionadas por ESLint impulsado por TypeScript. Se discuten las promesas flotantes y las promesas mal utilizadas, junto con recomendaciones para manejar excepciones y recursos. La Charla concluye ofreciendo recursos y soporte para una mayor exploración y desarrollo.

Available in English

1. Introducción al Análisis Estático

Short description:

Soy Josh Goldberg, un mantenedor independiente de código abierto que se enfoca en herramientas de análisis estático para JavaScript y TypeScript. La programación puede ser intimidante debido a suposiciones incorrectas y explicaciones deficientes. Muchas personas encuentran difícil imaginar el uso de una computadora o aprender a programar porque crecieron pensando que las computadoras son difíciles. Las herramientas de análisis estático a menudo se perciben como intimidantes, pero no tiene por qué ser así. Los conceptos que explicaré hoy son relevantes y aplicables para sus proyectos.

en herramientas de análisis estático para JavaScript y TypeScript. Específicamente, trabajo en TypeScript ES, que te permite ejecutar ESLint en tu código TypeScript. También soy el autor del libro publicado recientemente por O'Reilly. Y sinceramente, React Debra Lynn, tengo algo de enojo dentro de mí. Tengo muchos problemas con la industria tecnológica, y ahora los van a escuchar. Como desarrolladores de software, nos hemos acostumbrado a que muchos de nuestros amigos y familiares nunca van a entender lo que hacemos. No nos gusta. No estamos de acuerdo con su falta de voluntad para aprender, pero algunas personas simplemente no pueden o no quieren entender las computadoras o incluso aprender a programar. Aquí hay una cita real de mis fantásticos y amorosos padres: no sabemos qué es el código TypeScript, pero estamos muy orgullosos de Josh y estamos seguros de que será un libro encantador. Refiriéndose, por supuesto, a Learning TypeScript, disponible en Amazon O'Reilly y otras tiendas, cómpralo hoy.

De acuerdo. La programación puede ser falsamente intimidante, el problema no es que el concepto de usar una computadora sea inusualmente difícil por sí solo, muchas personas pueden entender eso, es que muchas personas asumen incorrectamente que es difícil. Muchas personas que no son capaces en tecnología encuentran difícil imaginar el uso de una computadora en absoluto, incluso, Dios no lo quiera, incluso aprender a programar, y por lo tanto se sienten intimidados y desanimados. Una gran fuente del problema es que muchas personas crecieron acostumbradas a la idea de que las computadoras son difíciles, inventos imposibles de entender. Y luego tienen a un montón de personas gritándoles, oh, envía un archivo, abre Facebook, adjunta un archivo, presiona iniciar, lo que sea, eso es difícil. ¿Qué demonios? Y el problema empeora porque muchos desarrolladores, porque muchas personas, no explican bien temas técnicos o complejos. Es algo con lo que muchos de nosotros luchamos. Y una persona no técnica solo puede pasar por tantas explicaciones malas, descripciones complicadas, antes de decidir que el problema soy yo, simplemente nunca voy a entender esto.

Y que eso sea contexto para ustedes, mientras hablo de dos problemas, cambio de contexto y malas explicaciones, para el análisis estático, herramientas que analizan tu código sin ejecutarlo. Porque en paralelo, muchos desarrolladores de software experimentan esa misma intimidación falsa, incluso cuando ya han aprendido a programar, saben cómo usar computadoras, cuando intentan pensar en el análisis estático. Durante muchos años, se pensó que el análisis estático era solo competencia de académicos o ingenieros de lenguaje hardcore. Y cuando intentaron buscar recursos para el análisis estático, lo que obtuvieron fueron explicaciones teóricas de alto nivel, trucos académicos, cosas que son teóricas en lugar de introductorias y prácticas. Pero eso no es cierto. Tal vez nunca lo fue. Ciertamente no lo es ahora. El análisis estático no tiene por qué ser intimidante. El panorama del análisis estático hoy en día, especialmente para bases de código modernas de TypeScript, les prometo que es mucho más accesible de lo que nunca ha sido. Creo que encontrarán que los conceptos que les voy a presentar hoy son muy relevantes y aplicables para sus proyectos, e incluso podrían disfrutar usándolos cuando los

2. Detectando Errores con TypeScript y ESLint

Short description:

Combinar ESLint y TypeScript permite detectar defectos y errores de aplicación a través de errores reales en tu código. TypeScript comprende el significado de tu código y proporciona API para tomar decisiones de linting más informadas. Analizaremos un ejemplo de componente para explorar posibles problemas y la importancia de la comprobación de tipos con TypeScript. Usando el complemento TypeScript ESLint, analizaremos nuestro proyecto y pondremos los tipos de objeto disponibles para las reglas de ESLint. Extenderemos las reglas recomendadas tanto del núcleo de ESLint como de TypeScript ESLint para obtener mejores resultados.

volvamos a trabajar en ellos. Así que este análisis estático es increíble, también conocido como detección estática de errores de aplicaciones React con TypeScript y ESLint. Conmigo, Josh Goldberg. Te mostraré cómo combinar ESLint y TypeScript permite detectar grandes cantidades de defectos y errores de aplicación, como código no utilizado o código asíncrono innecesario, a través de errores reales en tu código, que encontrarás antes de que tu aplicación se rompa misteriosamente solo para algunos usuarios en algunos momentos.

Empecemos. Primero, un poco de contexto sobre las propias herramientas, TypeScript y ESLint. ¿Por qué querrías mejorar las reglas de ESLint con TypeScript en primer lugar? ESLint solo ve la sintaxis cruda de tu código. Puede verificar problemas rudimentarios, como variables no utilizadas, violaciones de convenciones de nomenclatura, y así sucesivamente, pero realmente no entiende lo que ese código significa. TypeScript entiende lo que ese código significa. Hace una inmersión profunda en tu código, entiende tus tipos, entiende lo que todo debe ser, y luego tiene API que podemos usar en nuestras reglas de linting para tomar decisiones mucho más informadas basadas en esos tipos. Hoy te guiaré a través de algunos componentes que se parecen mucho a este ejemplo de mi botón, y vamos a jugar uno de mis juegos de programación favoritos, ¿Es esto seguro? Se supone que este componente debe recibir aproximadamente dos props, he ocultado todo lo que no es relevante. Acción e hijos, esta acción en particular es relevante e interesante, se supone que es una llamada de función entre dos registros en la consola. A primera vista, este código parece seguro, está bien, recibimos dos props, renderizamos los hijos, pasamos este callback de clic a un botón, todo está bien. Pero sin el profundo conocimiento de TypeScript sobre el sistema de tipos y este código, no tenemos forma de hacer linting sobre una gran cantidad de posibles problemas. Estamos confundidos. Tal vez las acciones asíncronas no están permitidas en esta aplicación. Tal vez la acción no siempre se proporciona. Si es una función en primer lugar, lo cual no sabemos, tal vez se supone que debe recibir argumentos. Tal vez realmente queremos manejar explícitamente las promesas rechazadas. Hay todo tipo de cosas que no podemos saber sin entender cuál es el tipo real de nuestro objeto. Cuáles son los tipos en nuestro código. Así que ahora vamos a hacer algunas comprobaciones de tipos. Usaremos TypeScript para analizar nuestro proyecto completo y entender los posibles tipos de objetos. Y luego haremos que esos tipos estén disponibles para las reglas de ESLint usando el complemento TypeScript ESLint. Ahora, si has configurado ESLint en código TypeScript antes, es probable que hayas hecho algo como esto. Has instalado el paquete analizador de TypeScript ESLint, que es el analizador que permite a ESLint y, dato curioso, también a Prettier, leer la sintaxis de TypeScript en tus archivos. Y tal vez también hayas instalado el complemento ESLint de TypeScript ESLint. El paquete que contiene un montón de reglas de linting adaptadas al código de TypeScript. Es posible que hayas configurado en tu archivo de configuración de ESLint, la configuración del analizador y el complemento. Si todo esto es nuevo para ti, dato curioso, así es como se hace. Pero hay otro paso que recomiendo que tomen muchos proyectos de código, que es extender las reglas recomendadas tanto del núcleo de ESLint como de TypeScript ESLint.

3. Explorando las Reglas de TypeScript ESLint y Ejemplo de Código

Short description:

Para la mayoría de los proyectos, se recomienda utilizar las reglas estándar tanto del núcleo de ESLint como de TypeScript ESLint. Sin embargo, las reglas recomendadas de TypeScript ESLint no incluyen reglas que requieran información de tipos, ya que pueden ralentizar el proceso de linting. Para habilitar estas reglas, puedes extender el conjunto de reglas recomendadas, configurar las opciones del analizador y especificar tu archivo tsconfig. Ahora, pasemos al código. Analizaremos una aplicación de demostración llamada TypeScript ESLint React demo, que es una aplicación simple de create-next-app. Tiene una página con botones que incrementan un contador de llamadas y cambian el color de fondo de la página. La primera regla que exploraremos es awaitAvailable, que verifica si se utiliza la palabra clave await en un valor que no está disponible. Ahora, veamos el ejemplo de código en nuestra página de inicio, donde tenemos una función de acción de ejemplo que establece el estado de color e incrementa el contador de llamadas. Esta función es utilizada por nuestros componentes await thenable.

ESLint y TypeScript ESLint. Para la mayoría de los proyectos, generalmente se recomiendan las buenas reglas estándar recomendadas de ambos. El núcleo de ESLint habilita cosas en todo JavaScript, mientras que las reglas de TypeScript ESLint están adaptadas al código de TypeScript, y estas son excelentes piezas de información. Recomiendo usarlas. Pero, un detalle, no incluimos reglas que requieran información de tipos en los conjuntos de reglas recomendadas de TypeScript ESLint, porque solicitar información de tipos a TypeScript hace que tu linting tarde un poco más y requiere una configuración adicional, por lo que si deseas habilitar esas reglas, puedes extender el conjunto de reglas recomendadas que requieren comprobación de tipos, configurar y agregar la opción del analizador 'project' a tu configuración, apuntando a tu tsconfig. Esto permite que nuestras reglas de complemento sepan que ese es el tsconfig que se debe utilizar para obtener información de tipos y conocer las opciones del compilador de TypeScript. Bien, hemos terminado. Con cuatro configuraciones de proyecto y medio, estamos listos para ver algo de código. La demostración que vamos a ver hoy es de código abierto. No es necesario clonarlo para asistir a esta charla, pero si quieres seguir, puedes hacerlo. GitHub.com/JoshRoke-Goldberg/TypeScriptESLintReactDemo. También está disponible en TypeScriptESLintReactDemo.Vercel.app. Me encantan mis empleados de Vercel. Y es una aplicación create-next-app bastante rudimentaria. Solo tiene una página. Tenemos un estado de contador de llamadas y un estado de color personalizado, que se establecen en cero y sin definir, respectivamente. En esta página, tenemos algunos botones. Cuando hago clic en un botón, incremento el contador de llamadas y establezco un color personalizado en un color aleatorio, lo que también cambia el fondo de la página. Genial. La primera regla que voy a revisar es awaitAvailable. Desde typescript.io/rules/awaitAvailable, la página de documentación para esta regla. Si se utiliza la palabra clave await en un valor que no está disponible, el valor se resuelve directamente de inmediato. Si bien esto es válido en JavaScript, a menudo es un error del programador. Dato curioso, 'Available' se utiliza comúnmente como promesas. 'Available' es una descripción del tipo de promesas de la clase real. Aquí te muestro el ejemplo de código. En nuestra página de inicio, perdón, tenemos esta función aquí, esta acción de ejemplo, que crea una variable de color igual a un color aleatorio, incrementa el estado de contador de llamadas que se establece aquí en uno, establece el color como el estado de color personalizado y devuelve ese color. Esta función luego es utilizada por nuestros componentes await thenable. Ahora, await thenable recibe una acción y elementos secundarios, al igual que en mi ejemplo de botón, y establece un estado de ejecución en verdadero o falso.

4. ESLint y Análisis de Código con TypeScript

Short description:

El botón debería estar deshabilitado mientras se ejecuta la acción, pero no lo está. La regla de ESLint se queja de un await inesperado de un valor no promesa no ventable. Eliminar los awaits no afecta el código y podemos eliminar el estado innecesario y simplificar el código a una línea. ESLint con TypeScript proporciona información profunda sobre los defectos del código.

antes y después de la acción. Y tiene este pequeño botón disabled igual a running que se refiere a ese fragmento de estado para que el botón esté deshabilitado mientras se ejecuta la acción. Para código asíncrono, esto es totalmente razonable, pero si volvemos a la demostración, nunca vemos que el botón esté deshabilitado. Entonces esto puede o no considerarse un error. Algunos simplemente lo llamarían código muerto, pero de cualquier manera, es un problema que debemos solucionar en nuestra aplicación. Y de hecho, estamos recibiendo una queja de nuestra regla de ESLint aquí. Tenemos la extensión de ESLint ejecutándose en VS Code. Await inesperado de un valor no promesa no ventable. Se queja de que mi acción está tipada como una función que devuelve void, lo que significa que ignoramos lo que devuelve. No nos importa. Pero lo estoy esperando, lo cual es incorrecto, porque no es una promesa. No está disponible. Entonces, si eliminara los awaits, el código debería seguir funcionando, y si voy a la demostración, incluso si actualizo. Sí, sigue viéndose bien. Porque ese await no hizo nada. De hecho, si uso el pequeño popover de la extensión aquí, puedo solucionarlo rápidamente, como nos dice la regla, para eliminar los awaits. Y luego, nuestra función async on click no tiene ninguna expresión await, me queja de otra regla de ESLint, impulsada por TypeScript, nuestra regla de require rate, que me informa que esta función ni siquiera necesita ser asíncrona en primer lugar, porque no hay ninguna llamada await en ella. E incluso puedo llevar esto un paso más allá al darme cuenta de que estoy estableciendo el estado en verdadero, llamando a una función de forma síncrona, y luego estableciendo el estado en falso. Entonces este estado ni siquiera es necesario en primer lugar. Puedo deshacerme completamente de mis estados. Siempre va a ser falso, lo que significa que el botón disabled igual a false ni siquiera necesita estar allí. Mi on click es una función que simplemente llama a la acción. Así que puedo simplificar el código a una línea dentro de la función. Boom. Increíble. Me encanta. Solo para asegurarme, volviendo a la demostración. Sí, todo aquí se ve bien. Genial. Ese es un ejemplo de tres en los que ESLint con TypeScript puede informarnos de información sorprendentemente profunda sobre los defectos del código.

5. Explorando Promesas Flotantes y Promesas Mal Utilizadas

Short description:

La siguiente regla que quiero analizar es la de no promesas flotantes. Una promesa flotante es aquella que se crea sin ningún código configurado para manejar errores. Las promesas flotantes pueden causar problemas como operaciones desincronizadas incorrectas y rechazos de promesas ignorados. En la demostración, tenemos un botón que debe esperar antes de realizar una acción, pero no se deshabilita cuando se hace clic varias veces. Esto se debe a que olvidamos agregar la palabra clave 'await' antes de la acción. Al habilitar la regla de 'no promesas flotantes', recibimos una queja de que las promesas deben ser esperadas. Agregar la palabra clave 'await' soluciona el problema. La última regla que quiero mostrar es 'no promesas mal utilizadas', que prohíbe proporcionar promesas en ubicaciones lógicas donde no se manejan correctamente. En la demostración, pasamos una función asíncrona al atributo 'onClick' de un botón, lo que genera una queja porque React no maneja funciones asíncronas. Al arrojar intencionalmente un error en la función asíncrona, demostramos que el error no puede ser manejado por el framework.

¡Yay! Pero sigamos adelante. La siguiente regla que quiero analizar es la de no promesas flotantes. Mi regla favorita personal de ESLint. En la página de documentación, notarás que esta es una pauta. Todas nuestras reglas están bajo TypeScript. Una promesa flotante es aquella que se crea sin ningún código configurado para manejar errores en mi lanzamiento. Las promesas flotantes pueden causar varios problemas como operaciones desincronizadas incorrectas, rechazos de promesas ignorados y más.

Veremos ambas cosas en esta demostración. Primero, quiero mostrar una violación directa aquí en este botón que es un poco más avanzado que el anterior. Se supone que debe esperar un segundo antes de hacer cosas. Y aunque funciona bien si simplemente hacemos clic una vez, si hacemos clic varias veces la demostración no se rompe como debería. Si hacemos clic varias veces veremos que en realidad no se deshabilita. ¿Qué está sucediendo aquí? Bueno, en esta versión sin promesas flotantes, llamamos a esta acción de ejemplo asíncrona que espera un segundo antes de llamar a esa misma acción de ejemplo y olvidamos agregar el 'await' antes de la acción. Observa cómo en esta está tipada como una función que devuelve una promesa void. Perdón. Entonces, nuestro código en realidad no espera la función antes de establecer los estados. Así que obtenemos este bonito efecto de discoteca si hacemos clic varias veces. Y si habilitamos la regla de no promesas flotantes, simplemente desactivo eso en la configuración para que no obtengamos un subrayado inmediatamente en los otros archivos. Obtenemos esta queja agradable, las promesas deben ser una lista de cosas que puedes hacer, como esperarlas, debes esperarlas. Así que voy a agregar un 'await' aquí, lo que significa que ahora esperamos la acción antes de que se llame a 'running false' y sí, nuestro código está arreglado como antes. ¡Yay! Ahora, las promesas flotantes no son honestamente mi regla favorita porque puede detectar muchas cosas realmente intensas, pero es muy similar en teoría a la última de las tres reglas que quiero mostrarte, que es la de no promesas mal utilizadas. Esta regla prohíbe proporcionar promesas en ubicaciones lógicas como declaraciones 'if' en lugares donde el compilador de TypeScript las permite, pero no se manejan correctamente. Las promesas flotantes son aquellas que se crean y luego no se manejan en absoluto, nadie las usa. Las promesas mal utilizadas son cuando manejas una promesa técnicamente, la proporcionas a algún lugar, pero ese lugar no tiene ninguna lógica para manejar promesas. Y para ilustrar la diferencia, te mostraré la última demostración que es nuestro componente de no promesas mal utilizadas. Aquí, pasamos esto a 'onClick' del botón, igual que antes. Y observa cómo tenemos el pequeño subrayado aquí, la queja, se esperaba una función que devuelve una promesa para el atributo o evitar el retorno, porque los eventos 'onClick' y 'on' en elementos DOM en frameworks como React no manejan funciones asíncronas. No manejan la idea de que la función podría tomar más tiempo síncrono constante para ejecutarse. Y en esta función, he hecho algo malvado. Dije que si el recuento de llamadas es mayor que dos y math.random es mayor que 0.5, vamos a lanzar un error, ¡atrapado!, lo que significa que debido a que este código asíncrono es

6. Manejo de Excepciones y Recursos

Short description:

Si encuentras una queja o fallo en tu código, envolver todo en un bloque try-catch puede parecer una solución razonable. Sin embargo, aún pueden ocurrir excepciones potenciales, incluso con try-catch. Para manejar de forma segura las funciones asíncronas, se recomienda crear un controlador unificado utilizando una función como 'runSafely', que recibe una acción, una función que crea una promesa y un controlador onError síncrono. Al implementar este enfoque, puedes asegurarte de que tu aplicación permanezca segura y no se bloquee, incluso cuando los usuarios exploran casos extremos. Estas son tres reglas fantásticas de ESLint del complemento TypeScript ESLint que recomiendo encarecidamente habilitar. Para obtener más recursos, ESLint.org ofrece una excelente documentación y una interfaz de usuario fácil de usar. También puedes consultar la demostración de TypeScript ESLint React para ver una demostración de estos conceptos. Si deseas apoyar mi trabajo, puedes comprar mi libro 'Aprendiendo TypeScript' o patrocinarme en GitHub. Además, el equipo detrás de TypeScript ESLint tiene un colectivo abierto y agradecería enormemente tu apoyo. ¡Gracias por ver y disfruta del resto de la conferencia!

Si encontramos una queja, si tenemos un fallo, jaja, ahí vamos. Simplemente irá a la raíz del error listener. Nuestro código no sabrá qué hacer con eso. Dato curioso. Esto es muy similar al estilo de ventana emergente en muchas herramientas de desarrollo modernas donde obtienes esto, creo que informado por webpack, pequeña queja.

Ahora, la forma de hacer esto que podrías tener en un principio sería envolver todo en un bloque try-catch, lo cual es totalmente razonable. Oh, no, error. Y tal vez también running false allí. Lo cual solucionaría el error si actualizamos, hacemos clic un par de veces y finalmente obtenemos la queja. Vamos, aleatorización. Me estás matando aquí. Vamos. Oh, cielos. Bueno, genial. Parece que nunca se rompió. Apuesto a que si revisamos la consola, sí, tenemos algunos oh, no. Pero esto aún podría ser un problema porque ¿qué sucede si haces algo peligroso en tu bloque catch, que accidentalmente tiene un error, jaja? Y luego lo ejecutas nuevamente, y nuevamente te encuentras en el caso en el que, a pesar de try-catch, aún tienes una excepción potencial en tu código. Entonces, la única forma real de hacer esto de manera segura es crear algún tipo de controlador unificado para tus funciones asíncronas. Recomiendo encarecidamente que, si tu aplicación debe ser sólidamente segura y no se bloquee, incluso para los usuarios que exploran casos extremos, si realmente te importa que tus usuarios no experimenten bloqueos, haz alguna función como esta función runSafely, que recibe una acción, una función que crea una promesa, y un on error síncrono, luego llama a action.catch on error, para que puedas crear onClicks o otros controladores de eventos que sean un run safely de tu código asíncrono y luego algo que maneje el error. En este caso, solo para fines de demostración, he configurado un estado de error, que se muestra al usuario en un span con ARIA live assertive. Entonces, ahora, si vamos a nuestra demostración y hacemos clic, esto puede fallar de manera segura. Si falla, aún obtenemos el gotcha, y luego el botón vuelve a estar habilitado, incluso si el código tuvo un fallo. ¡Increíble! Esas son tres reglas fantásticas de ESLint del complemento TypeScript ESLint que recomiendo encarecidamente habilitar. Y eso es todo lo que quería mostrarte en la demostración. Para obtener más recursos, ESLint.org es fantástico, acaban de hacer una gran revisión del sitio con una excelente reescritura de la documentación y una nueva interfaz de usuario encantadora. Tuvimos un rediseño de sitio un poco menos impresionante en TypeScript. Y si quieres ver la aplicación de demostración, nuevamente, está enlazada en el lateral, demo de TypeScript ESLint React. Si quieres apoyarme en mi trabajo para mejorar todo esto para ti, puedes comprar mi libro Aprendiendo Typescript. Y por favor, patrocíname en GitHub, github.com/.sponsors/.JoshuaKGoldberg. Y si quieres apoyarnos como equipo detrás de TypeScript ESLint, tenemos un colectivo abierto, opencollective.com/.typescripteslint. Realmente necesitamos tu apoyo porque estamos muy subfinanciados y tenemos muy poco personal en este momento, y tenemos muchas características, problemas de performance y errores que nos gustaría abordar este próximo año. Dicho esto, muchas gracias por ver. Gracias a los organizadores de la conferencia por organizar todo esto. Puedes encontrarme en Twitter, Joshua K. Goldberg, y espero que disfrutes del resto de la conferencia. Adiós.

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 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
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 Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

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 Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
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 Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
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