React, TypeScript y TDD

Rate this content
Bookmark

ReactJS es ampliamente popular y, por lo tanto, ampliamente respaldado. TypeScript es cada vez más popular y, por lo tanto, cada vez más respaldado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

React+TypeScript, con 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 que utilizan TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.

174 min
12 Oct, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La masterclass de hoy se centra en el desarrollo guiado por pruebas en React, abarcando temas como la ejecución, construcción y prueba de aplicaciones React, el uso de Prettier para el formato de código, la refactorización y creación de subcomponentes, la implementación de estado y manejo de eventos en componentes, y la gestión de proyectos y la integración con IDEs. La masterclass enfatiza los beneficios del desarrollo guiado por pruebas, el uso de IDEs y la integración con herramientas como Jest y React Testing Library. TypeScript también se destaca como una herramienta valiosa para la comprobación de tipos y la mejora de la calidad del código. En general, la masterclass proporciona una guía completa para desarrollar componentes React siguiendo las mejores prácticas en el desarrollo de software.

Available in English

1. Introducción al Desarrollo Dirigido por Pruebas en React

Short description:

El masterclass de hoy trata sobre el desarrollo de componentes React primero. Escribir una prueba antes de escribir el código y continuar desarrollando el código y el componente. Al final, podrás ver el resultado real en el navegador. El tutorial proporciona una URL donde puedes seguirlo, con explicaciones, código y videos. Cada paso en el tutorial tiene un enlace al código funcional para ese segmento.

El masterclass de hoy va a ser yo tratando de convencerte sobre una idea. Y esa idea es sobre desarrollar tus componentes React primero. Escribir una prueba antes de escribir el código. Escribir una prueba como forma de continuar desarrollando el código y el componente. Y solo al final, cuando necesitas ver cómo se ve realmente, vas a un navegador.

Este tutorial tiene asociado algo con lo que puedes seguir. Puedes seguirlo en esta URL www.jetbrains.com webstorm guide. Si haces clic en tutoriales, llegarás a este tutorial. Y encontrarás en este tutorial que estoy haciendo trampa. Cada cosa tiene la explicación que voy a hablar, tiene el código que voy a mostrar. Incluso tiene un video que es en su mayoría correcto.

Permíteme cubrir ese punto rápidamente sobre el sí puedo. Lo puse en discordia, pero tienes razón. Debería haberlo pasado a otra persona, lo hice bien. Muy bien, gracias por hacer eso. Cada cosa que tengo es hacer trampa y ponerlo aquí, pero hay una razón para esto, quiero que puedas seguir y jugar sin preocuparte por cada cosa. Digo, si hay algo que no entendiste, hay algo en lo que quieres profundizar. Puede ser fácilmente reemplazado por una URL a un sitio web. Y también debo mencionar que cada paso en el tutorial tiene un enlace al código funcional para ese segmento del tutorial.

2. Configuración de un Proyecto React

Short description:

En esta parte, discutiremos los beneficios del desarrollo dirigido por pruebas y el uso de IDEs en el proceso de desarrollo. También cubriremos el proceso de configuración y limpieza, pruebas y depuración. El tutorial está actualizado con la última versión de Create React App y se centra en escribir componentes React. Crearemos un nuevo proyecto usando WebStorm y NPX, asegurándonos de tener la última versión de Create React App. Se incluirá el soporte de TypeScript. La salida de Create React App instalará las dependencias necesarias para nuestro proyecto. ¡Comencemos!

Entonces, lo que vamos a hacer es revisar esto. Presentar el caso para esta forma de desarrollo. A medida que construyo código funcional. Intentaremos hacer una pausa tal vez dentro de una hora y media o algo así. Tomar un descanso de cinco minutos. Tengo mi temporizador configurado para eso. También estaremos hablando en el chat. Intentaré hacer más grande el canal de Discord y el chat de Zoom, para no cometer errores en ellos.

Muy bien, disculpen por un segundo. Disculpas, me pregunto si mi micrófono captó ese estornudo. Vamos a seguir todos estos pasos. Y si te quedas atascado, está bien, porque el enlace al código funcional de cada paso te teletransportará a un futuro mágico donde todo funciona correctamente.

Una última advertencia antes de comenzar, soy un defensor del desarrollador para nuestras IDEs. Así que en JetBrains, para esto, significa WebStorm, o cualquiera de las otras IDEs que incluyen el complemento de WebStorm. No voy a promocionar demasiado WebStorm en esto. Usaré el término IDE, porque también se aplicará a otros editores inteligentes que pueden analizar la estructura en lugar de solo las cadenas de texto. Pero al mismo tiempo, mientras hago este tutorial, me entusiasma mucho cómo las tooling pueden ayudarnos, la tooling de testing y la tooling de typing pueden brindarnos una mejor experiencia de desarrollo y mantenernos en el flujo.

Entonces, con eso en mente, comencemos. Esta es la secuencia que vamos a seguir: configuración y limpieza, y luego pasar directamente a las pruebas. Haremos un poco de depuración para mostrar los beneficios de trabajar en un IDE, y luego pasaremos a varias cosas sobre escribir componentes React. Esto está actualizado hasta la última versión de create React app de la semana pasada, así que actualicé todo el código para esto. No actualicé los videos. Hay un par de lugares donde los videos están desactualizados en el uso de un selector jest para roles, pero todos somos inteligentes. Podemos solucionarlo. No sé hasta dónde llegaremos hoy con todo esto, pero, nuevamente, soy fácilmente reemplazable, así que si no llegamos al final, puedes ver el video en tu propio tiempo y ver sobre estos últimos temas. Son temas bastante interesantes y realmente muestran hasta dónde puedes llegar con las pruebas primero.

Muy bien, comencemos, así que voy a ir a la configuración del proyecto, y vamos a obtener una aplicación de muestra, y vamos a mostrar tres formas de ejecutar cosas en el código. Vamos a mostrar la ejecución de la configuración de desarrollo, la configuración de construcción del sitio final y la configuración de pruebas. Y en el camino, vamos a comenzar a introducir algunas cosas sobre el IDE. Si quieres seguir en esta página, está bien. También la tengo en segundo plano para poder hacer trampa. Voy a ir a mi IDE, voy a comenzar en la pantalla de bienvenida de WebStorm. Voy a crear un nuevo proyecto. Ahora, si no estás usando WebStorm, está bien, puedes escribir esto. Así que voy a crear un nuevo proyecto, será un proyecto React. Lo llamaré Create React App y me pedirá algunas cosas que utilizará de forma predeterminada. Déjame asegurarme de tenerlo. Tengo que desplazarme hacia arriba. Estamos bien. Ahí. Estamos bien aquí. Estoy usando hug. Creo que es el nodo 16. Sí. 16.10 Gracias, WebStorm, por responder esa pregunta por mí. Va a usar NPX para obtener create React app. Así que veamos si tienes intelligent idea ultimate, entonces tienes acceso al complemento de Node JS. Y si has instalado Node JS, tienes acceso a todo esto. Muy bien. Una pequeña advertencia sobre esto, voy a explicar como si algunas cosas fueran nuevas para algunos de ustedes. Pero también me doy cuenta de que algunos de ustedes saben qué es NPX. No me detendré en ello porque está muy bien explicado en otros lugares. En el mundo de Node JS. Pero si estás creando un proyecto, puedes usar el comando NPM para instalar paquetes. Pero ¿qué pasa si quieres instalar una aplicación, algo que vas a ejecutar, que luego creará un paquete? Existe esta cosa llamada NPX que dice: `Ok, ve a obtener la última versión de esto, colócala en un entorno temporal y ejecútala`. Entonces verás muchas de estas herramientas de línea de comandos como formateadores y andamios como este. Crea React app usando NPM para que siempre obtengas la última versión. ¿Cuál es la última versión de Create React app? Que es la herramienta de andamiaje que queremos usar. Es la versión 4.0.3. Y finalmente, quiero hacer un proyecto Typescript porque la escritura de tipos es una parte importante de esto.

Muy bien, con eso en mente. Un poco fuera de lugar. Debería haberlo hecho. Voy a volver y hacer uno nuevo. Lo hice bien, voy a ir y eliminar ese scratch pen. Muy bien. Muy bien, y luego volveré. Mis disculpas, debería haberlo eliminado. Así que nuevo proyecto, React, lo llamaré CRA, y pediré soporte de Typescript, crearé un nuevo proyecto y WebStorm lo está poniendo en mi monitor externo. Así que voy a redimensionar esto aquí. Y luego. Así. Así que lo que hizo WebStorm fue crear un nuevo proyecto en ese directorio y ejecutar algunas cosas que sabe cómo ejecutar, como create React app, que está creando todo el software y luego instalando todas las dependencias. Entonces lo que ves ahora es la salida de create React app, como si lo estuviera haciendo en la línea de comandos.

Ah, sí, Next JS, de hecho, estamos cada vez más interesados en Next JS, mi colega Ebenezer Dawn tiene una larga publicación en el blog sobre MDX y Next JS que publicamos recientemente. Muy bien, esto va y obtiene, quiero hablar sobre create React app. Para aquellos de ustedes que no lo conocen, es un andamio para generar la mejor colección de software compatible para una aplicación React moderna. Lo que significa que agrega paquetes adicionales que puedes querer usar y tooling que puedes querer usar, como formateadores y cosas así. Va a instalar más de mil, tal vez 1,500 paquetes. Y esto es simplemente una locura. Es tan difícil tener todo esto en la cabeza. Y luego, a medida que cambia todos los días, esto romperá eso. Create React app nos está haciendo un gran favor al asumir la responsabilidad de qué software debemos usar. Y qué versiones de qué software debemos usar. Y ellos dirán que apoyaremos todo eso. Así que esto es algo realmente importante que se debe hacer para create React app. Y por eso lo estoy usando como punto de partida.

Qué suerte tenemos de tener compañeros de trabajo aquí juntos.

3. Ejecución, Construcción y Pruebas de Aplicaciones React

Short description:

En esta parte, aprendemos sobre la ejecución y configuración de una aplicación React utilizando Create React App. Exploramos cómo ejecutar la aplicación utilizando la terminal y el IDE, así como los beneficios de usar la herramienta npm del IDE. También discutimos el proceso de construcción y la generación de un directorio de construcción listo para producción. Por último, tocamos el tema de las pruebas y el uso de Jest como el ejecutor de pruebas oficial.

Muy bien. Y sí, June, tienes razón. Siempre hay 100 opciones para hacer lo mismo para todo, especialmente en el mundo del front-end. Creo que todos ustedes lo saben. Bien, ahora en este punto, todo mi software ha sido instalado. Voy a redimensionar todo esto y quiero ejecutar algo. Quiero ejecutar algo que está en mi archivo package.json. Sospecho que la fuente es un poco pequeña. Permíteme hacerla un poco más grande. Bien, Create React App genera un archivo package.json con algunas cosas en él. Pero lo interesante es que ha trasladado gran parte de la configuración y de este script a un software que puede ser actualizado más adelante sin que tengas que cambiar tu archivo package.json o las dependencias o algo así. Ahora podría seguir adelante y comenzar esto usando la terminal. Y lo haré, diré npm run script start. Y esta es la forma en que probablemente estás acostumbrado a hacerlo. Es decir, abrir una terminal. Y luego, veamos, abriste Chrome. Voy a cambiar mi navegador. Para que sea Firefox el primero de la lista. Sí, está bien. Así que esto tiene que venir aquí. Correcto. Quería que estuvieras en Firefox, pero está bien. Estamos bien. npm start ejecuta un servidor de desarrollo.

Muy bien, gracias por publicar los enlaces sobre la entrada del calendario y cómo ingresar aquí. Es cierto que Next.js se ha vuelto muy popular. Pero creo que si vas a las páginas de React en sí, todavía apuntan a Create React App. El proyecto React considera a Create React App como el iniciador oficial. Next.js agrega algunas cosas relacionadas con el enrutamiento y otras cosas que lo hacen más opinativo. Así que ejecutamos npm start, y está ejecutando un servidor de desarrollo de webpack. Está haciendo todas las cosas en una ventana, y puedo comprobar que está haciendo lo que quiero haciendo clic en app.tsx, que está en SRC. Y si cambio algo aquí para que sea una exclamación, verás que se recargará, se actualizará, y cuando vuelva a Chrome, veré esto en vivo. Y si tuviera suficiente espacio en mi pantalla, cambia a 720p, si tuviera suficiente espacio en mi pantalla, podrías ver que esto está sucediendo lado a lado. Ahora, eso está muy bien, pero no tienes que ejecutarlo en una terminal. Somos un IDE. Los IDE tienen cierta automatización para integrar tu entorno de desarrollo, así que si quiero integrar mi entorno de desarrollo, puedo hacer un par de cosas. Podría ejecutar, oh, por cierto, tengo las pestañas desactivadas. Las volveré a activar para que te resulte más familiar. Si quisieras, podrías ejecutar nuestra herramienta npm y obtener una lista navegable de cosas para ejecutar. Y luego se ejecutará en una ventana de herramientas para el IDE. Chris, estamos en la configuración del proyecto, que es el primer enlace, bajo muéstrame una página. Así que podríamos usar esta herramienta npm que expone todos los scripts en tu package.json, que es la forma en que solía hacerlo todo el tiempo. La forma en que lo hago ahora, sin embargo, es que simplemente dejo mi package.json aquí, y tenemos estas decoraciones de margen que me permiten ejecutar scripts, no solo ejecutarlos, también puedo ejecutarlos bajo el depurador, lo cual también es útil. Así que simplemente lo ejecutaré aquí, y en lugar de la ventana de la terminal, obtengo esta ventana de herramientas de ejecución que está dedicada para que el IDE capture la salida y te permita hacer ciertos tipos de cosas con ella. Muy bien, veamos, Alexis. Hola, Alexis. Actualmente estamos allí. Ahora, lo mismo. Verás que estamos ejecutando lo mismo por debajo. Si vuelvo a WebStorm y luego voy a mi componente, y lo minimizaré, y eliminaré esto y pondré el punto de nuevo y lo guardaré, se recarga automáticamente. Así que, en el fondo, sigue siendo el equivalente moral de npm start. Así que eso nos lleva a través de la creación del proyecto, muéstrame una página, estamos ejecutando el script para iniciar. Eso no es lo único que podemos hacer, sin embargo. Lo que estamos ejecutando es un servidor de desarrollo. No es la construcción de calidad de producción. No está minimizando todo y dividiéndolo en rutas cargadas de forma diferida, y todos los milagros de la ciencia moderna que React moderno te ofrece. Lo que queremos ejecutar es el script de construcción. Y nuevamente, esto es algo muy bueno que Create React App ha hecho por nosotros. Tienen un script que administran en su propio paquete, y cuando encuentran un error, lo solucionan, y no tengo que volver a escribir algo en mi lado. Está gestionado por el paquete. Así que si quiero ejecutar la construcción, la construcción de producción, lo mismo de siempre. Voy al margen, hago clic en ejecutar, se abrirá una ventana de herramientas. Va a llevar un tiempo, y mi ventilador de la CPU se va a encender un poco. Para la herramienta npm, si no puedes encontrarla, espero que puedas simplemente hacer buscar acción para acceder a ella. O si haces buscar archivos, espero que esté listada aquí. Si no es así, es posible que no tengas el complemento activado. Gracias, Sherry. Creo que respondí la pregunta que se hizo. Si estoy mirando otra pregunta, avísame. Parece que Sherry también respondió la pregunta allí. Si eso no responde la pregunta sobre dónde encontrarlo en IntelliJ, avísame. De acuerdo. Así que hemos generado un directorio de construcción. ¿Qué significa eso? Hemos generado un directorio de construcción. Eso es lo que significa. Esta es una versión exportada de mi proyecto React, lista para ser servida en un servidor de archivos estáticos de una manera muy performance. El mínimo JavaScript, y todo ese tipo de cosas. Y si miro aquí, veré que tengo un index.html, tengo algunas variaciones de mi logotipo, otras cosas que coinciden con lo que estaba obteniendo en un servidor de desarrollo. Una cosa interesante de esto es que el IDE lo ha marcado como excluido, lo cual es bueno. No quiero que lo indexe constantemente y me dé dos opciones para navegar a un símbolo o algo así. Muy bien, eso es hacer construcciones. Pasemos a lo que queremos hablar, que es pruebas. Otra cosa que hace Create React App por nosotros es un andamio.

Muy bien, de acuerdo. Así que lo estoy mostrando en WebStorm, pero si vas a Buscar archivos, espero que lo tengas aquí. Si no lo tienes aquí, entonces es posible que no esté instalado correctamente. De acuerdo, cerraré esta ventana de herramientas de construcción. Y estamos hablando de pruebas. Y lo que queremos ejecutar es este script de ejecución para las pruebas. ¿Qué está haciendo realmente? Nuevamente, Create React App es un andamio oficial para el proyecto React. Y ha tomado algunas decisiones sobre las pruebas. Ha decidido que Jest es el ejecutor de pruebas oficial.

4. Ejecución de Pruebas y Limpieza del Proyecto

Short description:

Jest es el ejecutor de pruebas oficial y la biblioteca de pruebas utilizada se llama biblioteca de pruebas. Se aseguran de la compatibilidad entre las versiones de Jest, la biblioteca de pruebas y React. Las pruebas se pueden ejecutar desde la línea de comandos, los scripts de NPM o el archivo package.json. El tutorial cubre la configuración de los scripts de ejecución de npm en el IDE y en Create React App. A continuación, limpiaremos el proyecto y exploraremos TypeScript. ¿Alguna pregunta o comentario antes de comenzar? Utilizaremos la expresión 'Fail Faster' para detectar errores temprano y nos enfocaremos en el formateo de código con Prettier. También eliminaremos archivos innecesarios generados por Create React App.

Vamos a ver si lo tengo. Sí, Jest es el ejecutor de pruebas oficial y la biblioteca de pruebas que se utiliza para la búsqueda y automatización de pruebas es algo llamado biblioteca de pruebas. Se aseguran de que esta versión de Jest y esta versión de la biblioteca de pruebas funcionen con esta versión de React. Esto es importante porque eso se rompe todo el tiempo, especialmente cuando se introduce TypeScript en la ecuación. Así que es muy útil que alguien más esté haciendo ese trabajo por nosotros. ¿Cómo puedo ejecutar mis pruebas ahora mismo? Veamos. Permíteme volver aquí. Podría ejecutarlo desde la línea de comandos como lo hice antes. Y nos dará la salida. O podría ejecutarlo desde los scripts de NPM. O podría hacerlo desde el archivo package.json. Así que lo ejecutaré desde aquí. Se abrirá otra ventana de herramientas de ejecución. Y lanzará mi observador de pruebas, que ejecuta mis pruebas constantemente en cada cambio para ver si algo está roto. En resumen, voy a romper algo. Y lo haré. Veamos, en Prueba. Quiere algo llamado Aprender React. Y así que veamos. Aprender. Sí. Si guardo eso, la prueba se vuelve a ejecutar. Y dice que fallé una prueba. Lo vuelvo a poner, lo guardo. En este caso, no volvió a ejecutar la prueba porque está en un modo en el que solo... De acuerdo. Estas son nuestras formas de comenzar con los scripts de ejecución de npm en el IDE y comenzar con Create React App y las pruebas. Lo que vimos es que hay muchas herramientas involucradas. Y Create React está haciendo un gran trabajo ayudándonos a mantenernos actualizados y administrar todas esas herramientas. En el siguiente paso, vamos a limpiar algunas de las cosas que estaban en nuestro sistema que obtuvimos de fábrica y que no necesitamos, y echar un vistazo más de cerca a TypeScript. De acuerdo. Veamos. Muy bien. Creo que estoy actualizado. Pasemos al siguiente paso del tutorial. Vamos a ir al paso de limpieza del proyecto. Aprovecharé este momento para responder cualquier pregunta que tengan o ver cualquier comentario que tengan y ofrecer algunos comentarios propios. Este sitio es un proyecto de defensa del desarrollador en Jet Brains. Tenemos guías para PyCharm, WebStorm, .NET, Goland, Space, IntelliJ, que está haciendo un gran trabajo con su guía. Y elegí implementarlo usando Gatsby. Gatsby. Fue una gran primera semana. Y han sido 200 semanas realmente difíciles desde entonces. Muy bien, ¿alguien tiene alguna otra pregunta o comentario sobre Create React App, el mundo de React o los IDE y las herramientas? De acuerdo. Comenzaremos. Vamos a limpiar un poco nuestro proyecto, eliminar algunas cosas que no estamos usando y, en el proceso, mostrar cómo el IDE puede ayudarnos. Voy a usar una expresión. Voy a usar un par de expresiones en varios lugares. Voy a usar una expresión llamada Fail Faster. Una expresión extraña destinada a ser extraña. Y el punto es, si va a haber un error más adelante, muéstramelo ahora. Muéstramelo directamente en mi cara visualmente para que sepa que he cometido un error. Y a medida que avanzamos, hablaré un poco sobre Fail Faster. En este ejemplo, en este paso, vamos a ver cómo reformatear nuestro código, en última instancia, con Prettier. Vamos a reducir lo que obtuvimos de fábrica para incluir la eliminación de algunos archivos que fueron generados por Create React App y que no vamos a usar.

5. Uso de Prettier para el Formateo de Código en WebStorm

Short description:

En esta parte, aprendemos sobre la limpieza de archivos y el uso de las funciones del IDE para el formateo de código. Exploramos el uso de Prettier como formateador de código y discutimos la elección del gestor de paquetes entre Yarn y npm. También abordamos la ubicación de las dependencias de desarrollo en Create React App y la instalación de Prettier para el formateo de código. El IDE proporciona opciones para configurar Prettier y ejecutarlo al reformatear el código. La audiencia participa en una discusión sobre por qué Create React App coloca las dependencias de desarrollo bajo las dependencias de tiempo de ejecución.

¿Esa cara sonriente, Alexis, es una cara sonriente de amor o de dolor? Si hay amantes o usuarios de Gatsby aquí, pido disculpas si me he equivocado. Compartan sus pensamientos sobre Gatsby en el canal, y déjenme saber qué piensan.

Así que vamos a hacer una limpieza de algunos archivos y ver cómo el IDE nos puede decir, oye, estás a punto de cometer un error. Falla más rápido. Vamos a ver un poco sobre las ventajas del IDE, cómo puede advertirte sobre ciertos problemas. Puede hacer limpiezas por ti y un poco de refactorización. Así que empecemos, voy a empezar reformateando mi código, y lo haré primero en, dejaré abierto el archivo Package.JSON. Voy a empezar aquí, y en el IDE, en Mac OS, es Comando Alt L. Verán que tengo esta herramienta llamada, un complemento llamado, Presentation Assistant instalado. Es para todos nuestros IDEs, y muestra qué tecla se presionó, qué acción se invocó, así que lo haré de nuevo. Eso te muestra el enlace de teclas que puedes usar en tu lado. El tutorial también tiene el enlace de teclas listado también en el texto.

Sí, Alexei, buen punto. Puede usar Yarn como gestor de paquetes. Nuestros IDEs son bastante transparentes al respecto. Si voy a buscar acción, no, a preferencias, y busco npm, puedo cambiar entre Yarn y npm. Buen punto. En el package.json, en las dependencias, en realidad lista algunas de las que mencionaste. Los tipos solo se enumeran aquí. ¿Es eso, me pregunto si no está en mi texto? Si el problema es que no está en mi texto, entonces necesito actualizarlo. Pero pensé que copié y pegué todo correctamente. Si no, pido disculpas.

De acuerdo, volvamos al formateo de código. Estoy en mi componente. He hecho el formateo, y eso es genial. Pero eso no es lo que la gente realmente está usando en estos días. En estos días, la gente está usando cosas como Prettier, algunas otras herramientas como esa. Así que en lugar de la maquinaria del IDE, la maquinaria de WebStorm para el formateo, que es genial y tiene todo tipo de perillas para ajustar todo tipo de cosas de formateo. Si voy a estilo de código, busco en JavaScript, veo que tengo todas estas perillas que puedo ajustar para controlar lo que sucede cuando reformateo el código. Pero estás trabajando en proyectos que podrían tener integración continua, otras personas que no están usando nuestros IDEs, podrías elegir usar Prettier. Así que instalemos Prettier. Vamos a hacer Prettier. Lo voy a ejecutar manualmente. Lo que podría hacer es ir aquí. Oh, entiendo tu punto. Esperabas que esto estuviera bajo Dependencias de desarrollo. Eso es un buen punto. Esta es una elección de Create React App. Y estoy de acuerdo contigo. Me sorprende eso. De acuerdo, eso es un buen punto. Creo que debería estarlo. Sí. Hmm. De acuerdo, audiencia, ¿alguien sabe por qué Create React App coloca cosas que son claramente dependencias de desarrollo bajo dependencias de tiempo de ejecución? Si tienes una buena respuesta para eso o crees tener una buena respuesta, escríbela. De acuerdo, solo estaba diciendo que voy a hacer esta instalación npm. Lo haré desde la línea de comandos. Pero una de las cosas geniales que puedes hacer en WebStorm es decir prettier aquí. Y se autocompletará. Y puedo elegirlo. Y hará la búsqueda por mí. Maldición, lo haré aquí. De acuerdo. Así que ahora, cuando guarde esto, el IDE dirá, oye, ha cambiado. ¿Quieres hacer una instalación? Sí, IDE. Sí, gracias. Gracias por ser tan útil. La instalación de Yarn se está ejecutando. Yendo a buscar 500,000 paquetes de npm porque así es como lo hacemos en los front ends en estos días. Ajá. Todo va a las dependencias. Tengo algo que aprender sobre eso. Buen punto. Buen punto. Andy, tenía la imagen arriba. Y luego desapareció. Así que ahora tengo Printier instalado. Necesito decirle al IDE que lo use para el formateo. En lugar del formateador del IDE. Porque no quiero tener que ejecutar algún otro comando para reformatear mi código. Ni siquiera sé qué comando es Alt L. Mis manos lo saben. Lo hacen automáticamente. Solo empiezo a pensar y mis manos lo escriben solas. Así que voy a ir a Printier. Y esto está en las Preferencias. Y voy a decir, tengo un paquete Printier instalado en Node modules ahora. Úsalo. No tengo que ir a buscarlo globalmente o algo así. Y luego esta es la parte importante. Puedo marcar 0, 1 o ambas opciones. Y puedo decir, ejecuta Printier siempre que elija reformatear el código. También podría ejecutarlo al guardar. También puedo ir a la ventana de herramientas para esto y hacer todo tipo de cosas interesantes. Esto se introdujo en la última versión, creo, 2021.2. Así que volviendo a Printier, lo haré de la manera más sencilla. Voy a decir en Reformat Code.

6. Reformateo de Código, Limpieza y Renombrado

Short description:

Reformateamos el código usando Printier, simplificamos el componente de nivel superior y agregamos un encabezado. Optimizamos las importaciones, eliminamos archivos no utilizados y manejamos las advertencias de importación. También renombramos la aplicación a Mi App y actualizamos el nombre del archivo según la convención de React.

¿Ves esa comilla simple? Voy a reformatear el código. Y debido a que Printier tiene una opinión diferente al IDE, piensa que las cosas deberían ser comillas dobles. Cuando reformateo el código, se ejecuta Printier. Muy bien, eso es genial. Tenemos Printier funcionando. Hagamos un poco de limpieza. Voy a cambiar mi componente de nivel superior para que sea muy simple. Y ejecutaré Printier, obtendré un poco de sangría en él. Y voy a poner un pequeño encabezado allí para que diga, digamos, hola React. Y voy a usar Emmet para hacer esto. También me desharé de esto. Corté y pegué y hice trampa. Pero podría decir div.h1 tab. Y luego decir no, eso no es lo que quería. Div. Oh sí. Lo siento. Hizo un nombre de clase para eso. Y luego tab. div.h1. Div.h1. He arruinado esto. No voy a insistir en eso. Obviamente estoy escribiendo algo mal aquí. Y diré, hola, React. Muy bien. Oh, OK. Sin espacio. Eso es lo que haré. Sí, tienes razón. div.h1. No. div.h1. Sí, tab. Mis disculpas. Eso es algo que hago todo el tiempo. No sé por qué mi mano no lo entendió automáticamente. De acuerdo, ahora tenemos un componente React muy simple que servirá de base para nuestras pruebas más adelante. Pero vemos que ahora tenemos algunos problemas en nuestro código. De hecho, tenemos dos. Y veamos. Logo está definido, pero nunca se usa. Podría volver al principio y simplemente eliminar esto. Pero eso significaría detener lo que estoy haciendo y salir del flujo. En cambio, hago optimizar importaciones. Y esa es la combinación de teclas para ello. Y eso eliminará cualquier importación no utilizada, y reorganizará mis importaciones, combinará mis importaciones cuando sea necesario sin mover mi cursor. Y eso es algo genial para mí. Optimizar importaciones o cualquier formato de código que hago todo el tiempo. Ahora puedo hacer otras limpiezas. No estoy usando app.css o más, así que puedo eliminar esa línea. Y luego puedo eliminar estos dos archivos ya que ya no los estoy utilizando. Así que eso es Logo.SVG y app.css. Voy a eliminar eso. Pero esto es una eliminación inteligente. Va a decir, ¿quieres buscar algo que pueda estar usándolo? Diré, claro, genial. Y no se estaba usando. Ahora, veamos si eliminé algo que se estaba utilizando. Como, OK, bueno, si estoy eliminando CSS, eliminemos más CSS. Uh-oh. Espera. Algo lo está usando. ¿Qué lo está usando? Oh, la cosa de nivel superior lo está usando. No lo hagamos. Muy bien. Y luego algunas otras cosas. Si mantengo esa línea fuera, en algunos casos, si no lo haces, en versiones anteriores de React o dependiendo de cómo configures tu proyecto, eso es como pre-React 17, tenías que importar React si estabas usando JSX. Y luego el IDE te daría una pequeña advertencia y diría, oye, necesitas importarlo. ¿Quieres que lo importe por ti? Y dices que sí. Y hace el trabajo de limpieza por ti. Es interesante. Create React app todavía genera esta importación, a pesar de que claramente estamos más allá de React 17. Muy bien, genial. Muy bien, hemos pasado por algunas de estas limpiezas. Hablamos de esta característica del IDE donde si estás en una versión anterior y eliminas la importación de React, entonces obtendrás esta advertencia de que falta una importación. Y obtendrás un alt-enter, que será un amigo nuestro durante el curso de esta masterclass, como ayuda. Y luego eliges la acción y lo genera por ti. Hagamos otra cosa. Digamos que app es un nombre tan aburrido, quiero cambiarlo a mi app. Bueno, lo que podríamos hacer es buscar en todas partes en nuestro proyecto y encontrar todas las referencias a app, esperar que las encontremos todas y cambiarlas. O podría refactorizar el nombre y decir Mi App. Y verás, mientras escribo en la parte inferior, está cambiando esa referencia. Y cuando termine, presiono Enter. Y hace algo aún más inteligente que solo encontrar referencias. En el mundo de React, hay una convención, un principio de responsabilidad única, que es nombrar el archivo con el mismo nombre que el componente exportado por defecto. Entonces el IDE me está ayudando, diciendo, oye, recuerda que hay esta guía de estilo. Es posible que desees cambiar el nombre del archivo. Sí, de hecho, gracias, IDE. Quiero hacer eso.

7. Deshaciendo Refactorizaciones en IDEs

Short description:

Cuando se renombran componentes o archivos, los IDEs ofrecen la capacidad de deshacer los cambios realizados durante el proceso de refactorización. Esto te permite volver fácilmente al estado anterior, incluyendo los cambios realizados en el código de prueba. Es una función conveniente que garantiza que puedas deshacer fácilmente una unidad de trabajo completa y restaurar todo a su estado original.

Ahora, cuando reviso los usos de esto, como en el archivo index.tsx de mi aplicación, su importación es diferente. Está importando desde un archivo con un nombre diferente y está importando un símbolo con un nombre diferente. Mi aplicación sigue en buen estado de funcionamiento porque la refactorización y el cambio de nombre se aplicaron en todas partes y hicieron lo correcto por mí, incluyendo en mi código de prueba. Digamos que luego decido, oh no, eso es tonto porque todos lo llaman app. Si lo llamo mi app, entonces nadie sabrá que realmente es el componente de nivel superior. Oye, IDE, ¿puedes devolverlo todo como estaba? ¿Puedes cambiar ese nombre de función a app? ¿Puedes cambiar el nombre del archivo a app? ¿Puedes cambiar la referencia a get? ¿Puedes cambiar todas las cosas que apuntan a él? Todo lo que tienes que hacer es deshacer y deshará todo lo que se hizo en esa acción. Entonces, el nombre del archivo vuelve a ser app, get vuelve a ser app y las cosas que lo referencian vuelven a usar app. Eso es realmente útil para todas nuestras refactorizaciones, que puedes deshacer y volver a poner las cosas como estaban antes.

8. Introducción a las pruebas

Short description:

A continuación, vamos a realizar pruebas reales. La masterclass enfatiza la importancia de disfrutar del proceso de desarrollo y encontrar la forma más productiva de trabajar. Lo demostraremos desde la perspectiva de las pruebas.

De acuerdo, a continuación vamos a realizar pruebas reales. El objetivo de esta masterclass ahora que ya estamos listos, haré una pausa por un momento. ¿Alguien tiene alguna pregunta? Veo que Reggie está hablando sobre la optimización de importaciones y VS code, al menos en Mac OS. Y nuevamente, esto se trata de los IDE en general, los editores inteligentes. Esto no se enfoca solo en WebStorm. Permite que tus herramientas hagan el trabajo de limpieza por ti. Lo cual también significa dedicar un poco de tiempo a aprender tus herramientas. Eres un profesional. Domina tus herramientas. Dedica tiempo durante la semana para repasar tus habilidades antiguas y aprender algunas nuevas. Los 10 o 20 minutos que dediques valdrán la pena durante el transcurso de un año. Gracias, Dylan. Por cierto, Dylan, ¿mi audio está demasiado alto o demasiado bajo? Tengo la costumbre de hablar en voz alta. Gracias, Jim. Y Sherry, estoy de acuerdo contigo en ejecutarlos como un combo, lo cual es algo para WebSRM, al menos en la versión 2021.2 puedes configurarlo de esa manera. De acuerdo, pasemos a las pruebas. Lo llamo test first en lugar de desarrollo guiado por pruebas porque lo que quiero convencerte es que no es comer tus vegetales. De acuerdo. Tienes una elección, ¿voy a comer el postre o el brócoli? Voy a comer el postre. En cambio, quiero convencerte de que esto es una forma más placentera, alegre y productiva de trabajar. Al comenzar con una prueba, no intento convencerte de la calidad. La calidad es buena, pero el punto aquí es cuál es la mejor forma para que yo trabaje en este momento. Y lo vamos a mostrar desde la perspectiva de las pruebas.

9. Ejecución de pruebas con Jest e integración con IDE

Short description:

Jest es el ejecutor de pruebas utilizado en el mundo de React y tiene una gran integración con IDE como Webstorm. Podemos ejecutar nuestras pruebas bajo una interfaz fácil de usar y enfocarnos en componentes de granularidad fina. Al simular código y devolver datos ficticios, podemos minimizar errores y concentrarnos en partes específicas. Vamos a configurar una interfaz agradable para las pruebas ejecutando pruebas directamente desde el margen o ejecutando todo en un archivo.

Muy bien, a medida que avanzas en esto, nuevamente todo el código está vinculado desde aquí. Jest es el ejecutor de pruebas que parece haber adoptado el mundo de React. También es de Facebook, creo. Y los IDE como Webstorm y otros tienen una gran integración con Jest. Y para nuestros IDE, todos tienen una interfaz de usuario consistente sobre cualquier ejecutor de pruebas. Así que aprendes uno, los aprendes todos en todos nuestros IDE, y Jest está conectado a eso.

Así que vamos a ejecutar nuestras pruebas tal como están ahora, pero bajo esta interfaz agradable que ponemos encima de Jest. Jun, tienes razón en que te encontrarás con algunos errores. Sin embargo, lo que puedes hacer es tener tu código simulado simplemente devolviendo datos ficticios para evitar los errores mientras vas completando las cosas. Pero como verás durante el transcurso de esto, porque estamos haciendo componentes muy pequeños y de granularidad fina, puedes apuntar la prueba a esta cosa muy pequeña e ignorar el resto del universo. Y así solo obtienes un par de errores, que son precisamente la cosa en la que estás pensando en ese momento. Así que Jun, pregúntame de nuevo en una hora y media y ve si estás en desacuerdo con este enfoque.

Lo que quiero hacer aquí es configurarme en el otro monitor. Lo que quiero hacer aquí, lo que quiero hacer aquí es tener una interfaz agradable en mis pruebas. Y esto está en este segmento, jest bonito, si estás siguiendo. Entonces lo que quiero hacer es poder acercarme a una prueba. Y en este caso, mis pruebas están en app.test.tsx, y al igual que el archivo package JSON, obtengo estos iconos donde puedo ejecutar cosas directamente desde el margen, y se ejecutará solo esta prueba. O bien, hago clic derecho en algún lugar del editor, o hago clic derecho en alguna parte de la pestaña, y puedo ejecutar todo en este archivo. Así que voy a hacer eso. Voy a ejecutar app.test.tsx.

10. Desarrollo guiado por pruebas en React

Short description:

El desarrollo guiado por pruebas en React puede ser más lento debido a los ciclos del transpilador y el compilador de TypeScript. Sin embargo, el IDE proporciona una ventana de herramientas dedicada para las pruebas, lo que permite a los desarrolladores centrarse en el código y recibir comentarios inmediatos sobre los resultados de las pruebas. Al configurar una ejecución de pruebas, los desarrolladores pueden ejecutar todas las pruebas o pruebas individuales, según sus necesidades. La integración del IDE con Jest y el depurador de Node.js mejora aún más la experiencia de las pruebas, proporcionando funciones como autocompletado de código, notificaciones de fallos y la capacidad de ejecutar pruebas en el depurador. Este enfoque de desarrollo, conocido como TDD, ayuda a los desarrolladores a trabajar de manera deliberada y bajo control, sin distracciones.

El desarrollo guiado por pruebas, también conocido como desarrollo primero de pruebas, en el mundo de React es un poco más lento. De hecho, en el mundo del front-end, es un poco más lento que en otros lenguajes, como Python, debido a todo el ciclo del transpilador. Tienes todo el ciclo del compilador de TypeScript que debe completarse antes de que el código pueda ejecutarse. En este caso, tenemos una interfaz agradable en nuestra salida de pruebas. Tenemos una ventana de herramientas dedicada a las pruebas con un pequeño árbol que muestra todos los archivos que se ejecutaron. Y luego, dentro de cada archivo, cada prueba que se ejecutó, y algunos pequeños iconos que te indican qué falló y qué pasó.

De hecho, vuelve al código de prueba, cambia el icono de la barra lateral para mostrarte que falló y agrega una pequeña ondulación para indicarte que una prueba falló y por qué. Así que no tienes que ir a la ventana de herramientas, puedes quedarte en tu editor y centrarte en la salida de texto. Ahora, sabemos que esto falló porque lo cambiamos durante la limpieza. Sin embargo, lo que podemos hacer es configurar una ejecución de pruebas que tenga todas nuestras opciones correctas y que ejecute todo nuestro código, en lugar de ir a una sola prueba. De hecho, encuentro que ir a una sola prueba es la forma en que trabajo la mayor parte del tiempo. Pero a veces, y esto vuelve a lo que Jun está diciendo, a veces quiero ejecutar todas las pruebas para ver si este cambio aquí rompió esa cosa allí.

Entonces, creemos lo que, en nuestros IDE, se llama una ejecución de pruebas. Voy a crear manualmente una ejecución de pruebas basada en Jest y voy a decir que ejecute todas las pruebas. Nuestra ejecución de pruebas de Jest conoce Jest. Conoce ciertas cosas que probablemente quieras hacer con Jest. De hecho, sabe que no solo hay opciones, sino que también te proporciona el texto de marcador de posición que te indica algunas de las opciones que podrías querer. Y de hecho, esa es la opción que voy a elegir. Voy a elegir la opción --watch. Ahora, cuando despliego las configuraciones disponibles, veo que acabo de ejecutar el archivo individual. Y luego está esta nueva configuración llamada todas las pruebas. Y cuando la ejecuto, obtengo la misma salida. Pero sigue ejecutándose. Así que si voy aquí y veo, oh, es hello React. Ahora, si necesito corregir mis pruebas, tan pronto como guardo, volverá a ejecutar mis pruebas. Ni siquiera tengo que hacer la acción de ejecutar mis pruebas. Solo tengo que escribir y guardar, y el resto se hará automáticamente.

Así que ahora he corregido mis pruebas. Todas están funcionando. Lucy y llegaré a eso en el siguiente segmento. Sí. ¿Es el siguiente segmento? Bueno, sí, aquí abajo. Muy bien, así es como hago el enfoque de ventanas divididas. Así que profundicemos un poco más en el TDD en acción, donde hago algo que falla. Sé que va a fallar. Veo el fallo y luego veo algunas de las cosas que puedo hacer y luego lo corrijo. Voy a poner este código aquí y ver un poco de autocompletado en acción. Voy a hacer esto un poco más pequeño. Muy bien. Voy a decir, ¿cómo lo llamo? Actual esperado. const actual igual a uno, constante esperado igual a dos. Podría ponerlos en la misma línea. Voy a escribir una afirmación de prueba sobre estos valores que están incrustados en la prueba, pero eso está bien cuando estás haciendo un enfoque de prueba primero. Y quiero esperar que actual sea igual, y así es como estoy usando el autocompletado aquí. No tengo que escribir todo, solo igual esperado, completar la declaración, guardar y mi prueba falla. Y me dice exactamente por qué falló mi prueba. Esperado y actual no eran iguales. Y nuevamente, si vuelvo, cambio, guardo, no escribo la acción, está observando y vuelve a ejecutar las pruebas. Esa es una pregunta interesante, Chris. Al comienzo de esto, justo antes de que te unieras, usé create-react-app 4.0.3. Y luego todo es lo mismo desde entonces, lo cual creo que significa que obtuvo su propio TypeScript, pero eso no afectaría esto. Así que no sé si por alguna razón obtuviste una versión anterior, oh, sí, está bien. Sospecho que es porque hello React es diferente a esto. Asegúrate de que esas dos cosas sean iguales. Espero que sean iguales porque de lo contrario voy a tener dificultades para depurar esto, hombre. Muy bien, acabamos de hacer desarrollo guiado por pruebas. Escribimos una prueba. Falló y luego vimos que falló y lo corregimos. Y en el camino, vimos que el IDE nos ayuda a fallar más rápido poniendo bleep en nuestra cara. Una ondulación roja en esta afirmación. Falló. El icono de la barra lateral cambió a rojo, lo que te indica qué pruebas fallaron. En la salida del ejecutor de pruebas, una prueba falló, una prueba pasó, o lo que sea. Y puedes usar todas estas formas diferentes de navegar entre tus pruebas exitosas y tus fallos. Y esa superposición, déjame volver a esa superposición, hagamos que esta prueba falle de nuevo. Cada vez más, estoy usando esto como mi entrada, mi ventana para ejecutar pruebas. Solo pongo el mouse encima de eso. Me dice qué sucedió. Y lo más importante, puedo hacer clic en eso y se ejecutará la prueba en el depurador. Se ejecutará bajo el depurador de Node.js, que está integrado en WebStorm. Se detendrá en ese punto de interrupción. Puedo moverme y ver qué valores hay. Incluso puedo decir cosas como Esperado, Esperado más 1, etc. Y cuando termino de ejecutar las pruebas, el depurador se apaga y elimina ese punto de interrupción. Así que este es un modo bastante completo de desarrollar. Y llegaré al final de la historia. Nunca fui al navegador. Muy bien. Conceptos básicos de TDD. Esto es de lo que Lucian estaba hablando. Esta es la forma en que desarrollo. Parece ser la forma en que Lucian también desarrolla. No me gustan las distracciones. Me gusta centrarme en lo que estoy haciendo actualmente. Y soy un hombre de cierta edad. No puedo molestarme en recordar 500 pestañas y necesito algo que engañe a mi mente para entrar en el flujo de las pruebas, entrar en el flujo de trabajar lentamente, deliberadamente, alegremente, bajo control.

11. Flujo de Desarrollo Guiado por Pruebas

Short description:

Para practicar el desarrollo guiado por pruebas, el orador oculta la herramienta del proyecto, desactiva las pestañas y divide las ventanas. Tienen su código a la izquierda, las pruebas a la derecha y la salida de las pruebas se ejecuta en la parte inferior. El orador demuestra hacer un cambio en el código que rompe las pruebas, resaltando el beneficio de tener todo en una sola pantalla. También mencionan recibir notificaciones en el escritorio para los resultados de las pruebas.

Y así es como lo hago: oculto la herramienta del proyecto. En realidad, desactivo las pestañas. Voy a la pestaña de Acciones. Pestaña. Eso son símbolos. Oh, lo siento. Acciones. Ubicación de la pestaña, Ninguna. Elijo eso, así que mis pestañas desaparecen. Y divido mis ventanas. Todo esto está en el texto, por cierto. Entonces tengo mi código a la izquierda. Mis pruebas para ese código a la derecha. Y la salida de las pruebas se ejecuta constantemente en la parte inferior. Y trabajo, y arreglo cosas, e implemento cosas, y todo está en la pantalla. Ahora, a veces, cuando estoy en mi monitor grande, tomo esta ventana de pruebas y la convierto en una ventana que puedo mover a otro monitor. Y luego realmente puedo concentrarme en el código a la izquierda, en realidad no, estoy al revés, para ti, código a la izquierda, pruebas a la derecha. Y en este caso, la salida del ejecutor de pruebas en otro monitor. Muy bien, hagamos un cambio en nuestro código que romperá esto. Voy a borrar estas tres líneas, guardar y mis pruebas se ejecutan correctamente. Mis pruebas se ejecutan correctamente. La otra que acabo de cerrar no estaba en modo de ejecución automática. Y si cambio algo en mi implementación, y luego mis pruebas fallan, eso es genial porque estoy viendo esto, estoy encima de ello, no tengo que ir a otra pestaña o abrir otro archivo, todo lo que necesito para mi código, mis pruebas y mi ejecutor de pruebas está en una sola pantalla. Así que felicidades, acabas de hacer TDD, acabas de hacer un cambio que hizo que las cosas fallaran. Lo revertiré, guardaré, las cosas estarán bien, eliminamos esas líneas. Puede que hayas visto ese salto, ese cambio de icono. Mi monitor grande aquí, tengo una notificación en el escritorio que dice que mis pruebas pasaron. Así que realmente, incluso podría ocultar esa ventana de herramientas y saber que recibiré una notificación en el escritorio que me dirá algo sobre mis pruebas.

12. Depuración y Parametrización de Componentes

Short description:

En esta parte, el orador hace una pausa para preguntas y aborda el uso de Enzyme y React Testing Library. Explican el cambio de Enzyme a React Testing Library y los beneficios de escribir pruebas que imitan el comportamiento del usuario. El orador también discute la parametrización del componente de la aplicación y la creación de una función auxiliar llamada label. Demuestran cómo escribir una prueba para la función label y explican el proceso de importación y ejecución de la prueba. El orador enfatiza la facilidad de evaluar funciones de JavaScript sin dependencias de React. El tutorial se centra en hacer que la función sea más dinámica.

De acuerdo, voy a hacer una pausa aquí, veamos, hemos estado trabajando durante una hora. Voy a hacer una pausa aquí y ver si tenemos alguna pregunta. Chris es interesante ver qué va a ser esto. Veo que tiene Enzyme y no estamos usando Enzyme y eso es React 16, así que es un poco antiguo. Chris, ¿utilizaste la última y mejor Create React app? Creo que es la versión 4.0.3 para generar tu proyecto. Muy bien, veamos. Muy bien, la pregunta sobre... Uh, veamos. Lucian, ¿pones tu... Lo haces al revés? ¿Pones tu código a la derecha o pones tus pruebas a la derecha?... Chris, lo siento. Evidentemente, eso es culpa mía. Pensé en cada paso del camino que actualicé correctamente los package.jsons, así que obviamente dejé algún artefacto perdido allí. Así que eso es culpa mía. Lo siento. ¿Puedes decirme en qué paso del tutorial estabas cuando hiciste clic en obtener el código del repositorio? ¿Fue el primero, Configuración del proyecto? Entonces, ¿fuiste aquí y hiciste clic aquí, Limpieza del proyecto? Oh, hombre. Tengo que limpiar la limpieza. Dios. Es difícil mantener estas cosas sincronizadas. Lo siento. En serio. De acuerdo, vamos a entrar en las pruebas y la depuración. Lo vimos brevemente, así que no me extenderé en el tema. De vuelta a Anton y esta pregunta sobre Enzyme. Esa es una buena pregunta. Yo era un gran fan de Enzyme. Y la versión original de este tutorial usaba Enzyme, pero luego create React... No creo que haya incluido Enzyme, pero comenzaron a incluir React Testing Library, que fue creado por Kent Dodds. Y Kent tenía un gran artículo explicando por qué lo escribió, qué problema resolvía, y realmente resonó conmigo en comparación con Enzyme. Su filosofía es escribir las pruebas que imitan el comportamiento del usuario. No tratarlo como software, escribirlo y tratarlo como si las personas lo usarán, como la interfaz pública de la salida renderizada. Pero tienes razón, Enzyme también me resultaba más familiar. Pero creo que está bastante claro que toda la energía está ahora detrás de React Testing Library porque Facebook lo designó como el incluido. Admito que fue extraño para mí cambiar. Por ejemplo, hay un comparador para ID, que me mató cuando hice una actualización más adelante en este tutorial, y realmente necesitaba algo para comparar. Así que artificialmente agregué un atributo de título innecesario al tutorial para tener un comparador. De acuerdo, palabras de lucha. Gracias por ese enlace sobre Adam. Gracias por ese enlace sobre cómo escribir pruebas. Y parece que... Muy bien, Lucien pone sus pruebas en la web. Muy bien, en este paso vamos a repasar la depuración. Probablemente no lo demostraré ya que ya lo hicimos. Pero, oh, espera, no, en realidad, tengo que hacer un poco de desarrollo en esto. Así que necesitamos hacer un poco más de limpieza. Vamos a parametrizar un poco nuestro componente, lo que generará un desarrollo guiado por pruebas. Y dejaremos que el IDE nos ayude con alt enter. Y luego mostraremos cómo crear un problema y resolverlo mediante la depuración. De acuerdo, déjame prepararme. Muy bien, comenzaré obteniendo... Actuaré como si me hubiera alejado del proyecto, volviera a él, cargar las cosas en mi cabeza y debe decir, hola React. Así que lo guardo y mostraré la salida del ejecutor de pruebas y mis pruebas se ejecutan, mis pruebas pasan. Muy bien, estoy de vuelta en el flujo. Estoy de vuelta en el flujo de pruebas. Lo que quiero hacer es parametrizar este componente de la aplicación. Así que lo que voy a hacer, voy a romper las reglas. No voy a hacer desarrollo guiado por pruebas. Voy a escribir el código y luego escribir la prueba. Luego, más adelante, cuando veas lo contrario, verás por qué lo hacemos de esa manera. Muy bien, voy a escribir una función llamada label. Esto no es un componente. Es solo un, como un ayudante. Y va a devolver hola React. Y luego voy a llamarlo aquí. Y cuando digo que todo está bien, nada se rompe en la tarea porque realmente no hemos cambiado la interfaz pública de esto. Pero lo que no he hecho es escribir una prueba para esta función. Así que volveré aquí, escribiré una prueba, probaré que genera una etiqueta. Supongo que no debería ser una G mayúscula. Esta es una función de flecha. Y la función de flecha primero obtendrá algo, alguna salida para probar. Así que diré que los resultados son iguales a label. Haré este error a propósito. Y luego esperaré que los resultados sean iguales a hola. Sí. Declaración completa. Y cuando digo que fallará, ¿por qué fallará? Porque no se ha importado Label. Puedo dejar que el IDE haga el trabajo de limpieza por mí. Me acerco a esto, presiono alt enter y hago que genere la importación. Cuando guardo las pruebas, se vuelven a ejecutar. Y mis pruebas pasan. Hice un poco de TDD en esto y lo divertido de esto es que esto evalúa solo las funciones de JavaScript, no es parte de React. No tiene un DOM ni un componente ni nada de eso. Así que fue bastante fácil hacerlo. Vamos a volver al tutorial. Y en esto acabamos de hacer esto. Y queremos hacer que su función sea un poco más dinámica. Es solo hola, React.

13. Parametrización y Desarrollo Guiado por Pruebas

Short description:

Queremos que sea parametrizado para que puedas decir hola, mundo, por ejemplo, o hacer algo como capitalizar lo que se pasó. Ahora vamos a hacer desarrollo guiado por pruebas. Lo vamos a cambiar para que falle. Así que voy a cambiar esto a React todo en mayúsculas. Cuando guardo, falla. Adam tiene razón. Exactamente como lo haría un usuario. Ese es el punto principal de Kent, lo cual creo que alienta a escribir componentes pequeños para mantener la velocidad. Mi prueba falló. Ahora tengo que hacer la implementación y arreglarlo.

Queremos que sea parametrizado para que puedas decir hola, mundo, por ejemplo, o hacer algo como capitalizar lo que se pasó. Ahora vamos a hacer desarrollo guiado por pruebas. Lo vamos a cambiar para que falle. Así que voy a cambiar esto a React todo en mayúsculas. Cuando guardo, falla. Adam tiene razón. Exactamente como lo haría un usuario. Ese es el punto principal de Kent, lo cual creo que alienta a escribir componentes pequeños para mantener la velocidad. Mi prueba falló. Ahora tengo que hacer la implementación y arreglarlo.

14. Implementación de Comportamiento y Depuración

Short description:

Para implementar el comportamiento que se está probando, se acepta un parámetro llamado 'name' y se utiliza en una cadena de plantilla. El IDE no proporciona ayuda para esto, pero TypeScript identifica el problema. Al pasar un valor a la prueba, se detecta el fallo de manera temprana. El IDE advierte sobre la falta de información de tipo, pero puede inferirla automáticamente. La combinación de TypeScript, desarrollo guiado por pruebas y el depurador permite depurar de manera eficiente sin necesidad de declaraciones console.log. Las pruebas se pueden ejecutar paso a paso y se puede identificar y solucionar el problema. Este enfoque permite a los desarrolladores mantenerse en el flujo y trabajar de manera eficiente.

Necesito implementar el comportamiento que estoy probando. Por lo tanto, lo que quiero hacer es aceptar un parámetro llamado 'name'. Luego quiero cambiar esto a una cadena de plantilla. Gracias IDE. Quiero decir 'name.toUpperCase'. Ahora, ves que no recibo ninguna ayuda del IDE en esto. No sabe qué tipo, oh, espera. Sí, lo haré. Ahora, cuando guardo, en la ejecución de la prueba, la prueba falla porque no estoy pasando un argumento y es nulo. Entonces, lo que quiero hacer es cambiar mi prueba para pasar un valor. En este caso, estoy fallando más rápido. El IDE me está mostrando subrayados rojos diciendo que violaste el contrato en React. Ni siquiera tuve que ejecutar la prueba para saber que fallé. Mucho menos enviarlo a producción y que mis usuarios me digan que olvidaste proporcionar un argumento aquí. Ahora, cuando proporciono el argumento, la prueba se ejecuta. Y veamos la etiqueta. Tampoco estoy proporcionando un valor aquí abajo. El otro lugar donde lo estoy usando. Entonces, mi prueba aquí pasó, mi prueba aquí arriba no. Voy a arreglar esto ahora poniendo React. Ahora mis pruebas pasan, pero estoy recibiendo una advertencia en mi IDE. ¿Qué es esta advertencia? Aquí es donde entra la escritura de tipos. Aquí es donde entra TypeScript. TypeScript me está diciendo: `Oye, somos un proyecto TypeScript. No pusiste ninguna información de tipo en este parámetro de función. Podría escribir la información de tipo. Otra vez, los IDE son buenos en este tipo de cosas. Tal vez puedan ayudarte. Voy a hacer Alt Enter. Y voy a decir inferir. Y el IDE, en este caso, o tal vez el Servicio de Lenguaje TypeScript, miró mi código, hizo una buena suposición de lo que se suponía que debía ser name, y proporcionó la información de tipo para ello. Así que eso funcionó bastante bien. Escribí una prueba. Escribí una implementación. Limpié algo de información de tipo. Tengo confianza. Recuerda, nunca fui a mi navegador. Me quedé en el flujo en mi herramienta. El IDE nos dio un Alt Enter. Arreglamos el problema de TypeScript. Pero digamos que hacemos algo que simplemente no podemos entender. Estamos cansados. Hemos estado mirándolo todo el día. Sabemos que es un problema estúpido, obvio, y no puedo entenderlo. Voy a pasar 42. ¿De acuerdo? Y mi prueba va a fallar. Nuevamente, fallar más rápido. Tengo un subrayado rojo. Aquí es donde la combinación de TypeScript y desarrollo guiado por pruebas realmente me ayuda. Pero en este caso, digamos que ni siquiera estoy mirando el subrayado. Estoy pensando, ¿qué está pasando? No puedo entender esto. ¿Sabes qué voy a hacer? YOLO. Lo voy a ejecutar bajo el depurador. Voy a investigar de forma interactiva, ver qué está pasando y ver si puedo encontrar el problema. La ejecución se ha detenido en mis pruebas. Hay otra cosa buena si lo quieres correcto, izquierdo o izquierdo, derecho, pero en este modo donde tienes tu código, tu prueba y la salida de tu ejecución de prueba, todo es muy familiar, donde están enterrados los cuerpos. Estoy en esta línea de mi prueba y puedo avanzar paso a paso en el código. En este caso, creo que voy a entrar, simplemente voy a entrar en el código. La ejecución salta a label porque llamamos a label y el siguiente paso fue saltar a label y pone mi cursor aquí. Puedo ver el valor de name, puedo ver el cierre, puedo ver el global, todas estas cosas. Puedo ver la traza de la pila si quiero subir más alto y ver qué había más arriba en la pila, y puedo investigar. Así que podría decir, bien, aM, ¿qué está pasando con name? Es 42. Bien, veamos, two uppercase, oh, Dios, ese es el problema. Pasé un entero. No pasé un número, no pasé una cadena. Ese es mi problema. Pude investigar, ver cuál era el problema, darme cuenta de mi error y convertirlo en una cadena. Cuando guardo, al final de esa pequeña sesión de investigación, encuentro la solución del problema, vuelvo a ejecutar mi prueba, todo está en verde, estoy bien. Usamos la combinación, de hecho, usamos una combinación realmente genial. Estamos escribiendo componentes y queremos escribir componentes y mantenernos en el flujo. No queremos un cambio de contexto entre un editor y una terminal y un navegador y dónde estoy. Y combiné el desarrollo guiado por pruebas, combiné TypeScript y combiné el depurador para tener una experiencia que me facilitó mucho llegar al lugar exacto donde quiero estar y explorar. Sin declaraciones console.log. Así que entramos en nuestro código, vimos cuál era el problema, volvamos a poner las cosas en su lugar. Salimos del depurador. Cerraremos la pestaña del depurador, lo dejaremos funcionando correctamente y estamos bien. Nuestras pruebas pasan, podemos pasar al siguiente paso. Me detendré aquí por un segundo, echaré un vistazo a algunos de los comentarios. Steven tiene un buen punto que y eso fue lo que resonó en mí, pensé en mis pruebas como implementaciones y exploré el interior de las cosas. No solo eso no fue valioso para mi cliente, a quien no le importaba, en realidad creó una enorme carga de mantenimiento porque cada vez que cambiaba los detalles internos, tenía que arreglar todas estas pruebas que estaban rotas por razones que realmente no importaban, hay otra estrategia de asegurarse de entender que las pruebas son tanto buenas como malas, son como este peso que arrastras en tu proyecto y cuando refactorizas cosas, tienes que cambiar un montón de pruebas. Obtengamos un enlace para el chico y lo pegaré en la parte superior del chico donde puedes ver un montón de consejos. Eso cubre eso, veamos si hay algo aquí. Sí, inferir la información de tipo es realmente agradable. Esa es una buena pregunta sobre el mockeo, en el mundo de Python, el mockeo es controvertido, a veces la gente lo llama un olor. Me interesaría saber de otros que estén haciendo pruebas aquí, ¿usan mucho el mockeo? Sé que en Gatsby sí. Ah, terapia, lo siento, okay volvamos a esto, voy a saltar esta parte porque no agrega nada nuevo a la parte importante que es enseñar sobre el desarrollo guiado por pruebas, primero las pruebas, solo entiendan que si tienen una necesidad, pueden ejecutar sus pruebas en el motor del navegador, o debería decir, para ejecutar sus, pueden depurar las cosas en el motor del navegador. Me alejo de hacer eso, pero Web Store lo hace muy fácil y sospecho que otras herramientas también lo hacen. Y así en este caso, lo que hice, está todo escrito aquí.

15. Uso del Protocolo de Desarrollo de Chrome y Funciones del IDE

Short description:

Discutimos el uso del protocolo de desarrollo de Chrome para controlar el motor JavaScript de Chrome y ejecutar código de forma remota. Esto nos permite depurar y probar nuestro código en una ventana privada de Chrome sin afectar nuestro uso personal de Chrome. También mencionamos el uso de jsdom en Node.js y preguntamos sobre posibles reemplazos. A continuación, exploramos las funciones en TSX y ECMAScript 6, y cómo el IDE puede ayudar con el autocompletado de código. Limpiamos nuestro código y nos aseguramos de que la configuración de nuestras pruebas se esté ejecutando correctamente.

Creas una configuración de ejecución que se trata de eso, y luego terminamos hablando del protocolo de desarrollo de Chrome para controlar de forma remota el motor JavaScript de Chrome. Y ejecutamos el código allí, pero se ve y se siente aquí exactamente como si estuvieras ejecutando bajo Node.js. Y puedes avanzar paso a paso en el código, ingresar en el código, ver fallar tus pruebas, y todas esas cosas, y lo que tienes aquí es una ventana privada de Chrome que se ejecuta bajo su propio perfil para no afectar tu uso personal de Chrome. Y al final de tu sesión de prueba, cierra esa ventana de Chrome, elimina el perfil para que pueda comenzar desde cero la próxima vez. Es bastante ingenioso.

Prefiero quedarme en Node.js, que actualmente utiliza jsdom. Pregunta para la audiencia. ¿Alguien ha escuchado rumores sobre reemplazar jsdom, que está implementado en Node.js, el navegador simulado de JavaScript, reemplazando jsdom con esa otra cosa de la que no puedo recordar el nombre? Bien. Parece que la gente está usando mock. Bueno. Tiene mucho sentido en aplicaciones de navegador reemplazar fetch, Axios y cosas así.

Bien. En adelante, vamos a ver cómo utilizar algunas funciones en TSX y ECMAScript 6, y cómo el IDE puede ayudarnos a completar cosas y mantenernos en el camino correcto. Vamos a limpiar nuestro código y probar un poco, asegurándonos de que la configuración de tus pruebas se esté ejecutando. De hecho, todavía estoy ejecutando mi servidor web, mi servidor de desarrollo de Webpack. Lo voy a detener, porque ¿sabes qué? No he ido al navegador en mucho tiempo. He estado escribiendo componentes, escribiendo funciones, escribiendo pruebas. Nunca vayas al navegador exactamente como debería ser, amigo. Sí. Hagamos algo de limpieza. Volvamos a poner app.test.txt en su estado original. Me desharé de esto, y voy a devolver mi componente a tener solo eso. Así que hola React. Deshazte de esto. Reformateo de código, optimizo las importaciones, porque hago eso mil veces al día.

16. Refactorización y Creación de Subcomponentes

Short description:

Alexei sugiere usar Cypress para pruebas unitarias. El orador discute los beneficios del desarrollo guiado por pruebas y el uso de IDEs. Mencionan tomar un descanso y el uso de Postman para APIs. El orador planea comenzar la refactorización y creación de subcomponentes. Explican el proceso de desarrollo guiado por pruebas y demuestran cómo hacer un subcomponente. La prueba falla, pero el orador planea importar el componente y continuar con el proceso de refactorización.

De acuerdo, Alexei está diciendo que le gusta ejecutar cosas en el DOM headless, y supongo que eso, ya sabes, karma es grande en eso en Angular. Alexei, te preguntaría, ¿preferirías usar Cypress para eso? En lugar de solo y decir, solo tienes que tener básicamente conjuntos de pruebas paralelos, uno que se trata de pruebas unitarias y otro que se trata de pruebas de navegador. De acuerdo, ahí tienes, Cypress. Cypress para todos. Pruebas unitarias en Cypress. De acuerdo. Muy bien. Muy bien. Aprendí algo hoy. Aprendí que volvemos a un punto en blanco. Y ese fue mi temporizador para darnos un pequeño descanso. Estamos una hora y 20 minutos en esta encuesta de la audiencia. ¿Quieres un descanso? Pon sí para descanso, no para no descanso. Es 50-50. Es 50-50, así que haremos medio descanso. Haremos un descanso de tres minutos. Así que tengo que son básicamente 20 minutos después de la hora a los 23 minutos después de la hora, haremos un descanso. Lo escribiré en ambos. 23 minutos después de la hora, continuamos. También voy a tomar agua. Muy bien, vuelvo enseguida. Muy bien. Eso es un buen punto Alexis sobre no probar la visibilidad. Suzanne, Postman para APIs es bastante bueno. Y nuestros IDEs tienen esta cosa de archivos HTTP, que te permite escribir en un archivo la solicitud que vas a realizar. Y se siente un poco como si estuvieras en un IDE en un editor, así que en realidad es genial. Paul, solo una nota. Tu chat de Zoom está atascado con DM, así que asegúrate de cambiar a todos. Mi chat de Zoom está atascado, oh vaya, huh. Gracias, Sherry. De acuerdo. De acuerdo, vamos a comenzar, o vamos a continuar. Vamos a continuar. Lo que vamos a hacer es que lo hemos vuelto a una condición de trabajo. Muy bien, y lo que queremos hacer es comenzar a hacer subcomponentes. Refactorización porque de eso se trata react. Convertir grandes rocas en rocas pequeñas, y haremos esta refactorización de una manera guiada por pruebas para que trabajemos con confianza, pero nos mantengamos en el flujo porque no abandonamos nuestro IDE. No tenemos que ir a mirar, déjame apagar el sonido. No tenemos que ir a mirar el navegador todo el tiempo. Mis disculpas. Disculpas por el sonido. Así que voy a hacer un subcomponente. Pero primero voy a ir a mi prueba. Y voy a escribir una prueba que estará rota, pero está bien. Espero que esté rota porque todavía estoy en el proceso de escribir la implementación. Así que aquí vamos. Vamos a hacer desarrollo guiado por pruebas de verdad. Voy a estar en app.test.tsx. Voy a escribir una nueva prueba. Asegurémonos de que esté bien. Esa pregunta sobre Cypress, hace cinco minutos, habría dicho simplemente. Pero Alexi está tratando de convencer a todos de que deberíamos usar Cypress para pruebas unitarias. Alexi, tengo que conseguir que vengas a un seminario web con nosotros para WebStorm y mostrar esto a todos, incluyéndome a mí. De acuerdo, voy a renderizar el encabezado. Renderiza un encabezado. Y voy a hacer una función de flecha. Voy a empezar a usar la biblioteca de pruebas de React un poco. Voy a decir const. Voy a desestructurar. Esto es una cosa de ES6. Voy a desestructurar los resultados de la renderización y tomar una cosa de ella, un cierre llamado Get by Text. Y esto va a ser ejecutar render. Como hacemos arriba y como hacemos aquí. Y así voy a estar en este caso renderizando el encabezado que la gente inteligente dirá que no existe. Y luego, ¿qué quiero hacer con este texto? Quiero ir a buscar algo del documento falso. Así que quiero agarrar un elemento de enlace como hago arriba. Get by text. Y espero que sea esta expresión regular de nuevo. Y luego haré mi afirmación. Espero que el elemento de enlace esté en el documento. Ahora, cuando digo, ¿qué crees que sucede? Se rompe porque el encabezado aún no existe. Lo que queremos hacer es convertir esto en un subcomponente. Y ¿qué haría normalmente? Iría aquí arriba. Iré a otro archivo, empezaría a escribir, nuestro IDE es inteligente. Puede ayudarnos con estas herramientas de limpieza. Así que voy a decir, oye, IDE. ¿Puedes ayudarme a refactorizar esto extrayéndolo a un componente? Claro. ¿Cómo te gustaría llamarlo? No me gusta este encabezado. ¿Quieres que sea un componente de clase o un componente de función? La función es lo nuevo y sexy. Así que vamos a tener un componente funcional y tomó eso. Hizo una nueva función. Reemplazó el lugar, hizo todo lo que tendría que hacer yo mismo. Puso una llamada a esa función aquí. Incluso hizo prettier por mí. Eres tan inteligente. Gracias. Um, ahora cuando guardo, mis pruebas aún fallan porque no lo he importado, pero está bien. Falla más rápido, léeme las ondas. Me dijo que había un problema.

17. Extracción de Subcomponentes y Refactorización

Short description:

En esta parte, el orador demuestra el desarrollo guiado por pruebas extrayendo un subcomponente. Muestran cómo activar la función de extracción de componentes utilizando el menú de refactorización del IDE. El orador discute la violación del principio de responsabilidad única y decide mover el subcomponente a su propio archivo. Demuestran la capacidad del IDE para generar automáticamente importaciones y limpiar símbolos innecesarios. Se enfatiza la importancia de las pruebas unitarias que se centran en una sola unidad y los beneficios del desarrollo guiado por pruebas en la refactorización.

Así que ve y obtén esa importación para mí. Oh, no puede importarlo porque no lo exporté. Ahora puedo generar la importación. Generó la importación para mí. Ya no tengo algo llamado label. Pensé, oh, eso fue un remanente. Eliminé esa prueba, pero no limpié mis importaciones. Así que ahora hice desarrollo guiado por pruebas para extraer un subcomponente. Escribí una prueba fallida. Fui al componente padre. Encontré lo que quería extraer. Lo seleccioné. Le pedí al IDE que hiciera una refactorización. Hizo la refactorización por mí. Tuve que agregar una exportación y volví y generé una importación. Mostraré nuevamente cómo... Digamos que quiero convertir eso en un componente. Esto responde a la pregunta de cómo activar la extracción de componentes. Abres el menú de refactorización. En Mac, es control T. Estoy a punto de presionarlo. Observa en la parte inferior de la pantalla si quieres ver el enlace de teclas de Windows. Refactorizar. Luego elijo extraer componente. Lo hice escribiendo rápidamente. Podría haber presionado 0. Podría haber usado el mouse, lo que sea. Así que abrí el menú de refactorización y elegí extraer componente. Ahora tengo todo esto seleccionado. No es necesario. Puedo hacer clic en el símbolo e iniciarlo desde allí. Muy bien, déjame venir y mirar. Veo que hay una conversación interesante en Zoom sobre por qué es genial el testing. Todo eso es genial. Ahora estoy violando el principio de responsabilidad única. Tengo un subcomponente en el archivo del componente padre app. Así que creo que me gustaría extraer esto a su propio archivo y luego escribir su propia prueba. ¿Puede el IDE hacer el trabajo sucio por nosotros? Probablemente, de lo contrario no estaría haciendo este punto ahora mismo. Abre la refactorización y mueve. Debo decir que no seleccioné todo esto. Solo puse el cursor en el símbolo. Mover refactorización. Luego obtengo un cuadro de diálogo. ¿Dónde te gustaría moverlo? Mira lo que hizo. Rellenó el nombre del archivo para mí. Exactamente como quería que fuera. Te da algunas opciones sobre algunos miembros para mover más tarde. Veremos cómo las props, el tipo que usamos para la definición de props, pueden ir con él. Voy a presionar refactorizar. Lo abre, me pide agregarlo a get. Tengo esto aquí y mira lo que tengo de vuelta donde estaba. Una importación reemplaza la definición que tengo, personas inteligentes verán que mi prueba puede arrastrarse a un nuevo archivo. Sospecho que eso probablemente es pedir demasiado al IDE, así que me gustaría mover esto. Serpientes. Pero no creo que pueda extraer esto ahora, de nuevo, ¿verdad? Así que tomaré esto y crearé un nuevo archivo llamado agregando esa prueba que sí, X. Pegar esto allí. Observa que cuando pego, tiene la costumbre de generar las importaciones que necesito por mí. Muy bien, y luego tengo un poco de sobras aquí atrás. Un símbolo que no necesito de la importación porque no estoy testing heading en este archivo app. Ya no son pruebas de texto. Podría eliminarlo o podría decir, oye, IDE. Limpia en el archivo cinco, ejecuta optimizar importaciones y ahora esa importación ha desaparecido. Este archivo de prueba, principio de responsabilidad única. Se trata de un. Este archivo de prueba, principio de responsabilidad única. Guardo todo una vez más. Mantengo mi ventilador de la CPU funcionando y todas mis pruebas y todos mis archivos se ejecutan. Bien. Y veamos. Sí, la belleza de las pruebas unitarias es la velocidad velocidad de ejecución, un segundo beneficio de esto. Me pregunto si Lexi estaría de acuerdo conmigo en que un beneficio secundario no es arrastrar el universo cuando estás refactorizando. Las pruebas unitarias realmente deberían centrarse en una unidad para que si algo más cambia no tengas que ir a cien cosas y tratar de recordar lo que estabas haciendo hace seis meses.

18. Refactorización y Valor Predeterminado de Propiedad

Short description:

Extraemos la información de tipo de las props en línea a un tipo independiente llamado Heading Props. Referenciamos este tipo en el código, lo que facilita su lectura. Sin embargo, todavía necesitamos abordar el problema del valor predeterminado de la prop. Al usar un argumento predeterminado de ES6, podemos cumplir con el contrato anterior y asegurarnos de que las pruebas pasen. TypeScript puede mostrar un error debido a la prop name requerida, pero podemos resolver esto informando a TypeScript que la prop name es opcional. Este enfoque nos permite cumplir con el principio de responsabilidad única y mantener una estructura de código limpia.

En esta parte de la masterclass, hemos realizado la refactorización del subcomponente de encabezado. Hicimos la extracción y ahora está en su propio archivo. Ahora, digamos que creo que lo hice. Sí, lo hice fuera de orden. Mis disculpas. Lo que quiero hacer es volver a agregar los argumentos y agregar valores predeterminados para que mi encabezado sea parametrizable. Tomaré esta prueba. Estoy en el archivo de prueba de encabezado y escribí una prueba para pasar el nombre a nuestro encabezado. Aún no he ejecutado el ejecutor de pruebas y sé que fallará porque tengo un subrayado rojo debido a TypeScript. TypeScript me está diciendo cuál es mi problema. De todos modos, lo ejecutaré. Dejemos que la prueba falle. Ya vimos lo que iba a suceder aquí. Necesitamos agregar un parámetro. En este caso, sin embargo, como es una función, no pasaremos name como argumento. Obtendremos las props y necesitamos desestructurar la prop name de ellas. Así que diré name, lo que me permite decir aquí. ¿Estoy usando mayúsculas? No, no lo estoy. Guardaré. Y digamos que esta prueba. Necesito. Iré poco a poco y arreglaré algunas de estas cosas. Así debería ser. Oh, signo de dólar. Tonto de mí. No estoy en un literal. Esta prueba pasa. Esta prueba falla porque ahora tengo una prop requerida. He hecho una refactorización que rompió el contrato. Y otros usos me están diciendo que el contrato se rompió. No tuve que ejecutar la prueba para saber que fallé, porque tengo un subrayado rojo para eso. ¿Cuál es la solución para esto? Entramos en las props y la escritura de tipos. El primer intento será en línea la información de tipo de las props. Guardo eso. Y TypeScript está más contento con algunas de estas cosas, pero aún no tengo una solución para esto. Quiero poder usar el encabezado sin pasar un argumento. Lo primero que haré, sin embargo, es en lugar de la información de tipo en línea, casi todos ponen los tipos de prop en un símbolo independiente en TypeScript. Lo hice durante mucho tiempo con interfaces. Aún creo que la mayoría de las personas usan interfaces. Vi un buen artículo que decía que uses type en lugar de interface, porque type es más limitado. Y la información de escritura que colocas en las props debe ser limitada. Podría extraer esto e ir a comenzar a escribir type, allá arriba, volver, escribir más cosas aquí. ¿Crees que podría extraer una interfaz? ¿Crees que podría refactorizar algo sobre la interfaz? ¿Por qué? Sí, puedo. Oh, tengo que estar dentro. Digamos, sí. Y lo llamaré Heading Props. Verás lo que hizo aquí. Creó algo llamado Interface Heading Props. Veamos, quiero establecer una interfaz en esto. Así que dejaré que sea una interfaz porque creo que eso es lo que tengo en mi tutorial. Ahora, veamos. Eso es lo que quería hacer. OK. Ya está formateado. He extraído la información de tipo en línea sobre mis props, la extraje a un tipo independiente y luego la referencié. Es tan fácil de leer. Es genial ver eso. Muy bien. Aún no he resuelto el problema del valor predeterminado de la prop. Lo que quiero es cumplir con el contrato anterior usando un argumento predeterminado de ES6. Así que vamos a hacer eso. Arreglemos esto para que hello, React siga funcionando. Lo haría poniendo un argumento predeterminado aquí. Pero algo más va a ir mal aquí. Ejecuto mis pruebas y mis pruebas pasan. Estoy en verde. Estoy en verde. Estoy en verde, estoy en verde, estoy en verde. Pero TypeScript está enojado conmigo. TypeScript está enojado conmigo en esta línea. ¿Por qué TypeScript está enojado conmigo? Vamos a pasar el cursor sobre eso. Creo que uno de ustedes tiene el micrófono encendido. Podemos escuchar algo de ruido de fondo. TypeScript nos está diciendo exactamente cuál es el problema. Está en heading props. Y está diciendo que algo es requerido. Se requiere name. Pero no se está proporcionando aquí. Así que lo que necesito hacer es decirle a TypeScript que name, según este contrato, es opcional porque tenemos un argumento predeterminado. Guardo eso. Las pruebas aún se ejecutan. El compilador de TypeScript está contento. Estamos en un buen lugar en esto. Y si hubiera hecho eso al principio de esta refactorización, no habría tenido esa prueba rota si hubiera dicho, OK, opcional. No tienes que pasar un nombre a un encabezado. Ya he mencionado el principio de responsabilidad única. Ya hemos movido el subcomponente de tipo a su propio archivo. Lo que debería señalar es que haré, fingiré decir subheading.

19. Refactorización y Extracción de Componentes

Short description:

Refactorizamos y extraemos un componente moviendo el subcomponente y sus dependencias a un nuevo archivo. JSX y TSX tienen ciertas restricciones y mensajes de error proporcionados por TypeScript. La combinación de desarrollo guiado por pruebas y tipado en TypeScript nos permite fallar más rápido y recibir comentarios inmediatos en nuestro IDE. Discutimos varios temas relacionados con las pruebas, como la simulación de componentes secundarios, la cobertura de código y el uso de React Testing Library. También se menciona Storybook como una herramienta para mostrar variaciones de componentes. Luego pasamos a los componentes de clase e introducimos el concepto de props. Creamos un nuevo archivo para un componente de contador y escribimos una prueba para ello.

Refactorizamos y extraemos componentes. Extraer. De todos modos, cuando lo mencioné, me habría dado la opción de llevar no solo el componente, sino también la definición de tipo y mover el símbolo al nuevo archivo. Así que esa es una forma bastante inteligente de refactorizar. Toma el subcomponente que deseas crear y todas las cosas en las que depende, y muévelo al nuevo archivo. Estamos en buena forma desde una perspectiva de principio de responsabilidad única.

Creo que omitiré esto un poco, el JSX y el TSX. Creo que la mayoría de ustedes saben que si digo class, está roto en JSX, TSX, porque ese es un nombre reservado en JavaScript y TypeScript, la declaración de clase. Entonces React te dice que debes nombrarlo class name. Y obtienes mucha ayuda para estas cosas de TSX, gracias a TypeScript. Puede mostrar mensajes de error realmente significativos sobre lo que no está permitido en eso. De hecho, eso fue lo que me metió en problemas en la reescritura, eso todavía está ahí en los videos. No puedes usar la etiqueta y los elementos for en spans, que es lo que estaba usando. Solo están en elementos de entrada. Muy bien.

Lo que mostramos aquí fue una combinación de dos cosas que nos ayudan a fallar más rápido y mantenernos en el flujo, el desarrollo guiado por pruebas y el tipado, TypeScript. Y la combinación de los dos, no tienes que enviarlo, descubrir que fallaste. No tienes que ejecutarlo en un navegador, rociar console log en 50 lugares, esperar tropezar con él. Ni siquiera tienes que ejecutar tus pruebas, no tienes que escribir una prueba y ejecutarla para descubrir que fallaste. Puedes obtener una decoración en tu IDE que te dice que rompiste el contrato. Muy bien, pasemos al siguiente paso. Y déjame poner el temporizador para estar en buena forma aquí. Responderé cualquier pregunta. Revisaré algunos puntos del chat. Siéntete libre de decirme si voy demasiado rápido o demasiado lento, hablando demasiado fuerte, lo que sea. Veamos. No creo que esté al día con todo esto. Este punto sobre probar el contenido de un hijo no es relevante, es un buen punto. Eso es algo de enzyme, ¿verdad? Shallow versus mount. Me llevó un tiempo dejar de pensar en eso cuando cambié a React Testing Library. Simulación de devoluciones de llamada, todos estos son excelentes puntos sobre la simulación de componentes secundarios. Cheri, es un punto interesante sobre el IDE, sabes que soy de Python y de la web y JavaScript, esas cosas no se escribieron. Se escribieron para ser tan simples que no necesitabas un IDE. Pero ahora, con sistemas más grandes donde cosas como React con subcomponentes, y cosas así, las herramientas realmente pueden ayudar. Y espero que los editores y los IDE más inteligentes realmente puedan brindar algunas mejoras de productividad en esto. Alexey, buena pregunta sobre get by text. Alexey, ¿te encuentras a ti mismo o alguien se encuentra a sí mismo usando el parche de escape data-test-ID en la biblioteca de pruebas? Siempre que lo hago, siento que hice algo mal. Buena pregunta sobre la cobertura de código. Me importa mucho más la cobertura en Python que en JavaScript. No sé por qué. No tiene sentido. Pero simplemente no era parte de mi cultura hacer cobertura, de hecho, el IDE hace que sea muy fácil obtener la cobertura integrada directamente en tu editor. Debería hacer eso más a menudo. Buen punto, Stephen, sobre las recomendaciones sobre qué biblioteca de aserciones usar. Supongo que lo asíncrono influye un poco en eso. 88%, ese es un gran número. ¿Por qué no? Y entonces, Brandon, estábamos hablando antes sobre qué probar, cuánto probar. Y esa React Testing Library realmente está cambiando a las personas para no probar la implementación, sino probar la forma en que las personas van a usar la implementación. Y a medida que detectas rutas de código como, oh, este componente no va a mostrar el encabezado si esto se evalúa como falso, entonces escribe una prueba para algo así. No pruebes solo un estado de un componente. Storybook, ¿alguien está usando Storybook? Porque Storybook realmente ayuda a promover esa idea de todas las variaciones de un componente. Oh, mira, algunos fanáticos de Storybook por ahí. Muy bien. De acuerdo, cambiemos a componentes de clase solo por diversión para prepararnos para hablar sobre el estado más adelante. Hasta ahora hemos estado usando componentes funcionales. Actualmente, Anton está construyendo un proyecto con LearnN Storybook. Muy bien. Esa es una buena combinación. LearnN Storybook produce mucho contenido. Esa es una buena combinación. Learn ha estado presente durante mucho tiempo. Supongo que Learn está mirando a Yarn 2 diciendo, vuelve a mí cuando tengas la historia clara, Yarn 2. Componentes de clase con props. Vamos a hacer algo similar a lo que acabamos de hacer, una prop. Pero eso fue con un componente funcional. Esta vez, veremos ideas similares sobre información de tipo para props, pero en el contexto de un componente basado en clases. Admitiré que no soy un fanático de la programación funcional. Si hay algo que siento que se expresa bien como una clase, lo hago. No me odien. Vamos a crear un nuevo archivo. Vamos a hacer un contador. El nombre del componente ya revela hacia dónde se dirige esto. Habrá algún estado y usaremos estado local en el componente en lugar de Redux o emr, mi nuevo mejor amigo. Y así, escribiré una prueba primero. Ahorrémonos algo de tiempo. Cortar y pegar. Cortar y pegar para ganar. En el lado de la prueba, crearé un nuevo archivo. Counter.test.tsx. Miren qué rápido puede escribir Paul. La prueba está rota y TypeScript está enojado por razones obvias. El archivo no existe. Pero nuevamente, fallar más rápido, TypeScript nos dijo que eso no existe. Obtendremos un punto de partida aquí. Nuevamente, haré trampa y no escribiré esto. Vamos a escribir mucho en esto a medida que avanzamos, así que está bien. Me gustaría recordarte, especialmente si te uniste un poco después del principio, que no tengo que ejecutar todas las pruebas. Puedo ir directamente a esta prueba y ejecutarla o ejecutar solo las pruebas del contador haciendo esto. Muy bien.

20. Conexión del Componente Contador y Pruebas

Short description:

Resolvimos la importación para el componente contador y agregamos pruebas para la etiqueta y el contador. Extraímos la información de tipo para las props a un tipo independiente y agregamos un valor predeterminado para la prop de la etiqueta. Luego conectamos el componente contador a la aplicación y escribimos pruebas para asegurarnos de que se esté renderizando correctamente. Todo pasó y estamos listos para continuar.

Resolvamos la importación ahora que está ahí. Oh, en realidad, tan pronto como pegué, lo hizo por mí. Gracias. O detectó que estaba allí. Gracias IDE. Tengo un contador y está renderizando una etiqueta en un contador. Es un span con un título. Esta es la evidencia de que me enteré de que React cambió sus typings de TypeScript y decidió no permitir etiquetas y for en spans. Así que este es el contrato público, habrá una etiqueta con un valor. Y luego habrá otro span que tiene el recuento real. Estoy probando ambos, la etiqueta y estoy probando el recuento. Veamos si hay algo. NPM audit, sí, sí, supongo que confié en la auditoría de yarn y no confié en la auditoría de NPM, pero eso es un buen punto. Me pregunto si hay algún progreso en eso. ¿Alguien sabe si alguna vez NPM 45 tendrá capacidades de auditoría? OK, hay una pregunta sobre verificar si el recuento es correcto en lugar de en el documento. Buena pregunta, podría estar verificando si el valor simplemente está verificando eso. Supongo que en este punto, no quiero probar demasiado y si cambio de opinión, mis pruebas fallarán. Digo que este recuento esta prueba seguirá pasando, pero si probara el valor real, no lo haría. Y supongo que he tomado mi decisión. Realmente no me importa lo que diga, pero tienes que tener una etiqueta como si lo hubieras localizado para tener una palabra diferente para el recuento NOM. Estamos bien. Vamos a mostrar con componentes basados en clases cómo hacer una prop. Y lo haremos usando este proceso consistente que hemos estado haciendo. Vamos a escribir una prueba fallida, arreglar el nuevo componente tonto y luego ir a la cosa que lo llama, que aún no tenemos nada que lo llame, y asegurarnos de que lo use correctamente. Así que vamos a agregar otra prueba para el caso en el que pasemos una etiqueta. Creo que sabes cómo va a ir esta película. Se romperá bastante rápido. Cortar y pegar. Todavía estoy en las pruebas del contador. Falló bastante rápido. ¿Por qué fallaste? Y ni siquiera he ejecutado la prueba todavía. ¿Por qué fallaste? Oh, me estás diciendo exactamente por qué fallaste, porque falta la etiqueta. Muy bien, pero de todos modos ejecutaré la prueba para que podamos ver que las pruebas también fallan. No, las pruebas no fallan, porque este es un fallo de TypeScript. Esto no es un fallo en tiempo de ejecución. Muy bien, lo que queremos es más tipado en nuestro componente. Tenemos nuestro componente aquí y queremos algún tipado aquí. Y lo que queremos decir es, ya vimos esto antes también, tipado en línea de las props. Y cuando hacemos eso, algunas cosas cambian. Es opcional, el signo de interrogación, por lo que esto todavía pasó. Pero aceptamos el paso de una etiqueta, por lo que esto todavía está bien con TypeScript. Pero lo que queremos hacer de nuevo es, no queremos esa información de tipo en línea. Así que le pedimos al IDE que lo extraiga a un tipo independiente. Elijo un alias de tipo y voy a decir props del contador. Y hace la definición de tipo por mí. Eso tiene la etiqueta opcional. Así que TypeScript está contento, Jest está contento, estoy contento. Y el componente es lo que se llama un genérico para la clase de un componente. Lo hemos movido a un tipo independiente. La definición de tipo dice que la etiqueta puede ser opcional. ¿Pero podemos tener un valor predeterminado? Y esto es más complicado ahora, porque antes cuando teníamos el encabezado, lo estábamos pasando a una función el valor llamado props, que era un objeto que se podía desestructurar y la desestructuración de ES6 admite esto. Pero no estamos en la desestructuración. A menos que tenga un constructor o algo así, ni siquiera sé si puedo hacerlo para eso. Entonces, ¿dónde puedo decir un valor predeterminado para la prop de la etiqueta? Entonces, lo que voy a hacer es comenzar aquí y voy a decir en mi render, voy a hacer la desestructuración nuevamente, lo que me permite tener un valor predeterminado, que solo se activa si las props, esto no tiene una etiqueta. De lo contrario, se usa la cosa que se pasa. Y luego tengo que hacer esto. Solo obtendré mi portada aquí. Ahora, cuando guardo, ejecuto mis pruebas, todas mis pruebas pasan y tengo un valor predeterminado para el recuento. Y nuevamente, usando las variables locales para renderizar, déjame echar un vistazo aquí y decir. Muy bien, Lexi ha usado data-test-ID. Lexi, cuando lo usas, ¿siempre tienes la sensación de que estoy haciendo algo mal que debería hacerse de una mejor manera? Elaina, creo que hubo respuestas a tu pregunta sobre la localización. Y Adam da una respuesta frontal, pero este tutorial no trata sobre accesibilidad y localización. Muy bien, gracias, Elaina. OK, ahora necesitamos conectar la interfaz de usuario. En realidad, aún no está en nuestra aplicación porque nuestro componente principal no está usando el contador. Entonces necesitamos que el componente principal use el contador. Voy a ir a app.tsx y lo agregaré justo después de esto. ¿Necesito detenerme e ir al principio, agregar por importación y luego volver a donde estaba, tratar de recordar dónde estaba, tratar de recordar qué estaba haciendo? No, los IDE de hoy en día, el servicio de lenguaje TypeScript puede automatizar todo esto por nosotros. Quiero resolver un contador con esa etiqueta. Solo puedo comenzar a escribir. Ha buscado en mi proyecto, en realidad ya ha indexado mi proyecto, por lo que sabe dónde están todos los cuerpos enterrados, y puedo simplemente elegir contador. Conoce las props, por lo que puedo usar la etiqueta y diré, ¿cuál es mi actual? Así que generó la importación por mí cuando hice la autocompletar. Así que estamos en buena forma. Ahora tenemos algo que usa nuestro contador, pero nuestras pruebas no se rompieron porque la prueba de la aplicación realmente ni siquiera esperaba que eso estuviera allí. Deberíamos haber escrito una prueba primero antes de agregar esto. Muy bien, hagámoslo. Así que mis pruebas pasan, pero quiero probar en la aplicación para ver si la etiqueta está presente. Solo voy a ver si el componente está ahí, no todo sobre el componente, el subcomponente, porque no es realmente necesario. Así que se renderizó. Oh, solo tomaré todo y lo cortaré y pegaré. De todos modos, está haciendo un mejor trabajo de prueba. Este es el nivel superior de la aplicación. Queremos ver si ese texto está ahí. Queremos ver si nuestro componente contador está ahí. Y así vamos a hacer lo mismo que acabamos de tener en nuestra prueba de contador. Queremos esto. Realmente, todo lo que hice fue cortar y pegar esto aquí. Falla porque volví en el tiempo y fingí que hice TDD y aún no lo he puesto. Ahora, cuando lo pongo, digo, ¿implementé esto correctamente? Bueno, seguro que lo hice.

21. Implementación del Estado en el Componente Contador

Short description:

Mis pruebas pasaron, demostrando que mi componente de clase de contador está en el componente principal de la aplicación. Echemos un vistazo en el navegador. El componente contador tiene un estilo deficiente, pero abordaremos eso en la próxima parte. Nos queda una hora, así que detengámonos para preguntas. Discutimos las pruebas de los componentes secundarios y el uso de selectores. También se menciona la prueba visual y el uso de Cypress. Cambiamos de un componente funcional a un componente basado en clases para tener un estado local fácil. Comenzamos con una prueba fallida e implementamos el componente contador. La prueba falla porque el contador no comienza en cero. Procedemos a implementar el estado en el componente de clase.

Porque mis pruebas pasaron. ¡Hurra! Ahora tengo una prueba que demuestra que mi componente de clase de contador está en el componente principal de la aplicación. Eso es una buena noticia. Hasta ahora todo está bien. Y creo que eso es un error tipográfico. No, no, no, no es un error tipográfico. Finalmente me está animando. ¿Podemos finalmente echar un vistazo a cómo se ve en el navegador? Voy a volver a mi script de inicio. Vamos a ejecutarlo. Generará el servidor de desarrollo del navegador, etc. Y en realidad veo que el componente contador tiene un estilo deficiente porque son dos spans, mostrando el actual y uno. Muy bien, voy a empezar con la siguiente parte, detenerme, hacer algunas preguntas, ver la hora. Nos queda una hora. Nos vamos a quedar sin tiempo. Muchos más uno para Storybook. ¡Hurra! Alexei está escribiendo en Discord. Así que volveré al chat de Zoom. Suzanne, espero haberlo hecho bien. Esa no es Suzanne. Correctamente me está señalando que no puse una prueba primero. Tenías razón. Veamos. Muy bien, estamos actualizados en eso. Alexei está preguntando, escribe una prueba de integración primero para asegurarte de que la aplicación esté usando el Contador. Creo que eso es similar a lo que Suzanne me estaba señalando, que debería haberlo hecho primero antes de pegarlo. Me pregunto si lo hice bien en mi texto. Veamos. Mi texto, no, no lo hice. Mi texto rompió las reglas. Debería intercambiar eso y eso y poner primero la prueba. Nota para mí mismo, nunca recordaré esa nota. Veamos qué más tenemos. getByTitle espera de dos a tres argumentos. Lo lograste. ¿Qué fue, Dylan? ¿Qué salió mal con eso? Alexi tiene razón, ahora que tengo una prueba integrada, si cambio la estructura interna del contador, la prueba de la aplicación se romperá y la prueba del contador también se romperá. Y así, la pregunta de los componentes principales con componentes secundarios, ¿deberías probar la estructura de los componentes secundarios o simplemente verificar si están en el documento? Alexi, ¿estoy entendiendo correctamente el punto que estás haciendo? Es realmente una cuestión de, sí. Ahí lo tienes. Supongo que lo que harías para eso es, ¿hay un selector de la biblioteca de pruebas de React que indique que un componente está en un árbol? Supongo que no lo habría. Lo que terminarías haciendo es en el contador, pondrías algo aquí que dijera, eh, soy una clase de nombre, título, o algún selector que sea visible. Prueba de datos. Ja ja, aquí vamos, sí, prueba de datos. Veamos. Reestructuré getByTitle de la cosa. Oh, sí, OK. ¿Te atrapó la desestructuración, eh? Muy bien, ¿recibiste alguna advertencia del Servicio de Lenguaje TypeScript, Dillon, cuando hiciste mal la desestructuración? ¿Deberías haberlo hecho? Oh, bien, muy bien. Te salió un subrayado rojo. Fallaste más rápido. Genial. Muy bien, algunos comentarios en Discord. Prueba visual, también estoy interesado en algo así. Algo así como que he visto algunas cosas donde pueden capturar instantáneas de los píxeles de una página y luego comparar más tarde y ver si tu diseño CSS cambió. Me pregunto si te refieres a algo así. Creo que estás hablando de algo así. Florian también menciona que puedes hacer algunas propiedades calculadas para ver si las cosas están en la posición en la que creen que están. Sospecho que eso es algo de Cypress, aunque no será algo del DOM de JS. Cypress hace eso, dice June. Todos los caminos llevan a Cypress, ¿verdad? Todos los caminos llevan a un consumo infinito de energía al ejecutar tus pruebas. Muy bien, voy a seguir adelante y vamos a volver a esto y por qué cambiamos de un componente funcional a un componente basado en clases para tener un estado local fácil. En este caso, contador. Vamos a hacer un componente de clase muy simple. Tendrá estado. Y luego ese estado necesita alguna tipificación de TypeScript para tener subrayados rojos y autocompletado. Pero se va a poner un poco raro, lo que te hará pensar en volver a los componentes funcionales y los hooks. Muy bien. Siempre comienza con una prueba. Vamos a escribir primero una prueba fallida para la implementación, conectada al componente principal. Blah, blah, blah. Queremos contador y contador. Así que tengo el contador aquí. Quiero contador.test aquí. Y ahora te apagaré. Y solo tendré mi ejecutor de pruebas. Vamos a escribir una nueva prueba. Esto va a ser sobre el estado, no sobre la presentación. Y queremos que nuestro contador comience en cero. Así que voy a cortar y pegar esto. Y luego guardarlo, lo que lo hace ejecutar. Y falla porque no comenzamos en cero. Actualmente estamos en uno. Pero eso no es un valor real de estado. Es solo el carácter en la pantalla. Así que esta prueba falló correctamente. Ahora tenemos que ir a la implementación. Tenemos un componente de clase base. Voy a apartarlo por un momento. Tengo un componente de clase base que tiene una definición de tipo para las props. Tal vez necesite una definición de tipo para el estado. Y lo que vamos a hacer esta vez, no lo sé.

22. Gestión del Estado del Componente con TypeScript

Short description:

Aprendí primero los componentes basados en clases y hay un lugar para el estado local. Agregamos un segundo genérico para el estado junto con las indicaciones y establecimos un estado inicial como una variable de clase. Sin embargo, la inmutabilidad es un problema y deberíamos usar el método setState. Podemos usar TypeScript para detectar asignaciones de solo lectura. Establecemos un valor de alcance de módulo para el estado inicial y usamos el prefijo de solo lectura. Ahora podemos cambiar el valor del estado. Volvamos a tener un valor inicial e implementémoslo usando un método de ciclo de vida. Si se pasó una propiedad, llamamos a setState en lugar de la asignación manual.

Podría haber hecho lo mismo en línea y luego extraerlo, pero hay algo en el estado que me hace querer razonar sobre él por separado de la implementación del componente. Así que voy a escribir esto. Voy a crear un nuevo tipo. Lo llamaré CounterState. Tendrá, ¿cómo llamé a ese valor? Count. Eso es un número. El IDE me está diciendo que aún no lo estás usando. Lo sé. ¿Y dónde pongo esto en mi declaración de CLASE dentro del genérico? Y eso me permite decir que el primer argumento del genérico es la información de las propiedades. El segundo argumento del genérico es la información del estado. De hecho, mira eso. El mensaje emergente nos dice con P y S, el siempre útil P y el siempre útil S. Ese es el orden de los argumentos dentro del genérico. June, estoy bien con los componentes basados en clases, probablemente porque los aprendí primero, y el mundo de Python no está tan interesado en la programación funcional como el mundo del front-end. Pero quiero decir, hay un lugar para el estado local, el estado local de los componentes. Así que ahora tengo la información de tipo correcta. Necesito obtener el estado real. Y lo haré en iteraciones y aprenderé en el camino sobre algunos errores. Me interesará ver si lo que considero la mejor manera está equivocado, si hay una mejor manera en estos días porque las cosas siempre cambian. Ahora estoy dentro de la clase. Y voy a agregar algo como un campo de atributo de clase. Le daré información de tipo y diré que el estado es de este tipo, y aquí está el valor inicial. Eso está bien. Y luego eso me permite hacer esto. Reemplazaré el uno con this.state., mira eso, autocompletar, ¡yay! Muy bien. Guardaré, dejaré que mis pruebas se vuelvan a ejecutar. Mira eso, se volvió verde y obtuve una pequeña notificación en mi escritorio que dice que mis pruebas pasaron. Ahora tengo un componente con estado que decide internamente que comienza en cero. Estoy muy contento de que estén discutiendo entre ustedes sobre el lugar de los componentes de clase versus los componentes funcionales. Podría participar, pero probablemente lo haría mal porque es muy cuestión de estilo. Agregamos un segundo genérico para el estado junto con las indicaciones y establecimos un estado inicial como una variable de clase, lo que nos dio algunos beneficios. Pero como saben, el gran problema con esto es la inmutabilidad, no se supone que debes asignar directamente a ese objeto, se supone que debes usar el método setState para llegar allí. ¿Qué pasa si no lo haces? ¿Qué pasa si haces algo como this.state.count += 1? ¿No te gustaría que el compilador lo subrayara en rojo? ¿Si TypeScript pudiera detectar que algo es de solo lectura y que le estás asignando? Puedes hacerlo, y lo haremos. Reemplazaremos nuestra definición de tipo con esto. Estableceremos un valor de alcance de módulo para el estado inicial con sus valores. Y voy a hacer esta extraña definición de tipo. Teníamos CounterState antes. Lo vemos aquí. Y lo que está diciendo es que está usando readonly como el tipo. Esa es una palabra clave incorporada en TypeScript. Por eso no se importa. Y en el genérico, vamos a decir que la forma de esta cosa que es de solo lectura es esta. Y una vez que hagamos eso, ahora necesitamos usar el estado inicial en lugar de nuestra definición manual. Así que lo cambiaremos también para usar el prefijo de solo lectura, readonly. Y ahora, si quisiera hacer algo que cambie el valor, veremos en un segundo que ahora puedo hacerlo. Bueno, eso es genial. De todos modos, volvamos a lo que se supone que debemos hacer, que es incrementar el contador. Haré una pausa aquí y miraré por aquí. Eso es maravilloso. Sí. Eso es un buen punto, Elena. El problema opuesto. Eso es gracioso. Es cierto. De hecho, creo que estoy más de acuerdo contigo que con la posición de quien estaba diciendo lo contrario. ¿Verdad? ¿Qué fue eso? June. OK. Volvamos a tener un valor inicial para que el mundo exterior pueda decir, eh, hazme un contador pero usa esto como valor inicial, cambio de comportamiento, cambio de promesas y contrato significa una nueva prueba, ¿verdad? Tomaré esta prueba. Volveré al contador. ¡Eh, las rayas rojas ganan, estoy rompiendo el contrato! Por supuesto que estoy rompiendo el contrato. No hay una propiedad de inicio. Muy bien, y lo guardaremos para que se ejecuten las pruebas. Las pruebas fallan porque 10 no es el valor, pero TypeScript falla porque start no es una propiedad. Así que arreglaremos la definición de tipo y el contador también permitirá, lo escribiré. ¿Quieres comenzar? Muy bien, ahora las rayas rojas desaparecieron. La prueba seguirá fallando porque aún no he implementado el punto de inicio. ¿Cómo quiero implementar el punto de inicio? Aquí las cosas se complican un poco. Solo lectura. No puedo poner esto al principio. Así que voy a usar un método de ciclo de vida, y en este método de ciclo de vida, luego tendré acceso a las propiedades, al valor pasado. Y a partir de eso, puedo obtener un punto de inicio. Así que en componentDidMount, tengo acceso a las propiedades. Así que vendré aquí, agregaré ese método. Se ejecuta una vez. Si se pasó una propiedad, si tengo una propiedad, llamaré a setState esta vez en lugar de hacer la asignación manual. Guardaré, veré si mis pruebas se ejecutan. Y todas mis pruebas se ejecutaron. Asegurémonos de que realmente se ejecutaron, que se ejecutó en toda la pantalla. Muy bien. Punto de inicio. He hecho algo en el punto de inicio, que no funcionó. Pasé start como una propiedad. Si props.start, si props.startState. Me pregunto si esto se debe a que la prueba no tiene acceso al nivel del ciclo de vida. No puede ser. Muy bien.

23. Manejo de clics para incrementar el contador

Short description:

Solucionamos el problema con la prueba que no ejecutaba el ciclo de vida componentDidMount. Ahora necesitamos conectar el componente contador a la interfaz de usuario. Tenemos un componente contador que puede recibir propiedades y estado, es configurable desde el exterior y realiza un seguimiento de los conteos. Discutimos la importancia de ser específico en el contrato de un componente. Pasamos a la siguiente parte, donde manejaremos los clics para incrementar el contador y simularemos clics en las pruebas.

Colocaré una declaración de depuración. ¿Por qué no puse el número de conteo como solo lectura? Entonces, Matt, estaba tratando de modelar todo el estado en lugar de solo el conteo. Podría haberlo hecho, tienes razón, podría haber tenido solo el conteo. La idea es que más adelante podría agregar otras cosas al estado. Pero en realidad tienes un buen punto. Deberías ser lo más específico posible y no tratar de adherirte a un contrato infinito. Muy bien, así que estoy comenzando en cero. this.props.start debería ser cero. Veamos. De acuerdo. Podrías ver mi problema. Muy bien. this.props.start debería evaluar como verdadero. Así que estoy estableciendo el estado, y supongo que esto es solo un caso en mi prueba. En realidad no estoy ejecutando el ciclo de vida componentDidMount. De acuerdo. Nota para mí mismo, lo arreglaré. Tal vez Angela esté a punto de darme la respuesta correcta sobre esto. De acuerdo. Ahora tenemos que hacer el tercer paso. Hablamos de los tres pasos. Escribimos una prueba fallida. Hicimos una implementación. Ahora tenemos que ir al padre y conectarlo a la interfaz de usuario. Así que comenzaré con app.test.tsx. Estoy haciendo las tres cosas en una gran prueba conjunta. Probablemente no sea lo más inteligente que puedo hacer. De acuerdo. Esto se ejecutará. Y en realidad no necesito hacer nada en el código porque estaba incluyendo el subcomponente y estaba mirando dentro del subcomponente. Oh. Creo que es la F de Florian. Adivinaré y diré que sí. Simplemente elegí algo que todavía iba a estar en el documento. Oh, eres tonto. Si hubiera dicho 99, habría fallado. Porque 110 todavía tiene un cero. Estoy cansado. Tal vez eso es en lo que lo culparé. De acuerdo. Así que está arreglado, y tenemos un componente contador que puede recibir propiedades, estado, es configurable desde el exterior. No solo puedes darle la etiqueta, sino también el punto de inicio, y realizará un seguimiento de los conteos. Y tenemos toda esa información envuelta en tipos, que intenta imitar la lectura única. Estoy de acuerdo con no puedo recordar quién lo dijo. Estoy de acuerdo contigo en que en lugar de modelar cualquier cosa posible, debería ser más específico, digamos, cuál es el contrato de este componente. Buen trabajo. ¿Es Florian? ¿Es eso lo que significa la F? ¿O estoy proyectando? Frank. De acuerdo, lo siento. De acuerdo. Karlsruhe, ¿verdad? ¿Recuerdo eso correctamente? Bien. De acuerdo. Adelante. Algo divertido. Y puedes ver que estamos llegando al final de la película y vamos bastante bien de tiempo. Antes de continuar, como nota, las cosas están a punto de ponerse reales. Así que hagamos una pequeña pausa. ¿Alguna pregunta? ¿Algún consejo sobre cómo reescribir este tutorial si lo hago en el futuro? ¿Algo que hayas visto presentado y tengas tus propias ideas al respecto? usehooks.com, oh, eso parece un taller interesante. Voy a hacer clic en ese enlace, Suzanne. Gracias. De acuerdo. Sin puntos. Continuaremos. Tenemos un contador. No realiza un seguimiento de nada. Entonces no tenemos forma de incrementarlo, excepto en una prueba. No lo hemos conectado a ningún manejo de eventos. Agreguemos al componente contador el manejo de clics para incrementar y mostraremos cómo modelarlo en TypeScript y cómo trabajar con esto y simular clics en las pruebas. Este es un divertido. También estaré interesado en ver si algunos de ustedes, profesionales, tienen un conjunto de sugerencias más recientes y mejores. Así que vamos a hacer lo mismo de siempre. Escribiremos pruebas, obtendremos subrayados. Haremos nuestra implementación, etc. Esta vez, sin embargo, en realidad vamos a abrir un navegador al final y hacer algunos clics. Aprovecharé este momento para destacar cuánto hemos avanzado sin realmente mirar un navegador. ¿No es genial? Podemos hacer desarrollo de React sin escribir, escribir, escribir, ir a un navegador, actualizar, hacer clic en el universo, ir a la consola, bloquear algunas cosas, volver a tu editor y escribir, escribir, escribir. Oh, Dios. Me está matando. Escribiremos una primera prueba fallida en el contador. Y esto será un incrementador, un clicker de eventos. Verás, obtendremos otra importación de la biblioteca de pruebas, fire event. Eso se ve sexy. Copiaré y pegaré esto, volveré a counter, ocultaré esto y agregaré una nueva prueba. Necesitaré una importación. Así que, gracias IDE. Haz esa importación por mí. Optimizaré la importación, formatearé el código libremente como el perro de Pavlov. Y lo que está sucediendo aquí es que voy a escribir una prueba para el punto de inicio del contador. Y en este caso, estoy mirando esto. Coincide con este atributo de título, conteo actual. Estoy obteniendo su valor, su contenido de texto.

24. Implementación del Manejo de Eventos en el Componente Contador

Short description:

Quería simular hacer clic en un elemento para pasar de 0 a 1. La prueba falló porque no se implementó el controlador de eventos. Necesitamos un controlador de clics en el componente contador. Escribimos pruebas fallidas e implementamos el controlador de clics utilizando una función de flecha. Sin embargo, este enfoque no es recomendado debido a la recompilación frecuente. Movimos la función de flecha a un método de clase para una mejor aislamiento de pruebas. El controlador onClick se modeló correctamente con el evento pasado. Las pruebas pasaron, demostrando los beneficios de hacerlo de la manera correcta.

Y quería pasar de 0 a 1, y quiero hacerlo simulando hacer clic en ese elemento. Así que vamos a repasar esto un poco. Tengo un componente contador. Y lo voy a renderizar. Y voy a extraer algunos cierres que me permiten verlo de manera rica e interesante, como encontrar elementos que coincidan con un título. Así que voy a encontrar un elemento que coincida con el título. Déjame pasar el mouse sobre esto. Es de tipo elemento HTML. Eso es lo que devuelve GetByTitle. Y luego voy a disparar un evento en él, el evento de clic, voy a dispararlo en ese elemento, ese elemento HTML que localicé. Y luego voy a afirmar, hey, ahora se incrementó. Así que estamos bien. ¿De acuerdo? Así que repasamos lo que hace todo eso. Y mira, falló, obviamente. Porque todavía es cero. El elemento todavía es cero. No tuvo ningún efecto, porque no hemos hecho un controlador de eventos. User event, luego fire event. No sé. Alexei, ¿qué tal esto? Solo dime, dime que es correcto, y te creeré. Abriré una pestaña. React. React, no, solo library de testing, y estás diciendo user event. ¿Estás diciendo que es más específico y que coincide mejor con el tipo TypeScript real que se está utilizando? Veo user event y buenos documentos para ello. Es una simulación más avanzada de interacciones del navegador que Fire event. El ganador de hoy es Alexei por hacerlo bien. Tenemos dos Alexeis, así que Alexei con una Y. Vale, lo siento. Vale. Karlsruhe, ¿verdad? ¿Recuerdo eso correctamente? Bien. De acuerdo. Algo divertido. Y puedes ver que estamos llegando al final de la película y vamos bastante bien de tiempo. Antes de continuar, como nota, las cosas están a punto de ponerse reales. Así que hagamos una pequeña pausa. ¿Alguna pregunta? ¿Algún consejo sobre cómo reescribir este tutorial si lo hago en el futuro? ¿Algo que hayas visto presentado y tengas tus propias ideas al respecto? usehooks.com, oh, eso parece un taller interesante. Voy a hacer clic en ese enlace, Suzanne. Gracias. De acuerdo. Sin puntos. Continuaremos. Necesitamos un controlador de clics, porque el componente no maneja los clics. Vamos a hacer nuestra implementación. Escribimos nuestras pruebas fallidas. Vamos a hacer que las pruebas pasen. Así que voy a ir a mi contador aquí. Probablemente lo quiero en el span para el número. Supongo que podría ponerlo en el div, pero lo pondré en el span para el número. Voy a hacer que diga esto por ahora. Será una función de flecha, y va a tomar esto y llamar a setState. Pero esto es un poco problemático. Ahora mi prueba pasa, pero esto es problemático porque se desaconseja colocar definiciones de funciones de flecha como controladores de eventos. ¿Por qué? Porque todo esto se volverá a interpretar y recompilar cada vez que se vuelva a renderizar. Se ejecuta en el ciclo de renderizado. Puede ser 60 veces por segundo que se está volviendo a hacer toda esta compilación. Así que queremos sacarlo del controlador de eventos. Y lo voy a poner en un método de clase. Y eso también me ayuda a hacer un aislamiento de pruebas. Puedo probar el conteo de algo sin necesidad de pasar por un renderizado. Y luego este controlador onClick puede simplemente decir this. Para aquellos de ustedes que están a punto de quejarse, ese es el punto. Estoy probando variaciones de esto para llegar a lo correcto. Y obviamente, puedo hacer autocompletado. Bien, cuando guardo eso, obtengo mis pruebas pasadas. Y lo que quiero señalar es que creo que en realidad dije método. Esto no es realmente un método. Si fuera un método, tendríamos el problema de this. Esto es en realidad un campo, o propiedad, o atributo, o como quieras llamarlo, que es una función de flecha, que luego obtiene la vinculación correcta de this para que no esté vinculado a un evento como this. El componente es this. Pero aún así se pasa el evento. Aunque no lo estamos usando, y será el this no es el evento, sino el componente. Sin embargo, estamos pasando un evento. Así que modelémoslo correctamente. Y luego se enojará porque dice que es any. Y así, está bien, te callaré, compilador de TypeScript. Ahora estás feliz, ¿verdad? Bueno, todavía obtenemos algunas advertencias sobre un evento no utilizado, lo veremos en un segundo. Pero si mi tsconfig.json desactiva la capacidad de tener any, obtendré algunas quejas. Estoy haciendo trampa diciendo any. Simplemente estoy callando al compilador. Hagámoslo de la manera correcta. Y demostremos que hacerlo de la manera correcta tiene sus beneficios. Esa información de tipo puede mostrarnos problemas. Vale, y voy a volver aquí, tengo, sí, Discord abierto. Bien. Mi primer intento dirá que es un evento de mouse. Y un evento de mouse es un genérico para el tipo de cosa en la que se hizo clic. Así que voy a decir eso. Bien, bien. Y luego voy a comenzar el proceso de usar esta información diciendo a lo que eventualmente queremos llegar es ¿presionaste Shift + Clic? Si es así, vamos a incrementar en 10. Y por eso queremos tener acceso al evento, queremos manejar el uso de Shift + Clic. Así que voy a venir. Voy a comenzar el proceso de cometer algunos errores. ¿De acuerdo? Así que este es mi primer intento. Y guardaré. Veamos qué sucede con las pruebas en ejecución. Las pruebas fallaron porque no tiene la respuesta correcta. Algo salió mal. ¿Qué salió mal? Hmm. Por cierto, el final de la historia es que siempre llego al muro de la ternaria. ¿Puede la escritura ayudarme a ver cuándo me equivoqué en la ternaria? Vale, no puedo hacer una suma en un número o número en booleano. Así que esto puede ser un booleano o un número. ¿Por qué es eso? Estoy diciendo uno y estoy diciendo 10 aquí.

25. Refactorización y Manejo de Pruebas de Clic con Shift

Short description:

Establecimos el tipo explícitamente para eliminar la línea ondulada. Nos dimos cuenta de que el orden de la ternaria estaba equivocado y lo corregimos. TypeScript nos ayudó en el proceso al proporcionar autocompletado e información de tipo. Las pruebas pasaron y ahora tenemos un contador que se puede incrementar con Shift + Clic. Necesitamos manejar la prueba para el clic con Shift. Discutimos el uso de user event y fire event en la biblioteca de pruebas. Decidimos usar fire event como la mejor opción. Importamos manualmente y nos enfocamos en la tarea en cuestión.

Es un número. No puede ser un booleano. Así que pasaré al siguiente intento. TypeScript nos indicó el problema. Establezcamos el tipo explícitamente y digamos: ja, sé más que tú. Te callaré y diré que eres un número. Bueno, esa línea ondulada roja desapareció. Pero ese no era nuestro objetivo. Nuestro objetivo no era mover la línea ondulada. Nuestro objetivo era eliminarla. ¿De qué te quejas ahora? Lo mismo, piensa que el lado derecho del igual puede ser un número o un booleano. Sigamos analizando esto un poco más. Y finalmente nos damos cuenta de que tengo el orden de la ternaria equivocado. Es si esto, entonces eso, de lo contrario eso. Y TypeScript me ayudó en todo momento porque decidí dar el paso extra y poner información de evento, información de tipo, en el evento. Pudo ayudarme con el autocompletado. Pudo decirme que eso se evalúa como un booleano, todas esas cosas. Y June tiene razón. La línea ondulada continúa, ¿verdad? El error tipográfico, Shift key es Boolean. Solo dice, ves donde dice Boolean al final aquí. Solo dice si se presionó Shift o no. Para este evento, ¿se presionó Shift? Alexei, ¿eso responde a tu pregunta? Muy bien, genial. Con eso en mente, guardaré y veré qué sucede. Mis pruebas pasan. Muy bien, tengo un contador que se puede incrementar con Shift + Clic. ¡Yay! ¿Ves algún Shift en mi prueba? No, así que necesitamos manejar la prueba para eso. Avanzado en 10 fue un clic con Shift. La biblioteca de pruebas tiene algún evento de disparo. Me pregunto si esto sigue siendo cierto. ¿Está incluido user event? Quien sea que me haya hablado de user event. Oh, Alexei. ¿Está incluido, o todavía tengo que hacer esto? Voy a suponer que todavía tengo que hacer esto. Solo pensé que quería user event para casos en los que no podía usar fire event. Parece que fire event es lo mejor para hacer en todo momento. Oh, mira. Sí, yarn. Debería haber escrito yarn en ese momento. De acuerdo, mientras se ejecuta, escribiré la importación manualmente en esto para que podamos enfocarnos un poco mientras lo hacemos.

26. Pruebas de Incremento del Contador y Simulación de Eventos

Short description:

Clonamos la última prueba y simulamos mantener presionada la tecla Shift mientras hacemos clic en el contador para aumentarlo en 10. Cambiamos de FireEvent a UserEvent para una interacción más rica. La prueba pasa porque la implementación ya está en el controlador de eventos. Discutimos la opción de probar el incremento del contador a través de la representación o llamando a la función y verificando el estado. La última opción se asemeja a las pruebas normales de JavaScript y proporciona fallos más rápidos y razonables.

De acuerdo, y voy a escribir una nueva prueba que básicamente clona la última prueba. Y luego la analizaremos. Y queremos aumentar el contador en 10 fingiendo que mantenemos presionada la tecla Shift cuando hacemos clic en el contador. ¿Cómo vamos a hacer eso? Aquí arriba, usamos FireEvent. Esta vez, vamos a usar UserEvent. De acuerdo, me gusta, veo tu punto. Sí, todo forma parte del mismo espacio de nombres del paquete, pero está desagregado. Sin embargo, esta vez, cuando hacemos clic, vamos a seleccionar un objetivo al igual que seleccionamos un objetivo. Pero vamos a pasar información de modificador. Las otras partes del objeto de evento que queremos simular, en este caso, el valor verdadero de shift. Esto es algo así como hacer shift es falso aquí arriba. Y lo que queremos demostrar es que al hacer esto, pasamos de 0 a 10. Y aquí explico que cambiamos de FireEvent a UserEvent para obtener una interacción más rica. Y cuando lo hicimos, mira eso, nuestra prueba ya pasó porque ya hicimos esta implementación en nuestro controlador de eventos. Me gustaría señalar que estoy probando el incremento del contador a través de la representación. Podría venir aquí y escribir una prueba que llame a incrementar contador y luego mire el estado para ver si se incrementó. Y podría simular un objeto de evento que pasé. Y se sentiría muy similar a las pruebas normales de JavaScript, no a las pruebas de componentes renderizados en el DOM. Y esas pruebas, son más rápidas y fallan de una manera más razonable.

27. Refactorización del Componente Contador y Pruebas

Short description:

En este paso, refactorizamos el componente contador para eliminar su estado y lógica de manejo de eventos. El componente padre se encargará de estas responsabilidades y las pasará como props al contador. También discutimos la estrategia de pruebas y modelado en TypeScript. Se modifican las pruebas para adaptarse a los cambios y se resuelven los problemas de TypeScript. Ahora estamos listos para continuar con el último paso.

De acuerdo, ese es un punto interesante sobre extraer en hooks personalizados y facilitar las pruebas. Algunas de las cosas que estamos haciendo en esta masterclass hacen un poco más de trabajo ahora para darte un nivel de granularidad que sea fácil de probar solo esa cosa, fácil de modificar y refactorizar en el futuro. Y eso es un buen ejemplo, Andre, de hacer un poco más de trabajo ahora para crear un hook personalizado. Porque luego puedo probar esa maldita cosa y está empaquetada con un conjunto de decisiones y el mundo exterior no tiene que saber nada al respecto. Por lo general, hacemos eso para componentes con componentes secundarios. Es interesante hacerlo también con el estado para que las partes pequeñas de tu estado global se puedan tratar de manera lógicamente diferente.

De acuerdo, estamos llegando al final, el último paso en el tutorial. Antes de continuar, haré una pausa por un momento y veré si tenemos alguna pregunta o comentario. De acuerdo, continuaremos. Lo que vamos a hacer en este paso es refactorizar esto para que sea la forma en que se supone que debes hacerlo para componentes de presentación, componentes secundarios o componentes de contenedor y componentes DOM. Y lo que queremos es que el contador se vuelva mucho más simple. No debería realizar un seguimiento de su estado y realmente no debería tener la lógica sobre qué hacer en el evento. Eso debería hacerlo el componente padre y pasarlo y ponerlo a disposición del hijo. Lo que queremos hacer es ver una estrategia de pruebas para esto a medida que avanzamos en las iteraciones de refactorización, y también queremos ver cómo modelar esto en información de TypeScript.

De acuerdo, comenzaremos con el estado del contador. Vamos a eliminar el estado del componente contador, y si vamos a eliminar el estado del componente contador, probablemente queramos convertirlo en un componente funcional. Así que comencemos haciendo que esto sea las props donde elimino el contador ya que pasar un punto de inicio ya no importará ya que no realiza un seguimiento del contador. Así que vendré a mi contador y aquí, eliminaré el inicio. Y luego voy a cambiar el componente contador en sí para que sea un componente funcional. Voy a dejar esta parte sobre el estado inicial por ahora porque tendré que ponerlo en otro lugar más tarde y debería tenerlo aquí para poder razonar al respecto. Y veamos. Oh, no. Necesito agregar contador. Así es. Mira, tengo subrayado en rojo. Contador ahora es una prop, que está siendo gestionada por mi componente padre y se me pasa. Y a medida que cambia en el padre, se me vuelve a pasar como una prop y se vuelve a renderizar y todas esas cosas. De acuerdo, Jun, estoy interesado en tu opinión al respecto. Pero sabes, SFC significa Stateless Functional Component. Y mi impresión fue que al principio, los componentes funcionales se introdujeron para modelar componentes que no tenían estado. Y al principio, se te animaba a usar solo componentes basados en clases cuando tenías estado local. Me pregunto si la gente está en desacuerdo conmigo al respecto. Ahora, nuestro contador es un componente de presentación DOM sin estado, y podemos eliminar la importación de component o usar el IDE para limpiar en IOWN 5 y deshacerme de él por mí. De hecho, en estos días creo que podemos deshacernos de eso, pero lo dejaré porque fue generado por create React app. Arreglemos las dos pruebas, las dos primeras pruebas y el contador para ver si estamos en el camino correcto y si podemos pasar un punto de inicio. Así que simplemente cortaré y pegaré estas. Mi prueba se volverá un poco desordenada a medida que haga la refactorización en esto porque estoy cambiando el contrato radicalmente. ¿Pasamos estas dos pruebas? Realmente no me preocuparé por las otras dos. De acuerdo, estas dos pruebas pasan. Así que estoy en buena forma. Estoy en el camino correcto. El componente contador ya no controla el valor de inicio, así que podemos eliminar estas dos pruebas, sobre comenzar en este lugar, comenzar en otro lugar. Así que digamos que eso pasa. Debería comenzar en otro valor y debería comenzar en 0, eliminaremos esas dos pruebas. Nos gustaría mantener estas pruebas sobre la generación de eventos. Ahora, en lugar de que el contador maneje la lógica de hacer clic, queremos que el padre maneje la lógica de hacer clic. Así que voy a poner esta mala cosa en la definición de props y luego la explicaré. Podría ser más fácil aquí. Ahora estoy pasando una función que espera un primer argumento, o debería ser algo como incrementar contador, ¿verdad? Pasar un primer argumento que es un evento de ratón en un elemento HTML. Y no va a devolver nada porque no necesita devolver nada, simplemente va a operar en el estado. Lo que vemos es que tenemos la etiqueta que llegó como una prop. Tenemos el contador actual que llega como una prop. Y tenemos un controlador de clic, que llega como una prop. Los tres, junto con su información de tipo, se expresan en esta definición de tipo. Es interesante pensar si la `hookificación` ha hecho que la gente repiense la presentación en el tipo de componente DOM padre-hijo. Aún no he visto ese meme, pero no he ido a un bootcamp recientemente. Y ha pasado un tiempo desde que escribí esto. Creo que este tutorial es anterior a los hooks. Sin embargo, nuestras pruebas, tenemos problemas de compilación en nuestras pruebas porque tenemos un contrato roto.

28. Manejo de Clics para Incrementar el Contador

Short description:

Hemos solucionado el problema con la prueba que no ejecutaba el ciclo de vida del componenteMount. Ahora necesitamos conectar el componente contador a la interfaz de usuario. Tenemos un componente contador que puede recibir props y estado, es configurable desde el exterior y realiza un seguimiento de los conteos. Discutimos la importancia de ser específico en el contrato de un componente. Pasamos a la siguiente parte, donde manejaremos los clics para incrementar el contador y simularemos clics en las pruebas.

Se requiere el conteo y el incremento del contador. Entonces, lo que necesito es, déjame ver. Las primeras dos pruebas pasan y las otras dos fallan. Vamos a arreglar estas dos pruebas porque en realidad no estamos probando el manejo de clics en este momento. No nos importa el clic. Solo necesita haber algo allí. Vamos a crear un controlador de clic falso. Y lo pasaremos, junto con un conteo inicial, como las dos props que actualmente se están maximizando. Eso es lo que nos falta actualmente. Ahora TypeScript está contento con eso. Veamos. Voy a copiar y pegar todo el código. Creo que tengo algo extraño debido a... Oh, no. Lo siento. Se supone que debo arreglar el anterior. Sí, estas son las pruebas que pasan, pero TypeScript está enojado. Así que volveré a hacer esto. TypeScript está enojado porque estoy pasando un contador pero no estoy pasando un controlador. Hagamos una simulación. Y luego puedo usar eso como el controlador y ahora TypeScript está contento con eso. Haré lo mismo aquí. Y así las pruebas se ejecutarán. Estas dos pruebas pasan nuevamente y no tienen problemas de TypeScript. Permíteme ver qué está diciendo Alexey sobre que hace que sea difícil. Alexey, cuando dices definitivamente hace que sea más difícil probar los componentes React, ¿a qué te refieres con más difícil? ¿Los hooks, la nueva forma o la antigua forma de presentación? De acuerdo, entendido. Bien, estamos en buena forma con esas dos pruebas y nos quedan unos cinco minutos. Así que lo que haré en el resto de esto, en lugar de escribirlo, simplemente lo explicaré y luego concluiremos. El manejo de eventos es un poco más complicado porque, por supuesto, el componente hijo de presentación no va a hacer el trabajo. Pero al menos queremos ver si la función fue llamada y si se llamó correctamente. Entonces, lo que vamos a hacer en este caso es cambiar la tercera prueba. Vamos a eliminar la última prueba. Vamos a crear un controlador. Lo vamos a pasar. Vamos a hacer el clic. Y luego, en esta cosa del controlador, vamos a hacer una afirmación para asegurarnos de que se haya llamado, si mi componente llamó a la función cuando se hizo clic. Un concepto bastante inteligente y fácil del contrato. Pero, ¿cómo escribo una prueba para esto? Creo una simulación. Uso esa simulación o espía como la cosa que se pasa al componente DOM. Hago todo el trabajo y luego lo miro y digo, oye, espía, ¿te llamaron correctamente? Eso es realmente fácil. Y cuando se combina con fire event y user event y cosas así, es realmente agradable. Quiero decir, ¿cómo lo harías de otra manera? Vas al navegador. Haces clic en el universo, ves si todo funcionó correctamente. Podemos hacer que el componente DOM sea un poco más inteligente porque su interfaz entre el padre y el hijo está expresando algunas cosas. Eso se podría mover un poco al hijo. Lo que tenemos ahora es que la función de incremento del contador pasa todo el evento. Pero sabemos que al hijo no le importa todo el evento. Solo le interesa el clic con shift. Así que vamos a decir, oye, llámame con un argumento sobre si se presionó shift. Ese es el primer cambio. Y luego, en la implementación, vamos a hacer una llamada que luego hace el incremento del contador con el valor de la tecla shift, y eso será el controlador utilizado por el hijo. Porque el padre tiene acceso a todo el evento. No vamos a hacer que el hijo tenga acceso a todo el evento. Lo siento, estoy en el hijo. Lo siento, tengo esta función handle click que está haciendo eso. Luego podemos volver al componente contenedor, lo siento, la prueba ahora está escrita para poder ver solo esa cosa sobre false. Porque eso es lo que tenía el controlador. Y solo para concluir un poco esto, podemos ir al componente padre. Dije que dejaríamos estas líneas en el contador. Eso es para que podamos copiar y pegarlas en el padre donde está el contrato. Veamos. Creo que sí, necesito cambiar eso. Ya no es un componente de clase. Luego, en el padre, vamos a hacer una función de incremento que se pasa, y aquí es donde obtenemos todo. Me refiero a que esta es la función que llama el hijo, y se pasa de vuelta. La información de shift, que luego usamos. No tenemos que analizar un evento. Pasando por todo esto, podemos escribir pruebas que hagan todo para el estado de la aplicación, que incluye algunos clics en el componente contador. Ahora, comenzaré el proceso de concluir, recibiré cualquier comentario y cosas así. Me gustaría señalar algo. Lo dije un par de veces, pero me gustaría terminar con eso. Casi nunca miramos la aplicación en el navegador, pudimos hacer todo este trabajo, ya sea renderizando, ya sea props, ya sea estado, ya sea controladores de eventos, todas estas cosas pudimos hacerlas, permaneciendo en nuestras herramientas, permaneciendo en el flujo, pudiendo depurar, obtener buenos datos de traza, capacidad de hacer clic, refactorizar todas estas cosas y esa capacidad de permanecer en el flujo y trabajar metódicamente y no sentirse abrumado. Esa es una sensación realmente buena para el desarrollo. Estás trabajando con confianza. Sabes que debido a las pruebas, sabes que todo funciona correctamente, pero debido a las pruebas, también puedes centrarte en el problema. Así que me detendré aquí por un momento. Sigamos adelante y concluyamos cualquier aporte, cualquier pregunta, cualquier comentario, cualquier observación sobre tus sentimientos acerca de las pruebas, tal vez incluso sobre TypeScript también. Echaré un vistazo a algunos de los comentarios en el chat. Tendré que estar atento al impacto de los hooks en la forma en que las personas dividen los componentes y sobre cómo escribir pruebas y cosas así. Entonces, June, gracias por mencionarlo. Alexei, el TypeScript en los últimos dos años. Tienes razón, sigo la hoja de ruta de TypeScript.

29. Gestión de Proyectos e Integración de IDE

Short description:

Hacen un gran trabajo ejecutando el proyecto y manteniendo el roadmap actualizado. Ahora están interesados en la teoría de tipos y tratando de mover partes importantes. También se menciona TypeScript. Las licencias de WebSR e IntelliJ son separadas, pero hay un paquete de todos los productos para acceder a todos los IDEs. Se aprecia la calma y disciplina de permanecer en el IDE durante el desarrollo. Se reconoce el comentario de Dylan y el orador expresa interés en aprender de él. Se menciona el punto de June, pero el orador no está seguro de su importancia.

Hacen un gran trabajo ejecutando ese proyecto y hacen un gran trabajo manteniendo su roadmap actualizado. A veces tienen un punto sobre, ya sabes, lo que está por venir o lo que acaban de implementar. Están usando palabras que no entiendo porque ahora están realmente interesados en la teoría de tipos. Están tratando de mover partes importantes. El desarrollo de un framework puede ser expresado en información de tipos. TypeScript es genial. Desafortunadamente, la licencia de WebSR y la licencia de IntelliJ son separadas, pero tenemos algo llamado el paquete de todos los productos, que te permite acceder a todos nuestros IDEs.

Y Alexa, tu punto sobre no abandonar el IDE. ¿Sientes que esta es una forma de desarrollo que te gustaría? Cuando tengo la disciplina para permanecer en este modo, es tan tranquilo. No me siento frenético. Tal vez esa no sea la forma correcta de decirlo.

Sí, bueno, gracias Dylan. Aprecio eso. Tal vez algún día vea una presentación tuya y aprenda algo de ti. De acuerdo. Creo que estos son la mayoría de los comentarios. June, lo que estás diciendo realmente es, lo que me atrajo a esto es... No sé. Tal vez sea solo yo.

Watch more workshops on 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
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
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions

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 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 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.
JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.