Hubo un tiempo antes de React, y habrá vida después. Si te vinculas demasiado estrechamente a cualquier tecnología, podrías atraparte a ti mismo y perderte la próxima ola. Vamos a alejarnos de la biblioteca de gestión de estado del momento — ¿qué lecciones atemporales podemos aprender de React? En la charla, discutiré las lecciones que he aprendido estudiando React que llevaré conmigo durante el resto de mi carrera.
This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.
FAQ
Las lecciones clave incluyen el patrón de reconciliador, el diseño de la API, la optimización para el cambio, las pruebas, las herramientas de desarrollo y la importancia de la comunidad.
El patrón de reconciliador implica que el programa regenere todo cada vez, utilizando almacenamiento en caché y compartición estructural para mantener la eficiencia. Esto permite adaptarse a cambios con menos coste de rendimiento.
Un área mínima de la API significa tener una interfaz más limpia y menos propensa a errores, lo que facilita el mantenimiento y la escalabilidad del software.
Un buen diseño de API permite un razonamiento local más fácil y menos dependencia del contexto global, lo que facilita la gestión del código y mejora la eficiencia en el desarrollo.
Las pruebas son cruciales para asegurar la estabilidad y la funcionalidad a largo plazo del código, especialmente en las refactorizaciones y al mantener la compatibilidad a lo largo de diferentes versiones de React.
Las herramientas de desarrollo, como React DevTools, son esenciales para depurar y optimizar aplicaciones, y para mantener la calidad del código a través de un mantenimiento más eficiente.
La comunidad juega un papel crucial en el desarrollo y la adopción de React, proporcionando retroalimentación, compartiendo mejoras y fomentando un ecosistema saludable de aprendizaje y colaboración.
La charla se centra en las lecciones que podemos aprender del éxito de React, incluyendo el diseño de API, la optimización para el cambio, las pruebas y la participación de la comunidad. La idea de un mullet DX UX, con modo inmediato en el frente y modo retenido en la parte posterior, se observa en varias áreas del desarrollo de software. Se enfatiza la importancia de la denominación y la optimización para el cambio, así como la importancia de DevTools y la construcción de una comunidad. También se discuten los principios detrás del marco Temporal y la importancia de un buen nombre en el diseño de API.
React es más antiguo que jQuery cuando se lanzó por primera vez. jQuery todavía alimenta una parte significativa de Internet, pero ya no es tan genial. React también enfrentará un destino similar. La charla se centra en las lecciones que podemos aprender del éxito de React. Las siete lecciones cubren el reconciliador, el área de superficie de la API, el diseño de la API, la optimización para el cambio, las pruebas, las herramientas de desarrollo y la comunidad. El patrón de reconciliador y programador de React es una buena idea para varios trabajos. El programador está viendo implicaciones más allá de React, y el equipo central de React lo ha dividido en su propio paquete. También están trabajando con el equipo de desarrollo de Chrome para potencialmente incorporarlo al navegador.
Hola, Cumbre de React. Estoy aquí para ofrecer siete lecciones para sobrevivir a React. Entonces, la premisa de esta charla es que React es más antiguo que jQuery cuando React fue lanzado por primera vez. Y jQuery no está muerto. Todavía alimenta una gran cantidad de Internet, pero ya no es tan genial como antes. Y ese destino también llegará para React algún día. Deberíamos tratar de pensar en lo que durará más allá de React.
Entonces, mientras miramos a React en su ascenso y entrando en su fase muy madura, deberíamos pensar en qué lecciones aprendemos de este enorme éxito. Hola, soy swix. Trabajo en muchas cosas diferentes. Y hago mucho en la comunidad de React. Pero principalmente doy charlas sobre React, que es la calificación más relevante para esta conferencia. Y muchas de estas charlas se centran en elementos individuales de React. Pero esta es la primera charla que realmente cubre la filosofía general, que creo que puede llevarse de eso. Si desea profundizar en detalles individuales, estas charlas son realmente buenas para cubrir sobre cubrir las bases técnicas de las que extraigo muchos de estos principios.
Entonces, las siete lecciones de antemano se presentan aquí. Hablaremos sobre el reconciliador, el área de superficie de la API, el diseño de la API, la optimización para el cambio, las pruebas, las herramientas de desarrollo y la comunidad. Entonces, la primera parte es que el patrón de reconciliador y programador es probablemente una muy buena idea para un montón de trabajos diferentes. Y esto en realidad proviene de Jordan Walk, que es su visión original. Que sea lo que sea que tu programa produzca, píxeles, archivos, cualquier cosa, simplemente haz que tu programa regenere todo cada vez, agrega almacenamiento en caché y compartición estructural para hacerlo rápido y eso es todo. Y obviamente eso es gran parte del discurso original, que capturé del original charla de JSConf. Y esa es la forma en que React se diferenció desde el principio.
Pero tal vez también esté pasando por alto el otro MVP de React, que es la programación. ¿Verdad? Que es la otra parte. Y estamos viendo mucha innovación ahora, cuando cambias de viejo React a modo concurrente de React, empiezas a obtener los beneficios del rebanado de tiempo, del cual se habla mucho. Si desea una introducción más detallada a la programación en React, definitivamente consulte la publicación de blog de Philips Spice, que presenté aquí. Este programador en realidad está empezando a ver implicaciones más allá de React. Entonces, el equipo central de React en realidad dividió el paquete del programador en su propio paquete con la esperanza de que otros frameworks puedan usarlo. Y están trabajando en el equipo de desarrollo de Chrome, eso debería ser del equipo de desarrollo de Chrome, para tal vez incorporarlo a su navegador. Entonces, si quieres que React se integre en el navegador, este es el comienzo.
2. DX UX Mullet: Modo Inmediato y Modo Retenido
Short description:
La idea de un mullet DX UX encapsula el concepto de modo inmediato en el frente y modo retenido en la parte trasera. El modo inmediato implica volver a renderizar todo el sistema cada vez, mientras que el modo retenido conserva el estado. Este patrón se observa en varias áreas como sistemas de construcción, GraphQL, tuberías ETL y Nullify, donde los desarrolladores buscan velocidad y simplicidad.
Pero en general, creo que esto encapsula la idea de un mullet DX UX. Ese es mi término para ello. Donde tienes el modo inmediato en el frente y el modo retenido en la parte trasera. Modo inmediato, simplemente vuelve a renderizar todo cada vez tanto para el frontend, el usuario, como para el desarrollador. Y el modo retenido, que es el sistema en el medio que realmente conserva el estado. Y esto es realmente cierto para los sistemas de construcción. Entonces, Jared Palmer está trabajando en un sistema de construcción donde tiene exactamente el mismo patrón. Y empieza a ver este patrón una y otra vez en GraphQL, en las tuberías ETL y Nullify. Y muchos otros aspectos diferentes de la vida donde tienes a un desarrollador trabajando con un sistema y quieres que sea rápido, pero también fácil de razonar.
3. Área y Diseño de la API
Short description:
El área mínima de la API es la segunda lección de la charla de Sebastian Markburger. Los patrones de biblioteca con demasiada API no son sostenibles. React ha reducido su propio formato de clase propietario, colapsando las API con el tiempo. Sin embargo, este enfoque tiene el costo de renunciar a la enrutación, la gestión del estado y el estilo, que otros marcos proporcionan. La lección número tres destaca que el diseño de la API es el diseño del lenguaje, con un enfoque en la denominación y cómo la gente habla de React.
Bien. Segunda lección. Área mínima de la API. Esta, por supuesto, proviene de la charla seminal de Sebastian Markburger que realmente expone esta filosofía. Y básicamente, basado en su experiencia trabajando con herramientas Mood, dice que muchos patrones de biblioteca son simplemente demasiado grandes. Es simplemente demasiada API y no van a durar y es realmente difícil de deshacer una vez que has creado esa API. Así que su solución es simplemente no intentarlo en primer lugar. Y prefieres una API explícita y repetitiva en lugar de una implícita.
El compromiso, por supuesto, es que tendremos mucho más... ¡Spoiler! Plato. Ves muchos de estos ejemplos en cómo crece React con el tiempo. React ha eliminado voluntariamente su propio formato de clase propietario para las clases ES6. Puedes ver realmente que el diseño de React usa... Como, por ejemplo, con los hooks, donde puedes ver los hooks de terceros, como los hooks definidos por el usuario, están al mismo nivel que los hooks centrales de primer nivel. Y ese es un concepto que proviene de la charla de Guy Steele Growing a Language, que recomiendo encarecidamente. Y puedes ver que React intenta colapsar las API. Tendrán estas tres API de clase de componente muy comunes, y las colapsarán en GDSFP, y luego también escribirán una entrada de blog para recordarte que es posible que no la necesites, especialmente si usas funciones. Así que cada vez menos API con el tiempo, y realmente aprecio al equipo central de React por eso. Pero hay un costo, que es que renuncias... No hay solución de enrutamiento, no hay solución de gestión de estado, no hay estilo, y todo eso que viene con React. Y estas son cosas que otros marcos dan por sentado, y con las que los desarrolladores de React luchan. Así que hay un costo para eso. Comentaremos sobre eso en una futura lección.
Pero la lección número tres es que el diseño de la API es el diseño del lenguaje. Y esto es muy similar al punto anterior, pero distinto. Y el punto en esto, y el énfasis aquí es la denominación, y la forma en que la gente habla sobre React. Así que Lee Byron en realidad tuvo una gran contribución a esto, incluso antes de que co-fundara GraphQL. Al sentarse y realmente definir los conceptos, las acciones, los operandos y las notificaciones, puedes ver el resultado de eso en las elecciones de diseño de la API de React. Y estos son los que nos son familiares. Pero han cambiado mucho con el tiempo.
4. Denominación, Hooks y Optimización para el Cambio
Short description:
La denominación ayuda a moldear nuestro pensamiento en React. Los Hooks proporcionan una sintaxis de denominación común y una API de una sílaba para los humanos. El principio de UI antes que API y la disposición a permitir que los usuarios hackeen soluciones existentes. La lucha con los componentes de envoltura y la pirámide del destino. Intentos de solucionar el problema con componentes de orden superior, props de renderizado y componente React.headless. La realización de que los hooks son una mejor opción. Lección número cuatro: optimizar para el cambio en el diseño de la API.
Pero todavía hay una gramática que se ha establecido que podemos esperar y recomendar. Y tiene sentido para nosotros como desarrolladores de React. Nos ayuda a pensar en React basado en el lenguaje. Y eso es una parte muy importante de esta hipótesis de aparecer-valioso, que es que la denominación realmente ayuda a moldear nuestro pensamiento. Las palabras que usamos ayudan a moldear nuestro pensamiento.
También puedes ver esto en los hooks. La forma en que se usa lo que sea es una sintaxis de denominación muy común para los hooks. O la sintaxis de denominación recomendada para los hooks. Y solo el nombre de los hooks en sí. Estos son los otros 50 nombres que se consideraron para los hooks antes de que se decidieran por hooks. Y en parte, es con la consideración de que, sí, quieres algo que sea de una sílaba, para que puedas referirte a ello en la conversación diaria. Pero también es una API que los humanos usan en lugar de las computadoras. Y en general, creo que tal vez Dan lo expresó mejor. Dice UI antes que API. Quieres empezar con el resultado final, y luego trabajas hacia atrás para crear las API que te ayuden a llegar allí. Pero su otro principio es realmente interesante también. Hacks y luego idiomas. Lo que significa que está dispuesto a dejar que los usuarios hackeen lo que sea que tengas, en lugar de construir una API extra solo para acomodarlos.
Y aquí, es muy claro lo que es, si eres de una cierta generación en React, donde tienes muchos componentes de envoltura solo para inyectar algo con redux o GraphQL. Y esta pirámide del destino, me encanta agregar un poco de Hadoop allí, solo para simbolizar lo profundo que realmente va. Hay muchas soluciones que intentan resolver esto. Hay muchas soluciones que resultan en esto, y simplemente no tienes opción porque React realmente no te dio otra forma. Entonces, si querías inyectar estado, necesitabas un componente de orden superior. Hubo una breve revolución para las props de renderizado, de nuevo, de las mismas personas que recomendaban componentes de orden superior. Intentando resolver este gran problema de la pirámide del destino, introduje un RFC de React llamado React.headless component. Y todas estas fueron solo formas de inyectar comportamiento, que simplemente no eran realmente correctas. Y todos nos dimos cuenta de que los hooks eran simplemente una opción mucho mejor hacia el final.
La lección número cuatro es optimizar para el cambio. Entonces, este es el punto final sobre el diseño de la API, que es que no deberías optimizar para, ya sabes, no te repitas, o no deberías optimizar para líneas mínimas de código. Optimiza para el cambio, y aquí está el por qué.
5. Diseño de Primer Orden y Optimización para el Cambio
Short description:
El diseño de primer orden es que tu código debería ser fácil de leer y escribir. Quieres hacer que lo correcto sea lo fácil. Una vez que has escrito la cosa, los requisitos comienzan a cambiar. Una gran API no solo te permite caer en un pozo de éxito, sino que te ayuda a permanecer allí. La solución del equipo de React es habilitar el razonamiento local para optimizar el cambio. Optimizar para el cambio es una idea fundamentalmente importante que durará más que React. Lección número cinco: prueba la API pública.
Entonces, el primer orden de design es que tu code debería ser fácil de leer y escribir. Deberías tener todas estas características. Realmente me gusta la del pozo del éxito. Se dice comúnmente que quieres hacer que lo correcto sea lo fácil. Quieres ser memorable, como Lee Byron haciendo la gramática para React. Eso es muy memorable. Necesitas ser adivinable. Ese es un muy buen consejo de Jon O'tander. Y también quieres fomentar el performance, la accessibility, la seguridad y la user experience. Todos estos son, ya sabes, igualmente importantes. No hagas juicios de valor sobre cuál es más importante. Pero una vez que has escrito la cosa, entonces los requisitos comienzan a cambiar. Y ahí es donde entra el diseño de segundo orden. También quieres que sea fácil de cambiar. Entonces, si tienes un código muy frágil, entonces un ligero cambio en los requisitos hará que tu código se desmorone. Entonces, el gran diseño de API realmente anticipa que querrás renombrar o copiar y pegar, unificar en abstracción o descomponer en abstracción, eliminar o añadir un hack. Hacer todo tipo de cosas a tu código, y necesita no desmoronarse cuando intentas hacer eso. Entonces, una gran API no solo te permite caer en un pozo de éxito, sino que te ayuda a permanecer allí. Y eso es una observación realmente, realmente buena. Y eso es algo que ves mucho en otros formatos. Entonces, dos referencias a las que me gustaría señalar si quieres investigar más sobre esto, es el blog de Stack Overflow, donde llaman a esto volatilidad de requisitos, así como Hillel Wain, que llama a esto perturbaciones de requisitos. Misma idea, diferentes enfoques. La solución del equipo de React para resolver esto es habilitar el razonamiento local, para tratar de reducir tanto contexto global como sea necesario, y simplemente enfocarte en el código frente a ti, y eso debería permitirte cambiar lo que necesites. Porque entonces en realidad no tienes que tener acción espeluznante a distancia. Ves esto en las publicaciones de blog de Dan, en Sophie Alpert blogueando sobre Data Loader. Puedes ver esto en Style Components, Tailwind, o el diseño del compilador Relay. Hay muchas formas diferentes en las que puedes habilitar el razonamiento local que ayuda a optimizar las cosas para el cambio.
6. Pruebas, DevTools y Construcción
Short description:
Tengo muchas más diapositivas que estas. Tuve que recortar porque no tengo tiempo, pero no dudes en contactarme porque optimizar para el cambio es una idea fundamentalmente muy importante que durará mucho, mucho más tiempo que React. Lección número cinco: prueba la API pública. Muy, muy simple. Deberías escribir pruebas, no demasiadas, principalmente de integración. No pruebes detalles de implementación. Lección número seis: DevTools no son opcionales. React enfatiza DevTools. React también utiliza Codemods. Las advertencias de desarrollo de React es algo que realmente se lleva al límite con React. No puedes automatizar todo, así que es bueno introducir algunos fixtures. El último consejo es un meta-consejo: DevTools para ayudarte a construir DevTools. Deberíamos ser conscientes de lo que estamos construyendo y enviando y deberíamos ser conscientes de las grandes regresiones.
Tengo muchas más diapositivas que estas. Tuve que recortar porque no tengo tiempo, pero no dudes en contactarme porque optimizar para el cambio es una idea fundamentalmente muy importante que durará mucho, mucho más tiempo que React.
Bueno, lección número cinco, prueba la API pública. Muy, muy simple. Deberías escribir pruebas, no demasiadas, principalmente de integración. No pruebes detalles de implementación. Esto es obviamente muy, muy importante para React porque React emprendió una gran reescritura de todo el código base, pero mantuvo las pruebas y las pruebas realmente sobrevivieron al código base, y eso no es algo que sea muy revelador para tus aplicaciones. Obviamente, también implementaron este pequeño rastreador para IsFiberReadyYet, donde realmente rastrearon la finalización hacia la reescritura. Y es solo una cosa realmente motivadora de ver para el código base de React, que en realidad se ha extendido como un movimiento hacia las aplicaciones de React, ¿verdad? Así que hemos visto que la enzima está relativamente en declive en comparación con la Biblioteca de Pruebas de React, y eso es como debería ser, porque nuestra Biblioteca de Pruebas de React tiene este enfoque en probar solo la API pública de los componentes. Y eso es lo que tus usuarios usarán, y eso es lo único que realmente deberías cuidar en tus pruebas. Y lo hace mucho menos frágil en comparación con lo que había antes. OK, lección número seis. Pasamos a DevTools. DevTools no son opcionales, y puedes ver cuánto enfatiza React DevTools. Entonces, por supuesto, los DevTools oficiales de React, el complemento de Chrome, es mantenido por Brian Vaughan en el equipo central de React, y hace un trabajo increíble. Como, no sé cuánto pagaría por esto, pero pagaría por esto. Y deberías aprender todas las complejidades si quieres depurar. React también utiliza Codemods. Esto no es opcional para React básicamente porque el equipo de React en realidad tiene que mantener las decenas de miles de componentes que están en el código base de Facebook, y tienes que actualizar todos ellos cada vez que cambian las API, así que, por supuesto, tienes que automatizar estas cosas. Y nosotros, como la comunidad de React, nos beneficiamos. Las advertencias de desarrollo de React es algo que realmente se lleva al límite con React. Así que puedes ver la superposición de errores de React, o puedes ver advertencias de lint, o puedes verlo en la consola. Incluso tenemos códigos de error, por lo que puedes ver errores agradables en producción, pero no tener peso extra en los artefactos de construcción finales, y es una experiencia de decodificador muy agradable, que desearía que más herramientas de desarrollo copiaran. No puedes automatizar todo, así que es bueno introducir algunos fixtures. Realmente me gusta esto como una forma de aprender React también, porque puedes comenzar a activar banderas de características y cambiar diferentes navegadores y ver cómo cambia el comportamiento. Es solo una forma muy agradable de probar cosas manualmente al tener todo en su lugar para que no pierdas tiempo configurándolo. Y finalmente, el último consejo es una especie de meta-consejo. DevTools para ayudarte a construir DevTools. Para React, porque está construyendo una biblioteca que se incrustará en millones de otras aplicaciones, necesitan mantener el tamaño del paquete pequeño y nunca aumentarlo involuntariamente, y es algo que podemos tomar prestado para nuestras aplicaciones también. Deberíamos ser conscientes de lo que estamos construyendo y enviando y deberíamos ser conscientes de las grandes regresiones.
7. Importancia del Compromiso Comunitario
Short description:
Las DevTools no son opcionales. Construir una comunidad es crucial. El primer equipo central de React escuchó los comentarios y se comprometió con la comunidad, lo que resultó en atraer a más usuarios. Deberíamos aprender de esto y priorizar el compromiso comunitario en nuestros propios proyectos.
Entonces, las DevTools no son opcionales. La última lección es que no debemos descuidar la comunidad. También queremos construir una comunidad. Esto obviamente se remonta al principio de la apertura del código de React. De hecho, Jordan Walk tuvo que introducir JSX porque estaba siendo ignorado internamente dentro de Facebook. Y una vez que introdujo JSX, les gustó mucho más. Pero luego, sucedió exactamente lo contrario cuando lo abrieron al público. Este es Jordan durante los faros tratando de introducir JSX a una muy mala recepción, y aquí está Pete Hunt tratando de rescatarlo diciendo, hey, es opcional, chicos, no se preocupen tanto. Y creo que finalmente nos acostumbramos a la idea. Pero el núcleo de esto es que todo el primer equipo central realmente escuchó los comentarios. Estaban en IRC en Stackoverflow 24-7, y respondieron a cada crítica viéndolas como su culpa. Y ese trabajo en la comunidad dio sus frutos. Comenzaron a atraer a muchos usuarios, en particular a David Nolan de la comunidad ClojureScript que construyó Omen, realmente comenzó a promocionar React bastante. Y creo que es mucho trabajo que tal vez se olvida con el tiempo. Pero creo que si estamos empezando a crear nuestros propios proyectos que queremos que sean tan populares como React, necesitamos empezar a prestar atención a la comunidad tal como lo hicieron. Y esa es una lección que llevamos con nosotros.
8. Distribución de React y Lecciones
Short description:
La distribución de React ha llevado a un enfriamiento en la destrucción creativa de los marcos de trabajo. El contrato para React ha cambiado de centrarse en las características a la estabilidad. Las siete lecciones cubiertas en esta charla incluyen tener una idea central, trabajar en el diseño de la API, producirlo y humanizarlo. La lección de metal es enamorarse de los problemas porque las soluciones van y vienen, pero los problemas permanecen. Consulta el libro en learningpublic.org para más principios.
Además, necesitamos empezar a resolver puntos de dolor. Entonces, uno de los grandes puntos de dolor era que React es tan pequeño que no resuelve el resto de las otras aplicaciones y la gente empezó a hacer memes y bromas al respecto. Entonces, Dan Abramov realmente fue y creó Create React App. Y esa es una historia que cuento en una charla separada llamada Create React App.
Pero en general, la historia de esto es básicamente que es una distribución de React, ¿verdad? Empaquetas React con otras cosas, Next.js y Gatsby lo empaquetan con enrutamiento y Blitz y Redwood empaquetan Next.js y así sucesivamente. Puedes empaquetar y empaquetar y empaquetar. Y lo que realmente estamos viendo aquí es un enfriamiento en la destrucción creativa de los marcos de trabajo y la maduración y despliegue de React y estamos empezando a construir encima de React en lugar de tratar de competir con React. Y lo principal que React, el contrato para React empieza a cambiar, ¿verdad? Ahora lo principal que cambia React, no son las características. Es la estabilidad. Por supuesto, la curva S no es un fin. Puede empezar a ser S de nuevo cuando concurrentemente React está completamente fuera.
Entonces las siete lecciones que cubrimos son todas estas. Creo que va a ser un poco difícil de recordar si eres siete. Ya sabes, la memoria de trabajo es solo de tres a cinco. Así que aquí está mi desglose. Primero, tienes una idea central de lo que tu biblioteca o marco de trabajo va a hacer. Luego quieres trabajar en la interfaz entre el desarrollador y tu biblioteca central. Así que ese es tu diseño de API. Luego quieres producirlo, ya sabes, trabajando en las pruebas, trabajando en las herramientas de desarrollo. Y finalmente, quieres humanizarlo para asegurarte de encontrarte con las personas donde están. Y esas son las siete lecciones. Eso no son las únicas siete lecciones que puedes aprender de React. Y hay más en camino. El equipo de React es muy generoso en compartir sus lecciones sobre concurrente React. Y deberías prestar atención a esas. Pero en general, la lección de metal que quiero dejarte es que deberías enamorarte de los problemas porque las soluciones van y vienen, pero los problemas siempre permanecerán. Eso es todo. Si quieres aprender más sobre estos principios, que creo que durarán toda nuestra carrera, deberías consultar mi libro en learningpublic.org. Pero de lo contrario, muchas gracias por tenerme y nos vemos en el resto de las charlas. Adiós.
QnA
Área de Superficie de la API y Optimización
Short description:
La mayoría de las personas dicen área de superficie de la API mínima y optimizan para el cambio. El orador comparte su actual función en temporal.io, una startup de orquestación de microservicios de back end. Explican su motivación para unirse a una pequeña empresa en una etapa temprana. El orador también menciona una pregunta de Juan Segebre sobre las trampas comunes y mentalidades que dificultan la optimización para el cambio.
Parece que la mayoría de las personas dicen área de superficie de la API mínima y optimizan para el cambio. Obtenemos muchos empates en estos, como 36%, 36%. Así que dividido por la mitad, ¿era eso lo que esperabas de esta pregunta? ¿El área de superficie de la API? Creo que sí. Creo que se ajusta a lo que la gente responde muy bien. Sí. Genial. Asombroso.
Bueno, tenemos un montón de preguntas para ti, pero quería empezar con una. Y eso es, ¿qué estás haciendo ahora? Así que en tu introducción, estaba como, eras un defensor senior de desarrolladores para AWS, pero sé que te has movido porque ese es el equipo en el que estoy. Entonces, ¿qué pasa? ¿Qué estás haciendo ahora? Oh, te pusieron a cargo y tuve que irme. Eso es una broma, todos. Se fue antes de que me convirtiera en el gerente. No. Sí, por supuesto. No, realmente. De todos modos, sí, acabo de unirme a temporal.io. Es una startup de orquestación de microservicios de back end. Muy, muy diferente a lo que normalmente hago. Y quería, supongo, ampliar. Pero también apostar por una pequeña empresa. Ya sabes, donde es la Serie A, muy temprano y esperando ser la próxima gran, supongo, ya sabes, startup de orquestación de back end. Y si alguna vez has trabajado en tareas de larga duración como, ya sabes, como sagas para el back end, esto es algo que realmente deberías revisar. Pero no voy a promocionarlo en una conferencia de React. Así que tuve que idear una charla diferente para esta. No, eso es genial. Eso es realmente, realmente genial. Tenemos más preguntas también. Esta es de Juan Segebre. ¿Cuáles son las trampas comunes y mentalidades que nos evitan optimizar para el cambio? ¿Eso evita? Lo siento. Supongo que es ¿nos ayuda a optimizar para el cambio? ¿O que nos hace evitar el cambio? Uno de los dos.
Optimizando para el Cambio y Escribiendo Entradas de Blog
Short description:
Existen varias formas de optimizar para el cambio en el desarrollo de software. Un enfoque es evitar depender del orden de los argumentos y en su lugar usar objetos de opciones. Otra estrategia es co-localizar datos y facilitar su eliminación, ya que el código solo de anexar puede llevar a la deuda técnica. El orador planea escribir un artículo más detallado sobre este tema en el futuro. También discuten la importancia de seguir la regla de los tres golpes cuando se trata de escribir entradas de blog, encontrando un equilibrio entre publicar demasiado y muy poco.
Porque se supone que eso es bueno. No estamos tratando de evitarlo. Espera. Estoy pegando mis diapositivas y mis enlaces en el Discord. Ahí es donde los tengo. Y no sé si hay otros canales donde debería publicarlo. Pero si alguien quiere seguir todas las recursos que pegué, puede seguir allí.
Pero, sí, esencialmente hay tanto, ¿verdad? Creo que simplemente pensando en tu design al pensar en qué cambios podrían llegar y arruinar tu día es esencialmente la idea. Y por lo tanto, puede ser tan pequeño como cosas como depender del orden de los argumentos. Entonces, si te das cuenta en React, las props realmente no les importa el orden de los argumentos. Y eso es porque básicamente es un objeto de opciones. Que es algo que si miras una de mis charlas favoritas, Simple Made Easy de Rich Hickey, depender del orden de algo es en realidad complejidad. Realmente te hace necesitar recordar, ¿qué viene después de qué? Mientras que si pones las cosas en orden independiente, te liberas. Pero luego se vuelve tan grande como si estás co-localizando data y facilitando las cosas para eliminar. ¿Verdad? Porque el código solo de anexar es una fuente importante de deuda técnica. Si tienes miedo de eliminar cosas porque no sabes qué efectos globales va a tener, entonces tienes esencialmente lo que llamo momificación de tentáculos. Porque estás poniendo vendaje tras vendaje tras vendaje y terminas con una momia de deuda técnica. Y sí, hay muchas formas de optimizar para el cambio y planeo escribir un artículo más grande sobre esto en el futuro, pero quería meterlo allí.
Eso es impresionante. Y la gente definitivamente debería seguirte en las redes sociales para ver todas tus entradas de blog porque es tan, tan impresionante cómo escribes sobre las cosas. Y sacas artículos y ves un tema un par de veces y escribes sobre él. Y creo que eso es impresionante. Sí, lo llamo la regla de los tres golpes. Creo que la gente tiene una barrera hacia cuándo deberían escribir sobre algo porque sienten que necesitan ser un experto en ello para escribir sobre ello. O tienen lo contrario completo. Sacan cada pensamiento despierto. Y esos dos extremos no son muy ideales, ¿verdad? Porque estás publicando demasiado o estás publicando muy poco. Entonces, mi regla de los tres golpes es que una vez que te has referido a una idea tres veces, deberías intentar y escribir un blog sobre ello. Porque eso ha permanecido el tiempo suficiente para demostrar que probablemente va a permanecer un poco más en tu mente. Pero no es demasiado tiempo que te has aburrido con
Presión de Blogging y Nuevos Frameworks
Short description:
Para tener menos presión con tu blog, simplemente publícalo después de tres intentos. Encuentra un medio diferente donde puedas experimentar más. Utiliza diferentes medios para diferentes propósitos. Considera la idea del jardín digital. Svelte es un framework que podría reemplazar a React en el futuro. El éxito de React ha inspirado a otros. Temporal está implementando estas ideas.
la idea o está empezando a perder relevancia. Así que, estoy tratando de promover este concepto de que para tener menos presión con tu blog, simplemente publícalo después de tres intentos. Me encanta esa idea. Soy tan perfeccionista que me resulta muy difícil presionar publicar en cualquier cosa, como que tomo notas de todo. Pero ese es un gran punto.
Eres un escritor muy pulido. Y creo que eso es algo que tenemos que entender como creadores de contenido. Tu blog transmite una expectativa de la cantidad de trabajo que se invierte en él. Y ahora, creo que si te desvías de eso, la gente se sentiría un poco... incómoda con ello. Así que, creo que necesitas encontrar un medio diferente donde puedas experimentar más y donde la gente no espere que tengas ese nivel de pulido. Así que, soy fan de usar diferentes medios para diferentes propósitos. Oh, me encanta eso. Me encanta eso. Me estás dando todos los advice aquí. Me encanta la idea del jardín digital también. La gente parece realmente interesada en eso especialmente en la community de egghead. Así que, debería profundizar más en eso. Ya publicaste todos tus recursos, lo cual es increíble. Esa era nuestra siguiente pregunta. Luego la siguiente es de Sasha. ¿Hay algún framework específico nuevo y mejorado basado en estas lecciones en el que preveas que podría reemplazar a React en el futuro? Wow. No quería ir allí pero realmente me gusta Svelte. Vamos a tener una masterclass en dos semanas. Así que puedes venir a ver Svelte Summit. Está en YouTube. Creo que es general para open source. Si estás trabajando en marketing de desarrollo o empezando un proyecto de open source o quieres apostar temprano en open source, estas son las cosas a tener en cuenta. Estas siete lecciones no son las únicas lecciones y estoy interesado en que otras personas entiendan lo que pueden aprender de React. React es uno de los frameworks de open source más exitosos del mundo. Todo el mundo está interesado en replicar
Framework Temporal y Principios de Aprendizaje
Short description:
Temporal es un framework de código abierto que surgió de Uber. Es útil de manera genérica y se puede aplicar a varias áreas. Los principios detrás del framework son más importantes que la API específica. Aprender y aplicar estos principios tendrá un impacto duradero en tu carrera.
éxito para su propio proyecto. Mi empresa, estamos implementando estas ideas en Temporal. Temporal es un framework de código abierto que surgió de Uber y estamos tratando de comercializar y popularizar eso. Creo que es útil de manera genérica, la única observación específica para el front-end fue la primera, que es más sobre reconciliación y programación, que es algo muy centrado en el framework de front-end. Pero luego te das cuenta de que puedes aplicar eso a otras cosas. Yo destacó un tweet de Jared Palmer diciendo que está utilizando las mismas ideas para el sistema de construcción. Y eso no tiene nada que ver con el DOM o el front-end, pero eso es genial. Son los mismos principios de ingeniería de software que puedes reutilizar una y otra vez. Y creo que ese es mi punto final, que es cualquier cosa que aprendas, no estás aprendiendo la API. Puedes aprender la API, pero realmente lo que se quedará contigo incluso después de que ese framework se haya ido son los principios. Y deberíamos tratar de aprender de eso porque eso se acumulará y durará toda nuestra vida.
HyperApp y Sistemas de Nomenclatura
Short description:
¿Has probado HyperApp? Es un marco de trabajo ligero que refleja la arquitectura de Elm. Encuentro que el lenguaje de programación Elm es difícil de usar. ¿Cómo se llega a un buen sistema de nombres? Tengo una publicación de blog sobre ese tema. Es importante tener cierta perspectiva sobre la nomenclatura de las cosas y no rendirse antes de intentarlo. Tu primer usuario de blog eres tú mismo.
Entonces, realmente, es algo muy valioso para aprender. Eso es genial. Eso es genial. ¿Has probado alguno de los otros frameworks más nuevos de los que has hablado, pero has probado HyperApp por casualidad? No, ¿qué es? Es un framework super ligero que te permite usar JSX también, pero refleja la architecture de Elm, que realmente disfruté. ¿Conoces Elm, como el front end? Sí. De hecho, he leído la tesis de graduación de pregrado de Evan Czeplicki, que es como la base para Elm.
Eso es genial. Y es la tesis de pregrado más impactante. Como que no recuerdo mi propia tesis de pregrado . Recuerdo la mía. Escribí un montón de tweets y todo era sobre cómo la gente discute sobre diferentes políticos en las redes sociales, pero sí, eso es una visión super, super interesante, pero sí, HyperApp. Está escrito en JavaScript, pero tiene la architecture de Elm. Me gusta mucho porque es ligero. Me gusta la architecture de Elm, pero encuentro que el lenguaje de programación es un poco difícil de usar, así que no sé. Eso es divertido.
Esta es de Katre. ¿Cómo se llega a un buen sistema de nombres cuando eso no es tu fuerte? ¿Cuánto tiempo se debe dedicar a eso? Tengo una publicación de blog sobre cómo nombrar las cosas. He intentado responder a esta pregunta porque es uno de los problemas conocidos difíciles. Deberíamos tener cierta perspectiva sobre la nomenclatura de las cosas. Si dices que simplemente no eres bueno en eso y no lo intentas, entonces básicamente te estás rindiendo antes de empezar. No creo que sea una forma muy productiva de manejar las cosas porque vas a tener que nombrar las cosas. Eso es mucho de lo que hacemos como parte de Coders. No sé. ¿Cuál era la pregunta de nuevo? ¿La respondí? Muchas de mis respuestas son simplemente como tengo una publicación de blog para eso. Y esa es una buena forma de vivir porque es un buen aprovechamiento del tiempo porque paso horas en esa cosa. No voy a dar en esta pequeña charla. Si a la gente le interesa realmente, puede buscarlo. Sí. Es casi como tu segunda fuga cerebral. No tienes que recordar todas estas cosas porque
Importancia de la Nomenclatura en el Diseño de API
Short description:
El equipo de React pone mucho esfuerzo en la nomenclatura porque es crucial para la comunicación humana. Un buen diseño de API implica considerar cuidadosamente la nomenclatura. El equipo de React consideró varios nombres antes de decidirse por hooks, que es un nombre simple y efectivo.
has escrito sobre ellos en el pasado. Tu primer usuario de blog eres tú mismo. Así que la pregunta era sobre cómo llegar a un buen sistema de nombres y cuánto tiempo se debe dedicar a ello, lo cual creo que respondiste. Sí. Quiero decir, estoy realmente inspirado por cómo el equipo de React piensa tanto en la nomenclatura. Y eso no significa nada para la computadora, pero es todo acerca de la comunicación entre humanos. Eso es mucho de lo que se trata un buen diseño de API. Y cuando ves que publiqué una captura de pantalla en mis diapositivas de cuántos nombres consideraron antes de decidirse por hooks. No es una casualidad que sea un nombre tan simple de una sola sílaba que vagamente a muchas personas les causa problemas con
Nomenclatura y Optimización para el Cambio
Short description:
Vale. Y tuve algunos problemas con eso, pero fue suficiente. Y transmitió el mensaje y fue útil. Y eso es lo que están buscando y eso es algo que creo que con un poco de práctica, puedes al menos evitar malos nombres. Lo cual es bueno. No sé cómo nombrar las cosas. Eso es difícil. Entonces, volviendo a esa primera pregunta, cambian su redacción. Entonces, queremos optimizar para el cambio ¿qué cosas nos impiden hacer esto? ¿Qué malentendidos? De esa manera podemos intentar alejarnos de ellos. Entonces, creo que esto se refiere al diseño de API y al acoplamiento y cómo cuando haces ciertas elecciones. Hay una tabla de elecciones fundamentales de diseño de API que conducen a un diseño simple y a un diseño más complejo. Y creo que es simplemente la verdad real que si simplemente evitas los más complejos, eso ayuda a, ya sabes, entender qué te lleva a optimizar para el cambio. Honestamente, hay mucha verdad en el hecho de que estás confiando en el orden. Y el orden puede significar orden jerárquico así como orden secuencial.
el nombre hooks. Vale. Y tuve algunos problemas con eso, pero fue suficiente. Y transmitió el mensaje y fue útil. Y eso es lo que están buscando y eso es algo que creo que con un poco de práctica, puedes al menos evitar malos nombres. Lo cual es bueno. Y creo que probablemente el primer paso es evitar múltiples nombres para el mismo múltiple nombres muy diferentes para el mismo concepto. Y puedes entender cuál es la abstracción más genérica que estás intentando nombrar también. No sé cómo nombrar las cosas. Eso es difícil. Sí, definitivamente un problema sin resolver. Vale. Entonces, volviendo a esa primera pregunta, cambian su redacción. Entonces, queremos optimizar para el cambio ¿qué cosas nos impiden hacer esto? ¿Qué malentendidos? De esa manera podemos intentar alejarnos de ellos. Ooh, gracias. Lo tengo. ¿Qué podría impedirnos hacer esto? ¿Qué malentendidos? Ah, interesante. Realmente no he pensado en esto. No sé. No sé si hay algo como hacer lo opuesto esencialmente a todo lo que recomendé. Sí. Entonces, creo que esto se refiere al diseño de API y al acoplamiento y cómo cuando haces ciertas elecciones. Entonces, mucho de esto está contenido en la charla simple made easy porque él realmente tiene una tabla. Tuve que cortar esto de mi charla porque tuve que cortarlo por tiempo. Pero hay una tabla de elecciones fundamentales de diseño de API que conducen a un diseño simple y a un diseño más complejo. Y creo que es simplemente la verdad real que si simplemente evitas los más complejos, eso ayuda a, ya sabes, entender qué te lleva a optimizar para el cambio. Honestamente, hay mucha verdad en el hecho de que estás confiando en el orden. Y el orden puede significar orden jerárquico así como
Optimización para el Cambio y Estilo de Alcance
Short description:
Hacer que tu asincronía, la obtención de data, la renderización y el estilo sean independientes del orden permite un razonamiento local y optimizado para el cambio. Aunque evitar los globales es ideal, su uso limitado puede ser aceptable. Los cambios de alcance a elementos específicos, como con Tailwind, ofrecen un enfoque más localizado al estilo. La forma en que Tailwind aplica directamente el estilo a los elementos es una tecnología fascinante que merece una exploración más profunda.
orden secuencial. Y creo que una vez que haces tu asincronía, tu obtención de data, tu renderización, tu estilo, independientes del orden, entonces permites, entonces habilitas el razonamiento local. Y eso es en última instancia lo que el equipo de Facebook y en última instancia algo con lo que estoy de acuerdo, en última instancia lo que ellos piensan que ayuda a optimizar para el cambio. Evitar los globales es una de esas respuestas muy baratas. Pero a veces los globales son realmente agradables. No sé cómo me siento acerca de los globales. Creo que el uso limitado de globales es probablemente la forma correcta de expresar esto. Y luego todo lo demás, ya sabes, solo intenta hacer, intenta mantener las cosas en el ámbito de la localidad de donde las cambias, que es, por cierto, una razón por la que realmente me gusta Tailwind, porque Tailwind aplica el estilo directamente al elemento, como si estuvieras usando estilos en línea. Esa es una tecnología fascinante, que espero que más gente esté explorando.
Consejos de Carrera para Desarrolladores
Short description:
Quiero pivotar a tu libro en lugar de tu charla. Tres piezas favoritas de consejos de carrera: conocimiento de código abierto, lo suficientemente bueno es mejor que el mejor, recoge lo que dejan.
Eso es increíble. Eso es increíble. Bueno. Nos queda un minuto. Quiero pivotar a tu libro en lugar de tu charla. ¿Cuáles son tus tres piezas favoritas de career advice para un desarrollador junior a senior? Todavía estoy aquí al lado. Dios mío. Por lo que vale, tengo 40 capítulos. Me estás pidiendo que elija mi favorito entre ustedes. Esto va a ser difícil. Bueno. Así que déjame tratar de hablar sobre, así que creo una cosa es open-source conocimiento, esencialmente. De hecho, tengo una charla sobre esto en mi YouTube donde es una variante de lo que soy conocido, que se llama aprender en público. Pero esto es realmente exponer tus materias primas al descubierto y dejar que la gente contribuya y evolucionarlo con el tiempo. Mientras que muchas personas, cuando intentan aprender en público, tienden hacia artículos terminados como un vídeo de YouTube, una entrada de blog. Eso es algo así como uno y hecho tipo de cosa. Quiero que la gente intente hacer más cosas con el tiempo y simplemente vaya y construya algo sustancial y algo útil para ti y para todos los demás a tu alrededor. Así es como me involucré en la construcción del proyecto de hojas de trucos de React y TypeScript que es literalmente una referencia para mí para aprender React y TypeScript. Eso es abrir el código fuente de tu conocimiento. Otro que realmente me gusta es esta idea de que lo suficientemente bueno es mejor que el mejor. Deja de buscar lo mejor porque nunca estarás contento. Tienes que estar al tanto de las noticias de otras personas y tienes que preocuparte por lo que otras personas piensan y te centras en lo que es suficientemente bueno, lo que necesitas y lo que mejor conoces. Finalmente, supongo que uno más para simplemente lanzar ahí es recoger lo que dejan. Así que si quieres que mucha gente pregunte sobre el inicio en frío intentando empezar a escribir y aprender en público. Y encuentran que no tienen ninguna tracción o ningún lector. Responde al trabajo de otras personas. Si acabo de lanzar un nuevo libro, revísalo o interactúa con los creadores y encontrarás que tendrás una probabilidad mucho mayor de responder y convertirte en un colaborador y eventualmente un amigo. Esos son mis tres tips.
Eso es increíble. Esos son grandes consejos de advice. Muchas gracias. Ha sido divertido ponerse al día y también escuchar tus advice y tu charla. Genial. Sí. Muchas gracias por invitarme y nos vemos a todos en el chat.
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
This Talk explores the concepts of impact and growth in software engineering. It emphasizes the importance of finding ways to make the impossible possible and the role of mastery in expanding one's sphere of impact. The Talk also highlights the significance of understanding business problems and fostering a culture of collaboration and innovation. Effective communication, accountability, and decision-making are essential skills for engineers, and setting goals and finding sponsors can help drive career growth. Feedback, goal setting, and stepping outside of comfort zones are crucial for personal development and growth. Taking responsibility for one's own growth and finding opportunities for impact are key themes discussed in the Talk.
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía). En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también. Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso. (Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?
¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.
Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.
¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.
¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.
En esta masterclass, aprenderás cómo construir tu primer dapp de pila completa en la blockchain de Ethereum, leyendo y escribiendo datos en la red, y conectando una aplicación de front end al contrato que has desplegado. Al final de la masterclass, entenderás cómo configurar un entorno de desarrollo de pila completa, ejecutar un nodo local e interactuar con cualquier contrato inteligente usando React, HardHat y Ethers.js.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Comments