React, TypeScript y TDD

La workshop de hoy va a ser yo tratando de convencerte sobre una idea. Y esa idea es sobre desarrollar tus React components primero en pruebas. Escribir una prueba antes de que escribas el code. Escribir una prueba como la forma de continuar desarrollando el code y el componente. Y solo al final, cuando necesitas ver cómo se ve realmente, vas a un navegador.

Este tutorial tiene asociado algo 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 el resumen de lo que voy a hablar, tiene el code 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 discord, pero tienes razón. Debería haberlo pasado a alguien más lo hizo bien. Bien, me atrapaste, gracias por hacer eso. Cada cosa que tengo es como hacer trampa y ponerla aquí, pero hay una razón para esto, quiero que puedas seguirlo y jugar con él y no preocuparte por cada cosa. Digo si hay algo que no entendiste, hay algo que quieres seguir. Puedo ser fácilmente reemplazado por una URL a un sitio web. Y también debería saber que cada paso en el tutorial tiene un enlace al code funcional para ese segmento del tutorial.

Entonces, lo que vamos a hacer es que vamos a pasar por esto. Hacer el caso para esta forma de hacer desarrollo. A medida que avanzo construyendo code de trabajo. Intentaremos hacer una parada tal vez como una hora y media a partir de ahora o algo así. Tomar un descanso de cinco minutos. Así que tengo mi temporizador configurado para eso. También estaremos hablando en el chat. Intentaré obtener tanto el canal de Discord como el chat de Zoom un poco más grande, para no cometer un error en él.

Muy bien, discúlpame por un segundo. Disculpas, me pregunto si mi micrófono recogió ese estornudo. Tomaremos un pequeño descanso, seguiremos todas estas cosas. Y si te quedas atascado, está bien, porque el enlace al code de trabajo para 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 nuestros IDEs. Entonces, en JetBrains, para esto, significaría WebStorm, o cualquiera de los otros IDEs que incluyen el complemento WebStorm. No voy a promocionar realmente WebStorm en esto. Será, utilizo la palabra IDE, porque entonces se aplicará a otros editores inteligentes que pueden mirar la estructura en lugar de solo las cadenas de texto. Pero al mismo tiempo, a medida que hago este tutorial, me emociono mucho acerca de cómo la tooling puede ayudarnos, la tooling de testing y la tooling de escritura puede hacernos tener una mejor experiencia de desarrollo y permanecer en el flujo.

Entonces, con eso en mente, comencemos. Esta es la secuencia que vamos a hacer configuración y limpieza y luego saltar directamente a testing. Haremos un poco de debugging para mostrar el beneficio de sentarse en un IDE, y luego directamente a varias cosas sobre la escritura de componentes React. Esto está actualizado a partir de la creación de la aplicación React la semana pasada, por lo que actualicé todo el code 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 trabajar en ello. No sé cuánto avanzaremos en todo esto hoy, pero, de nuevo, soy fácilmente reemplazable, por lo que si no llegamos al final, puedes ver el video en tu propio tiempo y ver estas últimas cosas. 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 voy a conseguirnos una aplicación de muestra, y vamos a mostrar tres tipos de ejecución de cosas en el code. Vamos a mostrar la configuración de desarrollo, la configuración de construcción de su sitio final y la configuración de prueba. Y en el camino, vamos a empezar a introducir un poco de cosas sobre el IDE. Entonces, con eso en mente, si quieres seguir en esta página, está bien. También lo tengo en segundo plano para poder hacer trampa. Voy a ir a mi IDE, voy a empezar en la pantalla de bienvenida a WebStorm. Voy a crear un nuevo proyecto. Ahora, podría, si no estás usando WebStorm, está bien, puedes escribir esto. Entonces, voy a crear un nuevo proyecto, va a ser un proyecto react. Lo voy a llamar Create React App y me va a indicar algunas de las cosas que va a utilizar por defecto. Déjame asegurarme de que lo tengo. Tengo que desplazarme hacia arriba. Estamos bien. Ahí. Estamos bien aquí. Estoy usando hug. Creo que node 16. Sí. 16.10 Gracias, WebStorm por responder esa pregunta por mí. Va a estar usando NPX para obtener create React app. Así que veamos si tienes idea inteligente definitiva, entonces tienes acceso al plugin Node JS. Y si has instalado Node JS, tienes acceso a todo esto. Muy bien. Un pequeño descargo de responsabilidad sobre esto, voy a explicar como si algunas cosas para algunos de ustedes podrían ser nuevas. Pero también me doy cuenta de que algunos de ustedes sí saben lo que es NPX. No me detendré en ello porque está muy bien explicado en otro lugar. 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 como una aplicación, algo que vas a ejecutar, que luego creará un paquete. Hay esta cosa llamada NPX que dice, Bueno, ve a buscar la última versión de esto ponlo en un entorno temporal y ejecútalo. Así que ves muchas de estas herramientas de línea de comandos como aprendices y formateadores y andamios como este. Create React app usando NPM para que siempre estés obteniendo 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 cuatro punto oh punto tres. Y finalmente, quiero hacer un proyecto Typescript porque la escritura es una parte importante de esto.

Bueno, con eso en mente. un poco fuera del final. Debería haber. Voy a volver y hacer uno nuevo. Lo hice bien, voy a ir y borrar ese bolígrafo de rasguño. Muy bien. Vale, y luego volveré. Mis disculpas debería haber borrado eso. Así que nuevo proyecto, react lo voy a llamar CRA, y voy a pedir soporte para TypeScript, decir crear nuevo proyecto y WebStorm está poniendo en mi monitor externo. Así que déjame redimensionar esto aquí. Y entonces. Entonces. Entonces lo que hizo WebStorm fue que creó un nuevo proyecto entre comillas en ese directorio y ejecutó algunas cosas que sabe cómo ejecutar, como crear react out, que está creando todo el software y luego instalando todas las dependencias. Así que eso es 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 un largo post en el blog sobre MDX y next JS que publicamos recientemente. Muy bien, así que esto está yendo y obteniendo, déjame hablar sobre create react app. Para aquellos de ustedes que no lo conocen, es un andamio para generar la mejor colección de software soportado para una moderna aplicación react. Lo que eso significa es paquetes adicionales que podrías querer usar y tooling que podrías querer usar como prestamistas y cosas así. Va a ser más de mil, tal vez 1,500 paquetes que instala. Y esto es simplemente locura. Es tan difícil mantener todas estas cosas en tu cabeza. Y luego a medida que cambia como cada día, esto romperá eso create react app nos está haciendo un gran favor al tomar la propiedad de qué software deberías usar. ¿Y qué versiones de qué software deberías usar? Y ellos dirán que apoyaremos todo eso. Así que esto es algo realmente importante que hacer para create react app. Y por eso lo estoy usando como punto de partida.

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

Vale, gracias por publicar los enlaces sobre la entrada del calendario y cómo entrar 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 añade algunas cosas relacionadas con el enrutamiento y otras cosas que lo hacen más opinado. Así que ejecutamos NPM start, y está ejecutando un webpack Dev Server. Está haciendo todas las cosas en una ventana, y puedo demostrar que está haciendo lo que quiero que haga yendo a app.tsx, que está en SRC. Y si cambio algo como aquí para ser exclamación, verás que va a recargar, se va a actualizar, y cuando vuelva a Chrome, veré esto en vivo. Y si tuviera suficiente espacio en mi pantalla, cambiaría a 720p, si tuviera suficiente espacio en mi pantalla, podrías ver que estas cosas están sucediendo una al lado de la otra. Ahora, eso está muy bien, pero no tienes que ejecutar en una terminal. Somos un IDE. Los IDEs tienen algo de automatización para integrar tu entorno de desarrollo, así que si quisiera integrar mi entorno de desarrollo, podría hacer un par de cosas. Podría ejecutar - por cierto, tengo las pestañas desactivadas. Las volveré a activar para que se vea un poco más familiar para ti. Si quisieras, sin embargo, podrías ejecutar nuestra herramienta npm y obtener una lista navegable de cosas para ejecutar. Y luego lo ejecutará en una ventana de herramientas para el ID. Chris, estamos en la configuración del proyecto, que es el primer enlace, bajo show me a page. Entonces, 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 dejo mi package.json por ahí, y tenemos estas decoraciones de canalón que me permiten ejecutar scripts, no sólo ejecutarlos, también puedo ejecutarlos bajo el depurador, lo cual es también útil. Así que, simplemente voy a ejecutar esto aquí, y lo que obtengo en lugar de la ventana de la terminal es 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, la misma clase de cosa. Verás que estamos ejecutando la misma cosa debajo. Si vuelvo a WebStorm y luego voy a mi componente, y minimizaré esto, y quitaré esto y pondré el punto de nuevo y lo guardaré, hace la recarga en vivo. Así que, debajo del capó, sigue siendo el equivalente moral de npm start. Así que eso nos lleva a través de la creación del proyecto, show me a page, estamos ejecutando el script para start. Eso no es lo único que podemos hacer, sin embargo. Lo que estamos ejecutando es un servidor de desarrollo. No es la calidad de construcción de producción. No está minimizando todo y dividiéndolo en rutas de carga perezosa, y todos los milagros de la ciencia moderna que el moderno React te da. Lo que queremos ejecutar es el script de construcción. Y de nuevo, esto es algo realmente agradable que Create React App ha hecho por nosotros. Tienen un script que ellos manejan en su propio paquete, y cuando encuentran un error, lo arreglan, y yo no tengo que volver a escribir algo de mi lado. Está gestionado por el paquete. Así que si quiero ejecutar la construcción de producción, lo mismo de siempre. Vengo al canalón, hago clic en ejecutar, va a abrir una ventana de herramientas. Va a tomar un tiempo, y el ventilador de mi CPU se va a encender un poco. Para la herramienta NPM si no puedes encontrarla, espero que puedas hacer find action para llegar a ella. O si haces find files, espero que esté listado aquí. Si no, es posible que no tengas el plugin activado. Gracias, Sherry. Creo que respondí a la pregunta que se hizo. Si estoy mirando una pregunta diferente, avísame. Parece que Sherry también respondió a la pregunta allí. Si eso no responde a la pregunta sobre dónde encontrarlo en IntelliJ, avísame. Vale. Así que generamos un directorio de construcción. ¿Qué significa eso? Generamos 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 alta performance. El mínimo JavaScript, todas esas otras cosas. Y si miro aquí, veré que tengo un index.html, tengo algunas variaciones de mi logo, otras cosas que coinciden con lo que estaba obteniendo en un servidor de desarrollo. Una cosa que es interesante acerca de esto es que el IDE lo ha marcado como excluido, lo cual es bueno. No quiero que esté reindexando eso constantemente y dándome dos opciones para navegar a un símbolo o algo así. Bueno, eso está haciendo construcciones. Pasemos a lo que queremos hablar, que es testing. Otra cosa que el create React app hace por nosotros es un andamio.

Vale, muy bien. Así que estoy mostrando en WebStorm, pero si vas a Find Files, espero que lo tengas aquí. Si no lo tienes aquí, entonces es posible que no esté instalado correctamente. Vale, cerraré esta ventana de herramientas de construcción. Y estamos hablando de testing. Y entonces lo que queremos ejecutar es este script de ejecución para test. ¿Ahora qué está haciendo realmente? De nuevo, create React App es como el andamio oficial para el proyecto React. Y ha tomado algunas decisiones sobre testing. Ha tomado la decisión de que Jest es el corredor de pruebas oficial.

Veamos si lo tengo. Sí, Jest es el corredor de pruebas oficial, y la biblioteca de testing que se utiliza para una búsqueda y prueba de automation y cosas así se llama testing library. Y se aseguran de que esta versión de Jest y esta versión de testing library funciona con esta versión de React. Esto es importante porque esas cosas se rompen todo el tiempo. Especialmente cuando introduces TypeScript en la ecuación. Así que es muy útil que alguien más esté haciendo ese trabajo por nosotros.

¿Cómo puedo ejecutar mi prueba ahora mismo? Veamos. Así que voy a 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 hacer la cosa del package.json. Así que voy a ejecutarlo desde aquí. Va a abrir otra ventana de herramientas de ejecución. Y va a lanzar mi observador de pruebas, que está ejecutando mis pruebas constantemente en cada cambio para ver si algo está roto. Breve, voy a romper algo. Y lo haré. Veamos, En Test. Quiere algo llamado Learn React. Y entonces veamos. Learn. Sí. Si guardo eso, las pruebas se vuelven a ejecutar. Y dice que fallé una prueba. Lo devuelvo, lo guardo. En este caso, no volvió a ejecutar la prueba porque está en un modo en el que solo OK. Así que esas son nuestras formas de empezar con los scripts de ejecución de npm en el IDE y empezar con create React app y testing. Así que lo que vimos es que hay muchas herramientas involucradas. Y create React está haciendo un gran trabajo ayudándonos a mantenernos al día y gestionando todas esas herramientas.

En el siguiente paso, vamos a limpiar algunas de las cosas que estaban en nuestro sistema que obtuvimos de fábrica que no necesitamos y echar un vistazo un poco más a TypeScript. OK. Veamos. Bien. Creo que estoy al día. Vamos al siguiente paso en el tutorial. Vamos a ir al paso de limpieza del proyecto. Aprovecharé este pequeño momento para tomar 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. Y fue una gran primera semana. Y han sido unas 200 semanas realmente difíciles desde entonces. Bien, ¿alguien tiene alguna otra pregunta o comentario sobre Create React App, o el mundo de React o los IDEs y las herramientas? OK. Comenzaremos. Vamos a limpiar un poco nuestro proyecto, eliminar algunas cosas que no estamos usando, y en el camino, 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. Expresión extraña destinada a ser extraña. Y el punto es, si va a haber un error más tarde, muéstramelo ahora. Muéstramelo justo en mi cara visualmente para que sepa que he cometido un error. Y así, a medida que avanzamos, hablaré un poco sobre Fail Faster. En esta muestra, en este paso, vamos a ver cómo reformatear nuestro código, finalmente 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, que no vamos a usar.

Sí, Alexis Gatsby. Esa cara sonriente, Alexis, ¿es una cara sonriente de amor o de dolor? Si alguien aquí es un amante o usuario de Gatsby, me disculpo si he hablado mal. Comparte tus pensamientos sobre Gatsby en el canal, y déjame ver lo que piensas.

Así que vamos a hacer una limpieza de algunos archivos y ver cómo el IDE puede decirnos, oye, estás a punto de cometer un error. Falla más rápido. Vamos a ver un poco sobre las bondades del IDE, cómo puede advertirte sobre ciertos problemas. Puede hacer limpiezas por ti, y un poco de refactorización. Así que comencemos, voy a empezar reformateando mi code, y lo voy a hacer primero en, dejaré Package.JSON abierto. Voy a empezar aquí, y en el IDE, en Mac OS, es Command Alt L. Verás que tengo esta herramienta llamada, un plugin llamado, Presentation Assistant instalado. Es para todos nuestros IDEs, y aparece qué tecla fue presionada, qué acción fue invocada, así que lo haré de nuevo. Eso te dice la combinación de teclas que puedes usar en tu lado. El tutorial también tiene la combinación de teclas listada también en el texto.

Sí, Alexei, buen punto. Puede usar Yarn como un 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 enumera algunas de las que mencionaste. Los tipos justos están listados aquí. Me pregunto si no está en mi texto. ¿Es eso, si el problema es que no está en mi texto, entonces necesito actualizarlo. Pero pensé que había copiado y pegado todo eso correctamente. Si no, me disculpo.

OK, volvamos al formateo de code. Estoy en mi componente. He hecho un reformato, y eso es genial. Pero eso no es lo que la gente realmente está usando estos días. Hoy en día 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 code, miro bajo JavaScript, veo que tengo todas estas perillas que puedo golpear para ajustar lo que sucede cuando hago reformato de code. 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 vamos a instalar Prettier. Estamos haciendo Prettier. Voy a ejecutar este a mano. Lo que podría hacer es ir aquí. Oh, veo tu punto. Esperabas que estos estuvieran bajo Dev Dependencies. Eso es un buen punto. Esta es una elección de Create React App. Y estoy de acuerdo contigo. Me sorprende eso. Bien, eso es un buen punto. Creo que debería ser. Sí. Hmm. OK, público, ¿alguien sabe por qué Create React App pone cosas que son obviamente dependencias de desarrollo bajo dependencias de tiempo de ejecución? Si tienes una buena respuesta para eso o crees que tienes una buena respuesta para ello, escríbela. OK, estaba diciendo que voy a hacer esta instalación de npm. Lo voy a hacer desde la línea de comandos. Pero una de las cosas geniales que puedes hacer en WebStorm es que podría decir prettier aquí. Y se autocompletará. Y puedo elegirlo. Y hará la búsqueda por mí. Mierda, voy a hacerlo aquí. Bien. Así que ahora cuando guarde esto, el IDE va a decir, oye, cambió. ¿Quieres hacer una instalación? Por qué, sí. Sí, IDE. Gracias. Gracias por ser tan útil. Se está ejecutando la instalación de Yarn. Va a buscar 500,000 paquetes de npm porque así es como rodamos en los front ends estos días. Aha. Todo va a las dependencias. Tengo que aprender sobre eso. Buen punto. Buen punto. Andy, tenía la foto arriba. Y luego se fue. 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 code. Ni siquiera sé qué es el comando Alt L. Mis manos lo saben. Lo hacen automáticamente. Sólo empiezo a pensar y mis manos lo escriben ellas mismas. Así que voy a ir a Printier. Y esto está en las Preferencias. Y voy a decir, tengo un paquete Printier instalado en los modules de Node ahora. Úsalo. No tienes que ir a buscarlo globalmente o algo así. Y luego esta es la parte importante. Puedo marcar 0, 1, o ambos. Y puedo decir, ejecuta Printier siempre que elija reformatear el code. 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 fue introducido en la última versión, creo, 2021.2. Así que de vuelta en Printier, lo voy a hacer de la manera simple. Voy a decir en Reformat Code.

Y ahora, observa lo que sucede. ¿Ves esa comilla simple? Voy a reformatear code. Y porque Printier tiene una opinión diferente a la del IDE, piensa que las cosas deberían ser comillas dobles. Cuando reformateo code, está ejecutando 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 súper simple. Y ejecutaré Printier, obtendré una identación 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 estropeado 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. OK, así que ahora tenemos un componente de React muy simple que formará la base para nuestras testing más adelante. Pero vemos que tenemos algunos problemas en nuestro code ahora. De hecho, tenemos dos. Y veamos. Logo está definido, pero nunca se usa. Podría volver arriba y simplemente borrar esto. Pero eso significaría detener lo que estoy haciendo y romper el flujo. En su lugar, hago optimizar las importaciones. Y esa es la combinación de teclas para ello. Y eso eliminará cualquier importación no utilizada, y reordenará mis importaciones, combinará mis importaciones donde sea necesario sin mover mi cursor. Y eso es algo genial para mí. Optimizar las importaciones o cualquier formato code lo hago todo el tiempo. Ahora otras limpiezas que puedo hacer. No estoy usando app.css o más, así que puedo borrar esa línea. Y luego puedo borrar estos dos archivos ya que ya no los estoy usando. Así que eso es Logo.SVG y app.css. Voy a borrar eso. Pero esto es una eliminación inteligente. Va a decir, ¿quieres ir a buscar algo que podría estar usándolo? Diré, seguro, genial. Y nada lo estaba usando. Ahora, veamos si borré algo que estaba siendo usado. Como, OK, bueno, si estoy borrando CSS, vamos a borrar 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, 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 haciendo JSX. Y luego el IDE te daría una pequeña advertencia y diría, hey, necesitas importarlo. ¿Quieres que lo importe por ti? Y dices que sí. Y hace el trabajo de conserje por ti. Es interesante. Create React app todavía genera esta importación, a pesar de que estamos claramente más allá de React 17. Muy bien, genial. Muy bien, hemos pasado por algunas de estas limpiezas. Hablamos de esta bondad del IDE donde si estás en una versión anterior y borras la importación de React, entonces obtendrás esta advertencia de que te falta una importación. Y obtendrás un alt-enter, que será un amigo nuestro durante el transcurso de esta masterclass, como ayuda. Y luego eliges la acción y la genera por ti. Hagamos otra cosa. Digamos que app es un nombre tan aburrido, quiero cambiarlo a mi aplicación. Bueno, lo que podríamos hacer es buscar por todas partes en nuestro proyecto y encontrar todas las referencias a app, esperar que las hayamos encontrado todas, y cambiarlo. O podría refactorizar renombrar y decir Mi Aplicación. Y ves, mientras escribo en la parte inferior, está cambiando esa referencia. Y cuando termino, presiono Enter. Y hace algo más inteligente que simplemente encontrar referencias. En el mundo de React, hay una convención, un principio de responsabilidad única, que nombras el archivo con el mismo nombre que el componente exportado por defecto. Así que el IDE me está ayudando, diciendo, hey, recuerda que hay esta guía de estilo. Puede que quieras cambiar el nombre del archivo. Sí, de hecho, gracias, IDE. Sí quiero hacer eso.

Ahora, cuando voy a ver los usos de esto, como el index.tsx en la parte superior de mi aplicación, su importación es ahora diferente. Está importando desde un archivo con un nombre diferente, y está importando un símbolo con un nombre diferente. Mi aplicación todavía está en buen estado de funcionamiento porque refactorizar, renombrar fue a todas partes e hizo lo correcto para mí, incluyendo en mi código de prueba code. Digamos que luego, sin embargo, decidí, oh no, eso es tonto porque todo el mundo lo llama app. Si lo llamo mi aplicación, entonces nadie sabrá que ese es realmente el componente de nivel superior. Oye, IDE, ¿puedes devolverlo todo como estaba? ¿Puedes cambiar el nombre de esa función a app? ¿Puedes cambiar el nombre del archivo a app? ¿Puedes cambiar la referencia get? ¿Puedes cambiar todas las cosas que apuntan a él? Todo lo que tienes que hacer es un deshacer, y va a deshacer todo lo que se hizo en esa acción. Así que 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 algo realmente útil para todas nuestras refactorizaciones, que puedes hacer un deshacer y poner las cosas que toda la unidad de trabajo, puedes volver a ponerlo como estaba antes.

OK, a continuación vamos a realizar pruebas reales. El punto de esta masterclass ahora que estamos todos configurados, haré una pausa por un momento. ¿Alguien tiene alguna pregunta? Veo a Reggie hablando sobre la optimización de importaciones y VS code, al menos en Mac OS. Y eso es de nuevo, esto es sobre los IDEs en general, editores inteligentes. No está enfocado solo en WebStorm. Deja que tus herramientas hagan el trabajo de limpieza por ti. Lo que también significa que debes pasar un poco de tiempo aprendiendo tus herramientas. Eres un profesional. Mejora en tus herramientas. Dedica tiempo durante la semana para repasar tus habilidades antiguas y aprender algunas nuevas. Los 10 minutos o 20 minutos que dediques se pagarán durante el transcurso de un año. Gracias, Dylan. Por cierto, Dylan, ¿mi audio es demasiado fuerte o demasiado bajo? Tengo la costumbre de hablar fuerte. Gracias, Jim. Y Sherry, estoy de acuerdo contigo sobre ejecutarlos como un combo, que es algo para WebSRM, al menos en 2021.2 puedes hacer que todo suceda de una manera configurable. OK, vamos a las pruebas. Llamo a esto pruebas primero en lugar de desarrollo guiado por pruebas porque lo que quiero convencerte de es que no es comer tus verduras. OK. Tienes una elección, ¿voy a comer el postre o el brócoli. Voy a comer el postre. En cambio, quiero convencerte de que esta es una forma de trabajar más placentera, alegre y productiva. Para empezar en una prueba no estoy tratando de convencerte de la calidad. La calidad es buena, pero el punto aquí es cuál es la mejor manera de trabajar para mí en este momento. Y lo vamos a mostrar desde la perspectiva de las pruebas.

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

Así que vamos a ejecutar nuestras pruebas tal como están ahora, pero bajo esta cara bonita que hemos puesto encima de Jest. Jun, tienes razón en que te encontrarás con algunos errores. Lo que puedes hacer, sin embargo, es hacer que tu code de simulación devuelva data ficticios para detener los errores mientras vas rellenando cosas. Pero como verás durante el transcurso de esto, porque estamos haciendo componentes muy pequeños y de grano fino, puedes apuntar la prueba a esta cosa muy pequeña e ignorar el resto del universo. Y así sólo estás obteniendo un par de errores, que resulta ser 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.

Así que lo que quiero hacer aquí es prepararme en el otro monitor. Lo que quiero hacer aquí, lo que quiero hacer aquí es ponerle una cara bonita a mis testing. Y esto está en este segmento, jest bonito, si estás siguiendo. Así que 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 en package JSON, obtengo estos iconos donde puedo ejecutar cosas directamente desde el canalón, y ejecutará sólo esta prueba. O, hago clic derecho en algún lugar del editor, o hago clic derecho en algún lugar de la pestaña, y puedo ejecutar todo en sólo este archivo. Así que voy a hacer eso. Voy a ejecutar app.test.tsx.

El desarrollo guiado por pruebas, desarrollo primero en pruebas en el mundo de React es un poco más lento. En realidad, en el mundo del front end, un poco más lento que otros lenguajes. Como Python, porque tienes todo el ciclo del transpilador. Tienes todo el ciclo del compilador de TypeScript que hacer antes de que pueda ejecutar el código. Así que en este caso, tenemos una cara bonita en la salida de nuestras 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 dicen qué falló, qué pasó.

Y de hecho, vuelve al código de la prueba, cambia el icono de la canaleta para mostrarte que falló, y pone un pequeño garabato que te permite saber que una prueba falló y por qué. Así que no tienes que ir a la ventana de herramientas. Puedes quedarte en tu editor y mantenerte enfocado en la salida del texto. Ahora, sabemos que esto falló porque lo cambiamos durante la limpieza. Así que ya no diría eso. Lo que podemos hacer, sin embargo, es configurar una ejecución que tenga todas nuestras opciones correctas que ejecutan todo nuestro código, en lugar de acercarnos a una sola prueba. En realidad, encuentro que acercarme a una sola prueba es la forma en que trabajo la mayor parte del tiempo. Pero a veces, y esto vuelve a lo que decía Junio, a veces quiero ejecutar todas las pruebas para ver si este cambio aquí rompió aquello de allá.

Así que vamos a crear lo que, en nuestros IDEs, se llama una configuración de ejecución. Voy a crear manualmente una configuración de ejecución basada en Jest. Y voy a decir todas las pruebas. Nuestra configuración de ejecución de Jest sabe sobre Jest. Sabe ciertas cosas que vas a querer hacer con Jest. De hecho, sabe que no sólo hay opciones, te da el texto de marcador de posición que te dice cuáles son 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 de observación. Ahora cuando despliego las configuraciones disponibles y acabo de ejecutar, que fue el archivo individual. Y luego esta nueva configuración llamada todas las pruebas. Y cuando lo ejecuto, voy a obtener la misma salida. Pero voy a obtener la misma salida, pero todavía está ejecutándose. Así que si voy aquí y veo, oh, es hola react. Ahora, si necesito arreglar mis pruebas, tan pronto como guarde, va a volver a ejecutar mis pruebas. Ni siquiera tengo que hacer la acción de ejecutar mis pruebas. Sólo tengo que escribir y guardar y hará el resto.

Así que ahora he arreglado mis pruebas. Están todas funcionando. Lucy y voy a llegar a eso en el siguiente segmento. Sí. ¿Es el siguiente segmento? Bueno, sí, aquí abajo. Bien, esa es la forma en que lo hago es un enfoque de ventanas divididas. Así que vamos a entrar un poco más en la acción de TDD donde hago algo que falla. Sé que va a fallar. Y veo el fallo, y luego miro algunas de las cosas que puedo hacer, y luego lo arreglo. Así que voy a poner este código aquí y ver un poco de autocompletado en acción. Haré esto un poco más pequeño. Bien. Voy a decir, ¿cómo lo llamo? Actual esperado. const actual igual a uno, constante esperado igual a dos. Podría poner esos en la misma línea. Voy a escribir una afirmación de prueba sobre estos valores que resulta que están incrustados en la prueba, pero eso está bien mientras estás haciendo un enfoque de prueba primero. Y quiero esperar que actual sea igual, y así es como estoy haciendo autocompletado allí. No tengo que escribir todo, para igualar lo esperado, completar la declaración, guardar, y mi prueba falla. Y me dice exactamente por qué falló mi prueba. Lo esperado y lo actual no eran iguales. Y de nuevo, si vuelvo, cambio, guardo, no escribí la acción, está observando, y vuelve a ejecutar las pruebas. Esa es una pregunta interesante, Chris. Al principio de esto, justo antes de que te unieras, usé create, react, out 4.0.3. Y luego todo es lo mismo desde entonces, lo que 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 de, oh, sí, OK. Sospecho que es porque hola react es diferente a esto. Asegúrate de que esas dos cosas sean las mismas. Espero que sean las mismas porque de lo contrario voy a tener problemas para depurar esto. Bien, acabamos de hacer desarrollo guiado por pruebas. Escribimos una prueba. Falló, y luego vimos que falló, y la arreglamos. Y en el camino vimos que el IDE nos ayudará a fallar más rápido poniendo un bleep en nuestra cara. Línea roja en esta afirmación. Falló. El icono de la canaleta cambió a rojo, dejándote saber qué pruebas fallaron. Abajo en la salida del corredor de pruebas, una prueba falló, una prueba pasó, o lo que sea. Y puedes hacer todas estas diferentes formas para navegar a tus pruebas exitosas y tus fallos. Y esa superposición, déjame volver a esa superposición, haz que esta prueba falle de nuevo. Cada vez más estoy usando esto como mi entrada, mi ventana al correr pruebas. Sólo pongo mi ratón sobre eso. Me dice qué pasó. Y lo más importante, puedo hacer clic en eso, y lanzará la prueba en el depurador. Se ejecutará justo debajo del depurador de Node.js, que está integrado en WebStorm. Y se detendrá en ese punto de interrupción. Y puedo dar pasos alrededor y ver qué valores son. E incluso puedo decir cosas como Esperado, Esperado más 1, etc. Y luego cuando termino de ejecutar las pruebas, el depurador se apaga, y se quita ese punto de interrupción. Así que esta es una forma bastante rica de desarrollar. Y llegaré al final de la historia. Nunca fui al navegador. Bien. Fundamentos de TDD. Esto es lo que veamos, Lucian estaba hablando. Esta es la forma en que desarrollo. Parece ser la forma en que Lucian desarrolla también. No me gustan las distracciones. Me gusta concentrarme en lo que estoy haciendo actualmente. Y soy un hombre de cierta edad. No puedo molestarme en recordar 500 pestañas, y necesito algo para engañar a mi mente para entrar en el flujo de las pruebas, entrar en el flujo de trabajar lentamente, deliberadamente, alegremente, bajo control.

Y así es como lo hago, oculto la herramienta del proyecto. De hecho, desactivo las pestañas. Voy a la Ubicación de la Pestaña de Acción. 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. Y entonces tengo mi code a la izquierda. Mi prueba para ese code a la derecha. Y mi salida de prueba corriendo constantemente en la parte inferior. Y trabajo, y arreglo cosas, y implemento cosas, y todo está en la pantalla. Ahora, a veces cuando estoy en mi gran monitor, tomo esta ventana de prueba y la convierto en una ventana que puedo mover a otro monitor. Y entonces realmente puedo concentrarme code a la izquierda, en realidad no, estoy al revés, para ustedes, code a la izquierda, prueba a la derecha. Y en este caso, salida del corredor de pruebas en otro monitor. Bien, hagamos un cambio en nuestro code que romperá esto. Voy a adelantar y borrar estas tres líneas, guardo mi prueba corre bien. Mi prueba corre bien. El otro que acabo de cerrar no estaba en modo de auto ejecución. Y si cambio algo en mi implementación, y luego mis pruebas se rompen, eso es genial porque estoy mirando esto, estoy sentado en ello, no tengo que ir a alguna otra pestaña o abrir algún otro archivo, todo lo que necesito para mi code, mi prueba y mi corredor de pruebas está en una pantalla. Así que felicitaciones, acaban de hacer TDD, acaban de hacer un cambio que causó que las cosas fallaran, lo revertiré, guardaré, las cosas estarán bien, eliminamos esas líneas. Puede que hayan visto ese golpeteo, ese salto del icono. Mi gran monitor aquí, recibí una notificación de escritorio diciendo que mis pruebas pasaron. Así que realmente, incluso podría ocultar esa ventana de herramientas y saber que voy a recibir una notificación de escritorio que me dice algo sobre mis pruebas.

Muy bien, voy a hacer una pausa aquí, veamos, hemos estado yendo 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 enzima en él y no estamos usando enzima y eso es React 16, así que es un poco viejo. Chris, ¿usaste la última y mejor Create React app? Creo que es 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 code a la derecha o pones tu prueba a la derecha?... Chris, pido disculpas. Eso es obviamente mi culpa. Pensé en cada paso del camino que actualicé correctamente los package.jsons, así que obviamente dejé algún artefacto perdido en allí. Así que es mi culpa. Pido disculpas. ¿Puedes decirme en qué paso del tutorial estabas cuando hiciste clic en obtener el code del repositorio? ¿Fue el primero, Configuración del Proyecto? Entonces, ¿fuiste aquí, y haces clic aquí, Limpieza del Proyecto. Oh, hombre. Tengo que limpiar la limpieza. Dios. Es difícil mantener esto sincronizado. Pido disculpas. En serio. Bueno. Vamos a entrar en testing y debugging. Lo vimos brevemente, así que no insistiré en el punto. 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 usó Enzyme, pero luego create React... No creo que alguna vez haya incluido Enzyme, pero comenzaron a incluir React Testing Library, que fue creada por Kent Dodds. Y Kent tuvo un gran artículo explicando por qué lo escribió, qué problema estaba resolviendo, y realmente resonó conmigo versus Enzyme. Su filosofía es escribir las pruebas que imitan el comportamiento del usuario. No lo trates como software, escríbelo y trátalo como la gente lo usará, algo así como la interfaz pública de la salida renderizada. Pero tienes razón, Enzyme me era más familiar también. Pero creo que está bastante claro que toda la energía ahora está detrás de React Testing Library porque Facebook lo consagró como el incluido. Lo admito, fue raro para mí cambiar. Como por ejemplo, hay un matcher para ID, que me mató cuando hice una actualización más tarde en este tutorial, y realmente necesitaba algo en lo que coincidir. Y entonces simplemente puse de forma artificial un atributo de título en el un atributo de título innecesario en el tutorial para que tuviera un matcher. Bueno, oh, palabras de lucha. Gracias por ese enlace sobre Adam. Gracias por ese enlace sobre escribir pruebas. Y parece que. Muy bien, así que Lucien pone su prueba en la web. Bueno, en este paso vamos a repasar debugging. Probablemente no lo demostraré ya que ya lo hicimos. Pero, oh, espera, no, en realidad, tengo que hacer algo de desarrollo en esto. Entonces, necesitamos hacer un poco más de limpieza. Vamos a parametrizar un poco nuestro componente, lo que generará algo de desarrollo test driven. Y dejaremos que el IDE nos ayude con alt enter. Y luego vamos a mostrar la creación de un problema y resolverlo a través de debugging. Bueno, déjame prepararme. Muy bien, comenzaré obteniendo... Actuaré como si me hubiera alejado del proyecto, volviera a él, recargara las cosas en mi cerebro, y necesita decir, hola React. Entonces, lo guardo y traeré la salida del corredor de pruebas y mi prueba corre, mi prueba pasa. Bueno, estoy de vuelta en el flujo. Estoy de vuelta en el flujo de testing. Lo que quiero hacer es parametrizar este componente de la aplicación. Y entonces, lo que voy a hacer, voy a romper las reglas. No voy a hacer desarrollo test-driven. Voy a escribir el code y escribir la prueba en segundo lugar. Luego, cuando veas el reverso, verás por qué lo hacemos de esa manera. Muy bien, voy a escribir una función llamada label. Esto no es un componente. Esto es solo un ayudante. Y va a devolver hola react. Y luego voy a venir aquí abajo y llamarlo. Y cuando digo que todo está genial, 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, prueba que genera una etiqueta. Supongo que no debería ser 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é resultados iguales a label. Haré este error a propósito. Y luego esperaré resultados para igualar un hola. Sí. Declaración completa. Y cuando digo si fallará, ¿por qué fallará? Porque Label no ha sido importado. Puedo dejar que el IDE haga el trabajo de conserje por mí. Camino hasta esto golpeo alt enter y lo hago generar la importación. Cuando guardo las pruebas, se vuelven a ejecutar. Y mis pruebas pasan. Así que hice un poco de TDD en esto y lo que es bastante divertido de esto es esto está evaluando solo las funciones de JavaScript, no es parte de React. No tiene un DOM o un componente o algo así. Así que fue bastante fácil hacer eso. Déjame volver a. El tutorial. Y así que en esto acabamos de hacer esto. Y queremos hacer que su función sea un poco más dinámica. Solo dice hola, react.

Queremos que esté parametrizado para que puedas decir hola, mundo, por ejemplo, o hacer algo como capitalizar lo que se pasó. Ahora vamos a hacer test driven desarrollo. Vamos a cambiarlo para que se rompa. Entonces voy a cambiar esto a react todo en mayúsculas. Cuando guardo, falla. Adam tiene razón. Correcto. Dice exactamente como un usuario interactuaría con él. Ese es el gran punto de Kent, que luego creo que al menos alienta a escribir componentes pequeños para que mantengas tu velocidad. Entonces mi prueba falló. Ahora tengo que hacer la implementación y arreglarlo.

Necesito implementar el comportamiento que estoy testing. Y lo que quiero hacer es venir aquí y aceptar un parámetro llamado nombre. Y luego quiero cambiar esto a una cadena de plantilla. Gracias IDE. Y quiero decir nombre en mayúsculas. Ahora, ves, no obtengo 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. En la ejecución de la prueba. La prueba falla porque no estoy pasando un argumento y es nulo. Así que 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á dando líneas rojas onduladas 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 suministrar un argumento aquí. Así que ahora cuando suministro el argumento se ejecuta la prueba. Y veamos la etiqueta. No estoy suministrando un valor aquí abajo, tampoco. El otro lugar donde lo estoy usando. Así que mi prueba aquí pasó mi prueba aquí no. Voy a arreglar este ahora poniendo en react. Ahora mis pruebas pasan, pero estoy recibiendo una advertencia en mi I.D. ¿Qué es esta advertencia? Aquí es donde entra la tipificación. Aquí es donde entra TypeScript. Typescript me está diciendo, hey, somos un proyecto de Typescript. No pusiste ninguna información de tipo en este parámetro de función. Podría escribir la información de tipificación. O de nuevo, los IDEs 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 de Typescript miró mi code, hizo una buena suposición de lo que se suponía que era el nombre y proporcionó la información de tipo para ello. Así que eso salió bastante bien. Escribí una prueba. Escribí una implementación. Limpié un poco de la información de tipificación. Tengo confianza. Recuerda, nunca fui a mi navegador. Me quedé en el flujo en mi herramienta. Así que el IDE nos dio un Alt Enter. Solucionamos el problema de TypeScript. Pero digamos que hacemos algo que simplemente no podemos entender. Estamos cansados. Lo hemos estado mirando todo el día. Sabemos que es un problema estúpido, obvio, y no puedo resolverlo. Voy a pasar el 42. ¿De acuerdo? Y mi prueba va a fallar. Ahora, de nuevo, fallar más rápido. Tengo una línea roja ondulada. Aquí es donde la combinación de TypeScript y la prueba primero realmente me ayuda. Pero en este caso, digamos que ni siquiera estoy mirando las ondulaciones. Estoy como, ¿qué está pasando? No puedo entender esto. ¿Sabes qué voy a hacer? YOLO. Lo voy a ejecutar bajo el depurador. Voy a investigar de manera interactiva, ver qué está pasando, y ver si puedo tropezar con el problema. Así que la ejecución se ha detenido en mis pruebas. Hay otra cosa buena sobre si quieres a la derecha, a la izquierda, o a la izquierda, a la derecha, pero en este modo donde tienes tu code, tu prueba, y la salida de tu corredor de pruebas, todo es muy familiar donde están enterrados los cuerpos. Estoy en esta línea en mi prueba, y puedo seguir el code paso a paso. En este caso, creo que entraré, simplemente entraré en el code. La ejecución salta a la etiqueta porque llamamos a la etiqueta, y el siguiente paso fue saltar a la etiqueta, y pone mi cursor aquí. Llego a ver el valor del nombre, llego a ver el cierre, llego a ver el global, todas estas cosas. Llego a ver la traza de la pila si quiero subir más alto y ver qué era todo más arriba en la pila, y llego a investigar. Así que podría decir, está bien, aM, ¿qué está pasando con el nombre? Es 42. Está bien, veamos, a mayúsculas, oh, Dios, ese es el problema. Pasé un int. No pasé un número, no pasé una cadena. Ese es mi problema. Así que 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. Así que usamos la combinación, en realidad acabamos de usar 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 un terminal y un navegador y dónde estoy. Y combiné la prueba primero, combiné TypeScript, y combiné el Depurador para tener una experiencia que me facilitó mucho llegar justo al lugar que quiero y investigar. no hay declaraciones de console.log. Así que entramos en nuestro code, vimos cuál era el problema, vamos a poner las cosas de nuevo donde estaban. Salimos del depurador. Cerraremos la pestaña del depurador, lo volveremos a poner para que funcione 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ó conmigo fue con la enzima, estaba pensando en mis pruebas como implementaciones y pinché en el interior de las cosas y. No sólo eso no era valioso para mi cliente a quien no le importaba, en realidad creó esta enorme carga de mantenimiento porque cada vez que cambiaba los internos, tenía que ir a arreglar todas estas pruebas que estaban rotas por razones que realmente no importaban, hay esta otra estrategia de, asegurarse de entender que las pruebas son tanto buenas como malas, son como este peso que estás arrastrando en tu proyecto y cuando refactorizas cosas, tienes que ir a cambiar un montón de pruebas. Consigamos un enlace para el chico, y lo pegaré en la parte superior del chico donde puedes ver un montón de tips. 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 mocking, en el mundo de Python el mocking es controvertido, a veces la gente lo llama un olor, estaría interesado en otros que están haciendo testing aquí, ¿utilizas just mock mucho? Sé que en Gatsby lo hago. Ah, terapia, lo siento, volvamos a esto, voy a saltarme este segmento, porque no añade nada nuevo a la parte importante que es enseñar sobre test-driven, desarrollo basado en pruebas, sólo entiende que si tienes una necesidad, puedes ejecutar tus pruebas en el motor de los navegadores, o debería decir, para ejecutar tu, podrías debug cosas en el motor de los navegadores. Me mantengo alejado de hacer eso, pero Web Store lo hace realmente fácil de hacer y sospecho que otras herramientas también lo hacen. Y así en este caso lo que yo, está todo escrito aquí.

Creas una configuración de ejecución que trata sobre eso, y luego terminamos hablando del protocolo de desarrollo de Chrome para controlar remotamente el motor JavaScript de Chrome. Y ejecutamos el code allí, pero parece y se siente aquí exactamente como si estuvieras ejecutando bajo Node.js. Y puedes seguir el code paso a paso, entrar en el code, ver tus pruebas fallar, todas esas otras cosas, y lo que tienes, es aquí, tienes una ventana privada de Chrome ejecutándose bajo su propio perfil por lo que no interfiere con tu uso personal de Chrome. Y luego, al final de tu sesión de prueba, cierra esa ventana de Chrome, elimina el perfil para que pueda empezar desde cero la próxima vez. Es realmente bastante elegante.

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

Bien. Seguimos, vamos a ver cómo usar algunas características en TSX y ECMAScript 6, y ver cómo el IDE puede ayudar a completar cosas para nosotros y mantenernos en el camino correcto. Vamos a limpiar nuestro code y probar un poco, asegurarnos de que tu configuración de prueba está funcionando. En realidad, todavía estoy ejecutando mi servidor web, mi servidor de desarrollo, Webpack. Voy a detenerlo, porque ¿sabes qué? No he ido al navegador en mucho tiempo. He estado escribiendo componentes, funciones, pruebas. Nunca voy al navegador exactamente como debería ser, bebé. Sí. Vamos a hacer un poco de limpieza. Vamos a devolver app.test.txt a su estado original. Me desharé de esto, y voy a devolver mi componente a tener solo eso. Así que hola React. Me deshago de esto. Reformateo code, optimizo las importaciones, porque hago eso mil veces al día.

OK, Alexei está diciendo que le gusta ejecutar cosas en el DOM headless, y supongo que eso es, 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 suites de pruebas paralelas, una que se trata de unit testing y otra que se trata de testing del navegador. OK, ahí tienes, Cypress. Cypress para todos. Unit tests en Cypress. OK. De acuerdo. Muy bien. Aprendí algo hoy. Aprendí que volví a estar en un punto de partida en blanco. Y ese fue mi temporizador para darnos un pequeño descanso. Estamos a 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 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 conseguiré algo de agua. Muy bien, vuelvo enseguida. Muy bien. Eso es un buen punto Alexis sobre no testing la visibilidad. Suzanne, el Postman para APIs es bastante genial. Y nuestros IDEs tienen esta cosa de archivos HTTP, que te permite escribir en un archivo la solicitud que vas a emitir. Y entonces se siente un poco como si estuvieras en un IDE en un editor, así que en realidad es bastante 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 con, oh Dios, huh. Gracias, Sherry. OK. OK, comenzaremos, o continuaremos. Continuaremos. Lo que vamos a hacer es que lo hemos devuelto a un estado de funcionamiento. Muy bien, y lo que queremos hacer es empezar a hacer subcomponentes. Refactorización porque eso es lo que react es todo. Convertir grandes rocas en pequeñas rocas, y haremos esta refactorización de una manera orientada a las pruebas para que trabajemos con confianza, pero nos mantendremos en el flujo porque no abandonamos nuestro IDE. No tenemos que ir y mirar, déjame apagar el ding. No tenemos que ir a mirar el navegador todo el tiempo. Mis disculpas. Disculpas por el ding. Así que voy a hacer un subcomponente. Pero voy a ir primero a mi prueba. Y voy a escribir una prueba que estará rota, pero eso 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 realmente el desarrollo guiado por pruebas. Voy a sentarme en app.test.tsx. Voy a escribir una nueva prueba. Déjame asegurarme de que estoy bien. Esa pregunta sobre Cypress, hace cinco minutos, habría dicho just. Pero Alexi está tratando de convencer a todos de que deberíamos estar usando Cypress para las unit tests. Alexi, tengo que conseguir que vengas a un webinar con nosotros para WebStorm y mostrar esto a todos, incluyéndome a mí. OK, 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 testing 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 agarrar una cosa de ella, una clausura llamada Get by Text. Y esto va a estar ejecutando render. Como hacemos arriba y como hacemos aquí. Y así voy a estar en este caso renderizando heading que la gente inteligente dirá que no existe. ¿Y qué quiero hacer con este texto? Quiero ir a agarrar algo del documento falso. Así que quiero agarrar un elemento de enlace como hago arriba. Get by text. Y voy a esperar que sea esta expresión regular de nuevo. Y luego voy a hacer mi afirmación. Espero que el elemento de enlace esté en el documento. Ahora, cuando digo, ¿qué crees que pasa? Se rompe porque heading aún no existe. Lo que queremos hacer es hacer un subcomponente de esto. ¿Y qué haría normalmente? Iría aquí arriba. Iría a otro archivo empezaría a escribir nuestro IDE es inteligente. Puede ayudarnos con estas herramientas de conserjería. Así que voy a decir, hey, IDE. ¿Puedes ayudarme a refactorizar esto extrayendo esto a un componente? Claro. ¿Cómo te gustaría nombrar esto? No me gusta este encabezado. ¿Quieres que sea un componente de clase o un componente de función? La función es la nueva sexy. Así que vamos a tener un componente funcional y tomó eso. Hizo una nueva función. Reemplazó el plato, hizo todo lo que yo habría tenido que hacer yo mismo. Puso una llamada a esa función aquí. Incluso hizo prettier para mí. Dios, eres tan inteligente. Gracias. Um, ahora cuando guardo, mi prueba sigue fallando porque no la he importado, pero eso está bien. Falla más rápido, lee squiggly para mí. Me dijo que había un problema.

Entonces ve y consigue esa importación para mí. Oh, no puede importarlo porque no lo exporté. Así que ahora puedo generar la importación. Generó la importación para mí. Ya no tengo algo llamado label. Pensé, Oh, eso sobraba. 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é la cosa que quería extraer. La 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é de nuevo cómo... Digamos que quiero convertir eso en un componente. Esto responde a la pregunta de cómo activar la extracción de componentes. Traes el menú de refactorización. En Mac, es control T. Estoy a punto de presionarlo. Mira en la parte inferior de la pantalla si quieres ver la combinación de teclas de Windows. Refactorizar. Luego elegí extraer componente. Lo hice escribiendo rápidamente. Podría haber presionado 0. Podría haber usado el ratón, lo que sea. Así que traje el menú de refactorización y elegí extraer componente. Ahora tengo todo esto seleccionado. No tengo que hacerlo. Puedo hacer clic en el símbolo e iniciarlo desde allí. Bien, déjame venir y mirar. Veo que hay una hermosa conversación en Zoom sobre por qué es impresionante el testing. Todo eso es genial. Ahora estoy violando el principio de responsabilidad única. Así que tengo un subcomponente heading 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 para ello. ¿Puede el IDE hacer el trabajo sucio por nosotros? Probablemente, de lo contrario no estaría haciendo este punto ahora mismo. Así que trae refactorizar mover. Debería decir que no seleccioné todo esto. Solo puse mi cursor en el símbolo. Refactorizar mover. Luego voy a obtener un diálogo. ¿A dónde te gustaría moverlo? Mira lo que hizo. Rellenó el nombre del archivo para mí. Exactamente como yo quería que fuera. Te da algunas opciones sobre algunos miembros para mover más tarde. Veremos cómo los props, el tipo que usamos para la definición de props puede ir con él. Voy a seguir y presionar refactorizar. Lo abre, me pide que lo añada a get. Tengo esto aquí y mira lo que tengo de vuelta donde estaba. Una importación reemplaza la definición que tengo, las personas inteligentes verán que mi prueba puede ser arrastrada a un nuevo archivo. Sospecho que probablemente eso 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 haré un nuevo archivo llamado adding that test that yes, X. Pega esto allí. Observa cuando pegué, pegar tiene la costumbre de generar las importaciones que necesito para mí. Vale, y luego tengo un poco de sobras aquí. Un símbolo que no necesito de la importación porque no estoy testing heading en este archivo app. No test texts anymore. Podría borrarlo o podría decir, Hey, I D.E. limpiar en un archivo cinco ve correr optimizar importaciones y ahora esa importación se ha ido este archivo de prueba principio de responsabilidad única principio. Se trata de a. Este archivo de prueba principio de responsabilidad única se trata de heading. Guarda todo una vez más. Mantén mi ventilador de la CPU funcionando y todas mis pruebas y todos mis archivos se ejecutan. OK bien. Y veamos. Sí, la belleza de las unit test es la velocidad velocidad de ejecución un segundo beneficio para esto. Me pregunto si Lexi estaría de acuerdo conmigo en que un beneficio secundario es no arrastrar el universo cuando estás refactorizando. Las unit test realmente deberían centrarse en una unidad de modo que si algo más cambia no tienes que ir a cien cosas y tratar de recordar lo que estabas haciendo hace seis meses.

OK, entonces hemos hecho el subcomponente de encabezado. Hicimos la refactorización. Hicimos la extracción y está en su propio archivo. Ahora digamos que creo que lo hice. Sí, lo hice en desorden. Pido disculpas. Entonces, lo que quiero hacer es recuperar los argumentos y agregar valores predeterminados para que mi encabezado sea parametrizable. Así que tomaré esta prueba. Voy, estoy en el archivo de prueba de encabezado y escribí una prueba para que pudiéramos pasar llamado nombre a nuestro encabezado. Y ni siquiera he ejecutado el corredor de pruebas todavía y sé que falla porque tengo una línea roja debido a Typescript. Typescript me está diciendo cuál es mi problema. Pero seguiré adelante y lo ejecutaré de todos modos. Deja que la prueba falle. Y vimos más o menos lo que iba a pasar aquí. Necesitamos poner un parámetro. En este caso, sin embargo, dado que es una función, no vamos a pasar el nombre como argumento. Vamos a obtener props y necesitamos desestructurar el nombre de la prop de él. Y entonces voy a decir nombre, lo que me permite decir aquí. ¿Estoy haciendo las dos mayúsculas? No, no lo estoy. Guardaré. Y esta prueba dirá. Necesito. Iré poco a poco a través de algunas de estas cosas y las arreglaré. Eso debería ser. Oh, signo de dólar. Duh. No estoy en un literal. Entonces esta prueba pasa. Esta prueba falla, porque ahora tengo una prop requerida. He hecho una refactorización, que rompió el contrato. Y otros usos de él me están diciendo que el contrato se rompió. Ahora no tuve que ejecutar la prueba para saber que fallé, porque obtuve una línea roja para eso. Entonces, ¿cuál es la solución para esto? Entramos en props y tipado. Ahora, el primer intento en esto será poner en línea la información del tipo de prop. 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 información de tipo en línea, casi todo el mundo pone los tipos de prop en un símbolo independiente en TypeScript. Durante mucho tiempo utilicé la interfaz. Todavía creo que la mayoría de la gente usa la interfaz. Vi un buen artículo que decía usar tipo, no interfaz, porque el tipo es más limitado. Y la información de tipado que pones en las props debería ser limitada. Así que podría extraer esto y empezar a escribir tipo, allá arriba, volver, escribir algunas cosas más aquí. ¿Crees que podría extraer una interfaz? ¿Crees que podría hacer algo de refactorización sobre la interfaz? ¿Por qué? Sí, puedo. Oh, tengo que estar dentro. Entonces digamos, sí. Y voy a llamar a esto Heading Props. Y verás lo que hizo aquí arriba. Creó algo llamado Interfaz Heading Props. Veamos, quiero que extraiga a una interfaz en esto. Así que toda esa predicación que acabo de hacer sobre tipos, etc. Así que lo dejaré como interfaz porque creo que eso es lo que tengo en mi tutorial. Ahora, veamos. Eso es lo que quería hacer. OK. Ya formateado. Así que he extraído la información de tipo en línea sobre mis props, la extraje a un tipo independiente, y luego la referencié. Y esto es muy fácil de leer. Eso es realmente genial de ver. Bien. Ahora todavía no he resuelto el problema sobre el valor predeterminado de la prop. Lo que quiero es satisfacer el contrato antiguo utilizando un argumento predeterminado de ES6. Así que vamos a hacer eso. Arreglemos esto para que hola, React todavía funcione. Y lo haría poniendo un argumento predeterminado aquí. Pero algo más va a ir raro 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á enfadado conmigo. TypeScript está enfadado conmigo en esta línea. ¿Por qué TypeScript está enfadado conmigo? Pasemos el cursor por encima. Creo que uno de ustedes tiene su 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. El nombre es requerido. Pero no se está proporcionando aquí. Así que lo que necesito hacer es decirle a TypeScript que el nombre, según este contrato, es en realidad opcional porque tenemos un argumento predeterminado. Guarda eso. Las pruebas todavía se ejecutan. El compilador de TypeScript está contento. Todos 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. Bien, y ya hablé sobre el principio de responsabilidad única. Ya movimos el tipo, el subcomponente a su propio archivo. Lo que debería señalar es que haré, fingiré decir subencabezado.

Refactorizar y extraer componente. Extraer. De todos modos, cuando lo traje, 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 ese es un enfoque bastante inteligente para la refactorización. Toma el subcomponente que quieres crear y todas las cosas de las que depende, y muévelo al nuevo archivo. Estamos en buena forma desde una perspectiva del principio de responsabilidad única.

Creo que pasaré por alto un poco esto, el JSX y el TSX. Creo que la mayoría de ustedes saben que si digo clase, está roto en JSX, TSX, porque eso resulta ser un nombre reservado en JavaScript y TypeScript, la declaración de clase. Así que React te dice, tienes que nombrarlo nombre de clase. Y obtienes mucha ayuda para estas cosas de TSX, gracias a TypeScript. Eso puede hacer aparecer estos mensajes de error realmente significativos sobre, esto 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 para los elementos en los spans, que yo estaba usando. Solo están en los elementos de entrada. Bien. Así que eso me permite saltarme la cobertura de esa última parte.

Lo que mostramos en esto fue una combinación de dos cosas que nos ayudan a fallar más rápido y a mantenernos en el flujo, desarrollo basado en pruebas y tipado, TypeScript. Y la combinación de los dos, no tienes que enviarlo, descubre que fallaste. No tienes que ejecutarlo en un navegador, Espolvorea console log en 50 lugares, espera que te tropieces con ello. Ni siquiera tienes que ejecutar tu prueba, no tienes que escribir una prueba y ejecutarla para descubrir que fallaste. Puedes obtener una decoración en tu IDE diciendo que rompiste el contrato. Bien, pasaremos al siguiente paso. Y déjame poner el temporizador para que esté en buena forma aquí. Tomaré cualquier pregunta. Miraré algunos puntos del chat. No dudes en decirme que voy demasiado rápido o demasiado lento, hablando demasiado alto, lo que sea. Veamos. No creo que esté al día en todo esto. Este punto sobre testing el contenido de un hijo no es relevante, es un buen punto. Eso es en realidad creo que algo de enzima, ¿verdad? Superficial versus montaje. Eso me llevó un tiempo dejar de pensar sobre cuando cambié a la Biblioteca de Pruebas de React. Simulando devoluciones de llamada, estos son todos grandes puntos sobre la simulación de componentes hijos. Veamos. Cheri, es un punto interesante sobre el IDE, sabes que soy Python y soy web y JavaScript, esas cosas no fueron escritas. Fueron escritas para ser tan simples que no necesitabas un IDE. Pero ahora con sistemas más grandes donde las cosas como React con subcomponentes, y cosas como eso la tooling puede realmente ayudar. Y espero que los editores e IDEs más inteligentes puedan realmente entregar algunas ganancias de productivity en esto. Alexey, buena pregunta sobre get by text. Alexey, ¿te encuentras a ti mismo o a alguien te encuentras usando el parche de escape de data-test-ID en la biblioteca de testing? Siempre que hago eso, siento que he hecho algo mal. Buena pregunta sobre la cobertura de code. Soy mucho más grande sobre 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 realmente fácil obtener la salida de cobertura integrada justo en tu editor. Debería hacer eso más. Buen punto, Stephen, sobre las recommendations sobre qué biblioteca de afirmaciones de consulta que solía usar. Supongo que async influye en eso un poco. 88%, eso es solo un gran número. ¿Por qué no? Y entonces, Brandon, estábamos hablando antes un poco sobre qué probar, cuánto probar. Y esa Biblioteca de Pruebas de React 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 así como detectas rutas de code 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 solo pruebes un estado de un componente. Storybook, ¿alguien usa storybook? Porque storybook realmente ayuda a promover esa idea de todas las variaciones de un componente. Oh, mira, algunos fans de storybook por ahí. Bien. OK, cambiemos a componentes de clase solo por diversión para prepararnos más tarde para hablar sobre el estado. Hemos estado haciendo componentes funcionales ahora mismo. Actualmente, Anton está construyendo un proyecto con LearnN Storybook. Bien. Esa es una buena combinación. LearnN Storybook produce mucho contenido Esa es una buena combinación. Learn ha estado alrededor por un tiempo. Supongo que Learn está mirando a Yarn 2 diciendo, vuelve a mí cuando consigas la historia recta, 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, vamos a ver las ideas similares sobre la información de tipo para las indicaciones, pero en el contexto de un componente basado en clase. Lo admitiré, 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 odies. Vamos a hacer un nuevo archivo. Vamos a hacer un contador. El nombre del componente ya revela hacia dónde va esto. Va a haber algún estado, y vamos a usar el estado local en el componente en lugar de Redux o emr, mi nuevo mejor amigo. Y entonces voy a escribir una prueba primero. Ahorremos algo de tiempo. Cortar y pegar. Cortar y pegar para la victoria. En el lado de la prueba, voy a crear un nuevo archivo. Counter.test.tsx. Mira qué rápido puede escribir Paul. La prueba está rota y TypeScript está enfadado por razones obvias. El archivo no existe. Pero de nuevo, falla más rápido, TypeScript nos dijo que eso no existe. Obtendremos un punto de partida aquí. De nuevo, voy a hacer trampa y no escribir esto. Vamos a estar haciendo mucho tipado en esto a medida que avanzamos, así que está bien. Me gustaría recordarte, especialmente si saltaste un poco después del principio, no tengo que ejecutar todas las pruebas. Puedo caminar justo hasta esta única prueba y ejecutarla o ejecutar solo las pruebas de contador haciendo esto. Bien.

Queremos resolver 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 o TypeScript, decidió prohibir la etiqueta y para los spans. Así que este es el contrato público, habrá una etiqueta con un valor. Y luego habrá otro span que tiene el contador real. Estoy probando ambos, la etiqueta y estoy probando el contador. 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 NPM 45 alguna vez tendrá capacidades de auditoría? OK, hay una pregunta sobre verificar si el contador para probar en lugar de en el documento. Buena pregunta, podría estar verificando si el valor solo verifica eso. Supongo que en este punto, no quiero probar demasiado y si cambio de opinión, mis pruebas fallan. Digo que esta prueba de conteo seguirá pasando, pero si probé el valor real, no lo haría. Y supongo que he tomado mi decisión. Realmente no me importa lo que dice, pero tienes que tener una etiqueta como si lo localizaras para tener una palabra diferente para el recuento NOM. Estamos bien. Mostraremos con componentes basados en clase cómo hacer una prop. Y lo haremos usando este proceso consistente que hemos estado haciendo. Escribiremos una prueba fallida, arreglaremos el nuevo componente tonto y luego iremos a la cosa que lo llama, que aún no tenemos nada que lo llame, y nos aseguraremos de que lo use correctamente. Así que agregaremos 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. Todo bien, pero de todos modos ejecutaré la prueba para que podamos ver que las pruebas también fallan. No, las pruebas no fallan, porque esto es un fallo de TypeScript. Esto no es un fallo en tiempo de ejecución. 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. ¿Podemos tener un valor predeterminado? Y esto es más complicado ahora, porque antes, cuando teníamos el encabezado, lo pasábamos a una función el valor llamado props, que era un objeto que se podía desestructurar y la desestructuración de ES6 lo admite. 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 los locales para renderizar, déjame echar un vistazo aquí y decir. 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. Bien, gracias, Elaina. OK, ahora necesitamos conectar la UI. 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. Entonces, quiero resolver un contador con esa etiqueta. Solo puedo comenzar a escribir. Ha buscado en mi proyecto, de hecho, ya ha indexado mi proyecto, por lo que sabe dónde están todos los cuerpos enterrados, y puedo elegir contador. Conoce las props, así que puedo usar solo la etiqueta, y diré, ¿cuál es mi actual? Así que generó la importación por mí cuando hice la autocompletar. Estamos en buena forma. Ahora tenemos algo que usa nuestro contador, pero nuestras pruebas no se rompieron porque la prueba de la aplicación ni siquiera esperaba que eso estuviera allí. Deberíamos haber escrito una prueba primero antes de agregar esto. Bien, hagámoslo. Entonces, mis pruebas pasan, pero quiero probar en la aplicación para ver si la etiqueta está ahí. 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 retrocedí en el tiempo y fingí que hice TDD y aún no lo he puesto. Ahora, cuando lo pongo, digo, ¿lo implementé correctamente? Bueno, seguro que sí.

Porque mis pruebas pasaron. Genial. Así que ahora tengo una prueba que demuestra que mi componente de clase contador está en el componente de aplicación principal. Eso es una buena noticia. Hasta ahora todo va bien. Y creo que eso es un error de tipeo. No, no, no, no es un error de tipeo. Me está animando por fin. ¿Podemos finalmente echar un vistazo a cómo se ve en el navegador? Así que voy a volver a mi script de inicio. Lo enciendo. Va a generar el navegador o generar el paquete del servidor de desarrollo, etc. Y en realidad veo el componente contador mal diseñado porque son dos spans, mostrando actual y uno. Bien, voy a empezar con la siguiente parte, parar, hacer algunas preguntas, mirar la hora. Y nos queda una hora. Nos vamos a quedar sin tiempo. OK, muchos más para storybook. Genial. Alexei está escribiendo en este Discord. Así que volveré al chat de Zoom. Suzanne, espero haberlo hecho bien. Eso no es Suzanne. Correctamente me señaló que no puse una prueba primero. Tenías razón. Debería haber hecho una prueba primero. Veamos. Bien, estamos al día con eso. Alexei pregunta, escribe una prueba de integración primero para asegurarte de que la aplicación está utilizando Counter. 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 la prueba primero. Nota para mí mismo, nunca recordaré esa nota. Veamos qué más tenemos. Get by title espera de dos a tres argumentos. Lo conseguiste funcionando. ¿Qué fue, Dylan? ¿Qué fue lo que salió mal con eso? Alexi tiene razón, ahora que tengo una especie de prueba integrada, si cambio la estructura interna del contador, entonces la prueba de la aplicación se romperá y la prueba del contador se romperá. Y entonces la pregunta de los componentes padres con componentes secundarios, ¿deberías probar la estructura de los componentes secundarios o deberías ver si están en el documento? Alexi, ¿estoy diciendo correctamente el punto que estás haciendo? Realmente es una cuestión de, sí. Así que ahí lo tienes. Sí, supongo que lo que harías para eso, ¿Hay un selector de la biblioteca de pruebas de React que dice 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, hola, soy el nombre de la clase, título, o algún selector que fuera visible. Data test. Ja ja, aquí vamos, sí, data test. Veamos. Reestructuré get by title de la cosa. Oh, sí, OK. ¿La reestructuración te mordió, huh? Bien, ¿recibiste alguna advertencia del Servicio de Lenguaje de TypeScript Dillon, cuando hiciste la reestructuración mal? ¿Deberías haberlo hecho? Oh, bien, bien. Te pusiste rojo. Fallaste más rápido. Genial. Bien, algunos comentarios en Discord. Prueba visual, estoy interesado en algo así también. Algo así como que he visto algunas cosas donde pueden capturar esencialmente los píxeles de una página y luego comparar más tarde y ver si tu diseño de CSS cambió. Me pregunto si estás hablando de algo así. Creo que es Florian pero también menciona que puedes hacer algunas de las propiedades calculadas para ver si las cosas están en la posición que creen que están. Sospecho que eso es una cosa de Cypress, aunque no va a ser una cosa de JS DOM. Cypress hace eso, dice June. Todos los caminos llevan a Cypress, ¿verdad? Todos los caminos llevan al consumo infinito de energía al ejecutar tus pruebas. 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 que podamos tener un estado local fácil. En este caso, una cuenta. Vamos a hacer un componente de clase muy simple. Va a tener estado. Y luego ese estado necesita algo de typescriptificación en él para que obtengamos líneas rojas y autocompletado. Pero se va a poner un poco raro, lo que entonces te hará pensar, voy a volver a los componentes funcionales y a los hooks. OK. Siempre empieza con una prueba. Vamos a escribir una prueba fallida primero para la implementación, conectada al padre. Blah, blah, blah. Queremos contador y contador. Así que tengo contador aquí. Quiero contador.test aquí. Y ahora te apagaré. Y solo tendré mi corredor 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 empiece en cero. Así que cortaré y pegaré esto. Y luego lo guardo, lo que hace que se ejecute. Y falla porque no empezamos en cero. Actualmente estamos en uno. Pero eso no es un valor real con estado. Es solo el carácter en la pantalla. Así que esta prueba falló correctamente. Ahora necesitamos entrar en la implementación. Tenemos un componente base de clase. Voy a mover esto por un segundo. Tengo un componente base de clase 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é.

Podría haber hecho lo mismo insertándolo y luego extrayéndolo, pero hay algo acerca del 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 voy a llamar CounterState. Y va a tener, ¿cómo llamé a ese valor? Count. Eso es un número. Y el IDE me está diciendo que aún no estás usando eso. Lo sé. ¿Dónde pongo esto en mi declaración CLASS dentro del genérico? Y eso me permite decir que el primer argumento del genérico es la información de las prop. El segundo argumento del genérico es la información del estado. De hecho, mira eso. El pop up nos dice con P y S, la siempre útil P y la 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 metido en la programación funcional como lo está 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. Así que voy a hacer esto en iteraciones y aprender en el camino sobre algunos errores. Estaré interesado en ver si lo que llamo la mejor manera es incorrecta, si hay una manera mejor estos días porque las cosas siempre cambian. Estoy dentro de la clase ahora. Y voy a añadir algo como un atributo de clase, un campo. Le voy a dar información de tipo y decir que el estado es de tipo esto, y aquí está el valor inicial. Así que eso está bien. Y luego eso me permite hacer esto. Así que reemplazaré el uno con este punto de estado punto, mira eso, autocompletar, ¡yay! Muy bien. Guardaré, dejaré que mis pruebas se vuelvan a ejecutar. Mira eso, se puso verde y me apareció una pequeña ventana emergente en mi escritorio diciendo que mis pruebas pasaron. Así que ahora tengo un componente con estado que internamente decide que empieza en cero. Estoy muy contento de que todos ustedes estén discutiendo entre sí sobre el lugar de los componentes de clase versus los componentes funcionales. Podría participar, pero probablemente me equivocaría porque es muy una cuestión de estilo. Así que añadimos un segundo genérico para el estado junto a los prompts y pusimos un estado inicial como variable de clase, lo que nos dio algunos beneficios. Pero como sabes el gran problema con esto es la inmutabilidad, no se supone que simplemente asignes a ese objeto, se supone que uses el método setState para llegar allí. ¿Y si no lo haces? ¿Qué pasa si haces esto.state.count más igual a uno? ¿No te gustaría que el compilador pudiera señalar eso en rojo? ¿Si TypeScript pudiera detectar que algo es de solo lectura y estás asignándolo? Puedes hacerlo, y así lo vamos a hacer. Vamos a reemplazar nuestra definición de tipo con esto. Vamos a establecer 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 solo lectura como el tipo. Esa es una palabra clave incorporada en TypeScript. Por eso no está importada. Y en el genérico, vamos a decir que la forma de esta cosa que es de solo lectura es esta. Y así que una vez que hacemos eso, necesitamos usar el estado inicial ahora en lugar de nuestra definición manual. Así que vamos a cambiarlo para usar también el solo lectura. Prefijo, así que solo lectura. Y ahora si quisiera hacer algo que cambiara el valor, veremos en un segundo que ahora puedo entrar en él. ¿Qué pasa si quisiera decir aquí este estado cuenta? Igual a nueve, mira eso. Genial. De todos modos, volvamos a lo que se supone que debemos hacer, que es incrementar la cuenta. Me detendré allí y miraré por aquí. Eso es maravilloso. Sí. Eso es un buen punto, Elena. Ese es el problema opuesto. eso es gracioso. Es rico. De hecho, creo que estoy de acuerdo contigo más que la posición de ¿quién fue el que decía lo contrario? ¿Correcto? ¿Qué fue eso? June. OK. Así que volvamos a tener un valor inicial. Así que el mundo exterior puede decir, hey, hazme un contador pero usa esto como el valor inicial, cambio en el comportamiento, cambio en las promesas y el contrato significa una nueva prueba, ¿verdad? Voy a tomar esta prueba. Volveré a contador. Hey, las líneas rojas para la victoria, estoy rompiendo el contrato. Por supuesto que estoy rompiendo el contrato. No hay una prop de inicio. Muy bien, y lo guardaré para que la prueba se ejecute. La prueba falla porque 10 no es el valor, pero TypeScript falla porque start no es una prop. Así que arreglaremos la definición de tipo y contador también permitirá, lo escribiré. ¿Quieres empezar? Muy bien, así que ahora la línea roja desapareció. La prueba todavía va a fallar porque aún no he implementado el punto de partida. ¿Cómo quiero implementar el punto de partida? Las cosas se complican un poco aquí. Solo lectura. No puedo meter esto al principio. Así que voy a usar un método de ciclo de vida, y en este método de ciclo de vida, tendré acceso a las props, al valor pasado. Y a partir de eso, puedo obtener un punto de partida. Así que en componentDidMount, tengo acceso a las props. Así que vendré aquí, añadiré ese método. Se ejecuta una vez. Si se pasó una prop, si tengo una prop, voy a 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 todo se volvió verde. Muy bien. Punto de partida. Así que he hecho algo en el punto de partida, que no funcionó. Pasé start como una prop. Si props.start, si props.startState. Me pregunto si esto es porque la prueba no tiene acceso al nivel del ciclo de vida. No puede ser. Muy bien.

Voy a poner una declaración de depuración. ¿Por qué no puse solo lectura cuenta número? Entonces Matt, estaba tratando de modelar todo el estado en lugar de solo la cuenta. Podría haber hecho, tienes razón, podría haber tenido solo la cuenta. La idea es que más tarde, 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, entonces estoy empezando en cero. This.props.startzero. Entonces debería ver. Vale. Podrías ver mi problema. Muy bien. This.props.start debería evaluarse como verdadero. Así que estoy estableciendo el estado, y supongo que este es solo un caso en mi prueba. En realidad no estoy haciendo el ciclo de vida del componenteMount. Muy bien. Nota para mí mismo, estoy arreglando eso. Quizás Angela está a punto de darme la respuesta correcta sobre esto. Muy bien. Ahora tenemos que hacer el tercer paso. Hablamos de los tres pasos. Hemos escrito una prueba fallida. Hicimos una implementación. Ahora necesitamos ir al padre y conectarlo en la UI. Así que empezaré con app.test.tsx. Solo estoy haciendo las tres cosas en una gran prueba jumbo. Probablemente no sea lo más inteligente que hacer. Muy bien. Esto se ejecutará. Y en realidad no necesito hacer nada en el code porque estaba incluyendo el subcomponente, y estaba mirando dentro del subcomponente. Oh. Creo que es la F de Florian. Voy a adivinar y decir que lo es. Solo pasó que elegí algo que todavía iba a estar en el documento. Oh, eres tonto. Así que si hubiera dicho 99, habría fallado. Porque 110 todavía tiene un cero en él. Estoy cansado. Quizás eso es a lo que le echaré la culpa. OK. Así que arreglado, y tenemos un componente de contador que puede pasar props, pasar estado, es configurable desde el exterior. Puedes darle no solo la etiqueta, sino que puedes darle el punto de partida, y llevará la cuenta de los conteos. Y tenemos todo eso envuelto en información de tipo, que hace algún tipo de intento de imitar solo lectura. Y estoy de acuerdo con no puedo recordar quién fue el que lo dijo. Estoy de acuerdo contigo en que en lugar de modelar cualquier cosa posible, debería ser más específico en, digamos, ¿cuál es el contrato de este componente? Buen trabajo. ¿Es Florian? ¿Es eso lo que significa la F? ¿O estoy proyectando? Frank. OK, lo siento. Muy bien. Karlsruhe, ¿verdad? ¿Recuerdo eso correctamente? Bien. Muy bien. Adelante. A algunas cosas divertidas. Y puedes ver, estamos llegando al final de la película, y estamos haciendo bastante bien en tiempo. Antes de entrar en esto, como nota, las cosas están a punto de ponerse reales. Así que hagamos una pequeña pausa. ¿Alguna pregunta? ¿Algún advice sobre cómo reescribir este tutorial si lo hago en el futuro? ¿Alguna cosa que hayas visto presentada que tienes tus propias ideas sobre? usehooks.com, oh, eso parece una interesante masterclass. Voy a seguir adelante y hacer clic en ese enlace, Suzanne. Gracias. OK. No puntos. Seguiremos adelante. Tenemos un contador. No lleva la cuenta de nada. Así que no tenemos forma de incrementarlo, excepto por una prueba. No lo hemos conectado a ningún manejo de eventos. Vamos a agregar a nuestro componente de contador el manejo de clics para incrementar y mostrar cómo vamos a modelar esto en TypeScript y luego cómo vamos a trabajar con esto y simular clics en las pruebas. Este es uno divertido. También estaré interesado en ver si algunos de ustedes profesionales por ahí tienen un buen conjunto de suggestions más recientes y mejores. Así que vamos a hacer lo de siempre. Vamos a escribir pruebas, vamos a obtener squiggles. Vamos a hacer nuestra implementación, etc. Esta vez, sin embargo, en realidad vamos a encender un navegador al final y hacer algunos clics. Aprovecharé este momento para notar cuánto hemos avanzado sin realmente mirar un navegador. ¿No es genial? Podemos hacer desarrollo de React sin teclear, cambiar a un navegador, presionar recargar, hacer clic en el universo, ir a la console, console, bloquear algunas cosas, volver a tu editor y teclear. Oh, Dios. Solo me está matando. Vamos a escribir una primera prueba fallida en el contador. Y esto va a ser un incrementador, un clicker de eventos cosa. Y verás, vamos a obtener otra importación de la biblioteca de pruebas, evento de fuego. Eso se ve sexy. Así que voy a copiar y pegar esto, volver a contador, ocultar esto, y agregar una nueva prueba. Necesitaré una importación. Así que hey, gracias IDE. Ve a hacer esa importación por mí. Optimizaré la importación de formato libre code como el perro de Pavlov. Y lo que está sucediendo aquí es que voy a escribir una prueba para el punto de partida del contador. Y en este caso, estoy mirando esta cosa. Está coincidiendo con este atributo título, conteo actual. Estoy obteniendo su valor, su contenido de texto.

Y quería pasar de 0 a 1, y quiero hacerlo simulando un clic en ese elemento. Así que repasemos esto un poco. Tengo un componente contador. Y voy a renderizarlo. Y voy a extraer algunas clausuras que me permiten echar un vistazo en formas ricas e interesantes, como encontrar elementos que coinciden con un título. Así que voy a encontrar un elemento que coincida con el título. Permíteme pasar el ratón por encima de esto. Es de tipo HTML elemento. Eso es lo que devuelve GetByTitle. Y luego voy a disparar un evento en él, el evento de clic, voy a disparar en ese elemento, ese HTML elemento que localicé. Y luego voy a afirmar, hey, ahora has incrementado. Así que estamos bien. ¿Correcto? Así que repasamos lo que hace todo eso. Y mira, falló, obviamente. Porque todavía es cero. El elemento sigue siendo cero. No, disparar el evento en él no tuvo efecto, porque no hemos hecho un manejador de eventos. Evento de usuario, luego evento de disparo. No lo sé. Alexei, ¿qué te parece esto? Solo dime, dime que es correcto, y te creeré. Abriré una pestaña. React. React, no, solo testing library, y estás diciendo evento de usuario. ¿Estás diciendo que es más específico, y que coincide mejor con el tipo de TypeScript real que se está utilizando? Veo evento de usuario y buenos docs para ello. Es una simulación más advanced, aquí vamos, es una simulación más advanced de las interacciones del navegador que Fire event. El ganador de hoy es Alexei por acertar. Tenemos dos Alexeis, así que Alexei con una Y. OK, lo que significa que tengo que cambiar mi tutorial de nuevo. Espera hasta React 25. Necesitamos un manejador, un manejador de clics, porque el componente no maneja los clics. Vamos a hacer nuestra implementación. Escribimos nuestras pruebas fallidas. Hagamos que la prueba pase. Así que voy a ir a mi contador aquí. Probablemente lo quiera 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. Va a ser una función de flecha, y va a agarrar esto y llamar a setState. Pero esto es un poco problemático. Mi prueba ahora pasa, pero esto es problemático porque se desaconseja poner definiciones de funciones de flecha como manejadores de eventos. ¿Por qué? Porque todo esto se va a reinterpretar y recompilar cada vez que se vuelva a renderizar esto. Está funcionando en el ciclo de renderizado. Podría ser 60 veces por segundo que está rehaciendo toda esta compilación. Así que queremos sacarlo del manejador de eventos. Y voy a ponerlo en una especie de método de clase. Y eso también me ayuda a hacer aislamiento de pruebas. Puedo probar el conteo de algo sin necesidad de pasar por un renderizado. Y entonces este manejador onClick puede decir esto. Para aquellos de ustedes que están a punto de quejarse conmigo, ese es el punto. Estoy pasando por variaciones de esto para llegar a lo correcto. Y obviamente, puedo hacer auto-completar. Bien, cuando guardo eso, obtengo mis rutas de prueba. Y lo que quiero señalar es que creo que en realidad dije método. Esto en realidad no es un método. Si fuera un método, entraríamos en el problema de esto. 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 de esto correcta para que no sea atado a un evento como esto. El componente es esto. Pero todavía está recibiendo el evento pasado. No lo estamos usando, y va a ser el esto no es el evento, pero esto es el componente. Sin embargo, estamos recibiendo un evento pasado. Así que modelémoslo correctamente. Y luego se enfadará porque dice que es cualquier cosa. Y entonces, OK, te callaré, compilador de TypeScript. Ahora estás contento, ¿verdad? Bueno, todavía tenemos algunas advertencias sobre un evento no utilizado, llegaremos a eso en un segundo. Pero si mi tsconfig.json apaga la capacidad de tener cualquier cosa, obtendré algunas quejas. Así que estoy haciendo trampa al decir cualquier cosa. Solo 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. OK, y voy a volver aquí a tener mi, sí, el Discord abierto. Bien. Mi primer intento va a decir que es un evento de ratón. Y un evento de ratón es un genérico para el tipo de cosa que se hizo clic. Así que voy a decir eso. Bien, bien. Y luego voy a empezar el proceso de usar esta información diciendo lo que eventualmente queremos llegar a es ¿presionaste Shift Click? Si es así, vamos a incrementar por 10. Y por eso queremos tener acceso al evento es que queremos manejar el uso de Shift Click. Así que voy a venir. Voy a empezar el proceso de cometer algunos errores. ¿Correcto? Así que este es mi primer intento. Y guardaré. Veamos qué pasa con las pruebas en ejecución. Las pruebas fallaron porque no tiene la respuesta correcta en ella. Algo ha salido mal. ¿Qué salió mal? Hmm. Por cierto, el final de la historia es siempre consigo la pared ternaria. ¿Puede la escritura ayudarme a ver cuando me equivoqué en la ternaria? OK, no puedo hacer un más en un número o número en Boolean. Así que esto puede ser un Boolean o un número. ¿Por qué es eso? Estoy diciendo uno y estoy diciendo 10 aquí.

Es un número. No puede ser un Boolean. Así que seguiré con el 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, ese subrayado rojo desapareció. Pero ese no era nuestro objetivo. Nuestro objetivo no era mover el subrayado. Nuestro objetivo era eliminar el subrayado. ¿Por qué estás enfadado ahora? Lo mismo, piensa que el lado derecho del igual puede ser un número o un boolean. Así que sigamos mirando esto un poco más. Y finalmente nos damos cuenta de que tengo el orden del operador ternario mal. Es si esto, entonces eso, de lo contrario eso. Y TypeScript me ayudó a señalar todo el camino porque decidí dar el paso extra y poner información de evento, información de tipo, en el evento. Fue capaz de ayudarme a autocompletar. Fue capaz de decirme que eso evalúa a un boolean, todo eso. Y June tiene razón. Se subraya todo el camino, ¿verdad? El error tipográfico, Shift key es Boolean. Simplemente dice, ves donde dice Boolean al final aquí. Simplemente dice si se presionó shift o no. Para este evento se presionó shift. Alexei, ¿eso responde a la pregunta? Muy bien, genial. Con eso en mente, guardaré y veré qué pasa. Mis pruebas pasan. Muy bien, tengo un contador en el que se puede hacer clic con shift. Yay. ¿Ves algún cambio en mi prueba? No, así que necesitamos manejar la prueba para eso. Avanzado por 10 fue clic con shift. La biblioteca de pruebas tiene algunos disparos de eventos. Me pregunto si esto es incluso cierto ahora. ¿Está incluido el user event? Quienquiera que me haya hablado del 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 donde no podía usar fire event. Parece que fire event es la mejor cosa para hacer en todo momento. Oh, mira. Sí, yarn. Debería haber escrito yarn justo entonces. OK, mientras estás corriendo, escribiré la importación manualmente en esto para que podamos centrarnos un poco mientras hacemos esto.

OK, y voy a escribir una nueva prueba que básicamente clona la última prueba. Y luego la revisaremos. Y queremos aumentar el contador en 10 fingiendo mantener presionada la tecla Shift cuando hacemos clic en el contador. ¿Cómo vamos a hacer eso? Aquí arriba, hicimos FireEvent. Esta vez, vamos a hacer UserEvent. OK, me gusta que veo tu punto. Sí, todo es parte del mismo paquete de espacio de nombres, pero está desempaquetado. Esta vez, sin embargo, cuando hacemos clic, vamos a elegir un objetivo al igual que elegimos un objetivo. Pero vamos a pasar información del modificador. Las otras partes del objeto de evento que queremos simular, en este caso, shift siendo verdadero. Esto es algo así como el equivalente moral de 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 que obtuviéramos esa interacción más rica. Y cuando lo hicimos, mira eso, nuestra prueba pasó ya porque ya hicimos esta implementación en nuestro manejador de eventos. Me gustaría señalar, estoy testing el contador incremental a través del renderizado. Podría venir aquí y escribir una prueba que llama al contador incremental y luego mira el estado para ver si se incrementó. Y podría simular un objeto de evento que pasé. Y se sentiría muy parecido a las pruebas normales de JavaScript testing, no del tipo de cosas de componentes renderizados en el DOM. Y esas pruebas, son más rápidas y fallan de una manera más razonable.

Muy bien, es un punto interesante sobre la extracción en hooks personalizados y pruebas más fáciles. Algunas de las cosas que estamos haciendo en esta masterclass hacen un poco de trabajo extra ahora para darte un nivel de granularidad que es fácil de probar solo esa cosa, fácil de modificar y refactorizar en el futuro. Y ese es un buen ejemplo, Andre, de hacer un poco de trabajo extra ahora para crear un hook personalizado. Porque entonces puedo simplemente probar esa maldita cosa y está empaquetado un conjunto de decisiones y el mundo exterior no tiene que saber nada al respecto. Usualmente hacemos eso para componentes con componentes hijos. Es genial hacer eso también con el estado para que pequeñas partes de tu estado global puedan ser tratadas lógicamente de manera diferente.

OK, estamos llegando al final, el último paso en el tutorial. Antes de hacerlo, haré una pausa por un momento y veremos si tenemos alguna pregunta o comentario. Muy bien, continuaremos. Lo que vamos a hacer en este paso es refactorizar esto para ser la forma en que se supone que debes hacerlo para componentes de presentación, componentes hijos, o componentes contenedores y componentes DOM. Y lo que queremos es que el contador se vuelva mucho más tonto. No debería llevar la cuenta de su estado, y realmente no debería tener la lógica sobre qué hacer en el evento. El padre debería hacer eso y pasarlo y hacerlo disponible para el 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 la información de TypeScript.

OK, comenzaremos con el estado del contador. Vamos a eliminar el estado del componente contador, y si vamos a eliminar el estado del contador componente, probablemente vamos a querer convertirlo de nuevo en un componente funcional. Así que vamos a empezar haciendo que esto sea las props donde elimino la cuenta ya que pasar un punto de inicio no importará más ya que no está llevando la cuenta. Así que vendré a mi contador y aquí, el inicio lo eliminaré. Y luego voy a cambiar el componente contador mismo para ser un componente funcional. Voy a dejar en esto sobre el estado inicial ahora porque voy a tener que poner eso en otro lugar más tarde y debería tenerlo cerca para poder razonar sobre ello. Y veamos. Oh, no. Necesito agregar la cuenta. Eso es correcto. Mira, me salió un subrayado rojo. La cuenta es ahora una prop, que está siendo administrada por mi padre y me la pasa. Y a medida que cambia en el padre, yo la recibiré de nuevo como una prop y se volverá a renderizar y todas esas cosas. Muy bien, Jun, estoy interesado en tu pensamiento sobre eso. Pero ya sabes, SFC era componente funcional sin estado. 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 un estado local. Me pregunto si la gente está en desacuerdo conmigo sobre eso. Así que ahora nuestro contador es un componente de presentación DOM sin estado, y podemos eliminar la importación de componente o usar el IDE para limpiar en IOWN 5 y deshacerme de él. De hecho, estos días podemos creo que deshacernos de eso, pero lo dejaré porque fue generado por create React app. Arreglemos las dos primeras pruebas y el contador para ver si estamos en el rango y si podemos pasar un punto de inicio. Así que solo cortaré y pegaré estos. Mi prueba se va a ensuciar un poco a medida que hago la refactorización en esto porque estoy cambiando el contrato radicalmente. ¿Pasaron estas dos pruebas? Realmente no me preocupo por las otras dos. OK, estas dos pruebas sí pasaron. Así que estoy en buena forma. Estoy en el rango. El componente contador ya no controla el valor inicial por lo que estas dos pruebas, sobre empezar en este lugar, empezar en otro lugar, podemos eliminarlas. Así que digamos que eso pasa. Debería empezar en otro valor y debería empezar en 0, vamos a eliminar esas dos pruebas. Estas sobre el disparo de eventos nos gustaría mantenerlas. Ahora, queremos, en lugar de que el contador maneje la lógica sobre el clic, queremos que el padre maneje la lógica sobre el clic. Así que voy a poner esta mala jama en la definición de props, y luego la explicaré. Podría ser más fácil aquí. Estoy pasando una función ahora, una función que esperará un primer argumento, o debería parecerse a incrementar contador, ¿verdad? Pasar en 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, solo va a operar en el estado. Así que lo que vemos es que tenemos la etiqueta que entró como una prop. Tenemos la cuenta actual que entra como una prop. Y tenemos un manejador de clics, que entra como una prop. Las tres y su información de tipo se expresan en esta definición de tipo. Eso es un punto interesante sobre si la hookificación ha hecho que la gente reconsidere la presentación en la especie de cosa de componente DOM padre-hijo. No he visto ese meme aún, pero no he ido a un boot camp recientemente. Y ha pasado un tiempo desde que escribí esto. Creo que este tutorial precedió a los hooks. Ahora, nuestras pruebas, sin embargo, tenemos problemas de compilador en nuestras pruebas porque tenemos un contrato que está roto.

Se requiere la cuenta, y se requiere el incremento del contador. Entonces, lo que necesito es, déjame ver. Las dos primeras pasan, y las dos segundas fallan. Así que vamos a arreglar estas dos pruebas porque realmente no estamos testing el manejo de clics en este momento. No nos importa el clic. Solo necesita haber algo allí. Vamos a hacer un falso manejador de clics. Y lo vamos a pasar, junto con una cuenta inicial, como las dos props que actualmente están al máximo. Eso es lo que nos falta actualmente. Así que ahora TypeScript está contento con eso. Veamos. Solo cortaré y pegaré todo. Creo que tengo algo extraño porque... Oh, no. Lo siento. Se supone que debo estar arreglando el de arriba. Sí. Estos son los que las pruebas están pasando, pero es TypeScript el que está enfadado. Así que lo que haré es volver atrás y hacer esto de nuevo. TypeScript está enfadado porque estoy pasando cuenta pero no estoy pasando un manejador. Hagamos un simulacro. Y luego puedo usar eso como el. Manejador y ahora TypeScript está contento con eso. Haré lo mismo aquí. Y así las pruebas se ejecutarán. Y estas dos pruebas pasan de nuevo y no tienen ningún problema con TypeScript. Déjame ver qué dice Alexey sobre que lo hace difícil. Alexey, cuando dices que definitivamente hace más difícil probar los componentes de React, ¿qué forma lo hace más difícil? ¿Los hooks, la nueva forma o la antigua forma de presentación de pruebas? Bien. Lo tengo. OK, así que 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 terminaremos. El manejo de eventos es un poco más complicado porque seguro, has terminado. 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 fue llamada correctamente. Así que lo que vamos a hacer en este caso es cambiar la tercera prueba. Vamos a eliminar la última prueba. Vamos a hacer un manejador. Lo vamos a pasar. Vamos a hacer el clic. Y luego esta cosa del manejador, vamos a poder llamar a una afirmación en ella. Para asegurarnos de que fue llamada, ¿mi componente llamó a la función cuando fue clicado? Concepto bastante inteligente y fácil del contrato. Pero, ¿cómo escribo una prueba para ello así? Hago un simulacro. Uso ese simulacro o espía es la cosa que se pasa al componente DOM. Hago todo el trabajo y luego lo miro y digo, hey, espía, ¿te llamaron correctamente? Eso es realmente fácil. Y cuando se combina con el evento de fuego y el evento de usuario y cosas así, es una forma realmente agradable, ¿cómo más lo harías? 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 podría ser movido tal vez un poco al hijo. Lo que tenemos ahora es el encuentro la función de incremento pasa todo el evento. Pero sabemos que al hijo no le importa todo el evento. Solo está interesado en shift. Click. Así que vamos a decir, oye, llámame con un argumento sobre si se presionó shift. Así que 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 luego eso será el manejador 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, así que tengo esta función de manejo de clics que está haciendo eso. Luego podemos volver al contenedor componente, lo siento, la prueba ahora está escrita para poder mirar solo esa cosa sobre falso. Porque eso era lo que tenía el manejador. Y luego, solo para terminar un poco, podemos subir al componente padre componente. Dije que íbamos a dejar estas líneas en el contador. Eso es para que podamos copiarlas y pegarlas en el padre donde está el contrato. Y 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 el todo. Me gustó, esta es la cosa que llama el hijo, y se va a pasar de nuevo. La información de shift, que luego usamos. No tenemos que analizar un evento. Así que pasando por todo esto, podemos escribir pruebas que hacen todo para el estado de la aplicación que incluye algunos clics en el componente contador. Ahora, comenzaré el proceso de terminar, tomando 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. En la aplicación en el navegador, pudimos hacer todo este trabajo, ya sea renderizado, ya sea props, ya sea estado, ya sean manejadores de eventos, todas estas cosas pudimos hacer, manteniéndonos en nuestras herramientas, manteniéndonos en el flujo, siendo capaces de debug, obteniendo buenos hechos de rastreo, capacidad de clic, refactorización todas estas otras cosas y esa capacidad de mantenerse en el flujo y trabajar metódicamente y no sentir que estás 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 está funcionando correctamente, pero debido a las pruebas, también puedes concentrarte en el problema. Así que me detendré allí por un momento. Vamos a terminar cualquier entrada, cualquier pregunta, cualquier comentario, cualquier observación sobre tus sentimientos acerca de testing, tal vez incluso sobre TypeScript también. Así que miraré algunos de los comentarios en en el chat. Tendré que estar atento al impacto de los hooks en la forma en que la gente está dividiendo los componentes y sobre la escritura de pruebas y cosas así. Así que, June, gracias por mencionarlo. Alexei, el TypeScript en los últimos dos años. Tienes razón, sigo el Roadmap de TypeScript.

Hacen un gran trabajo dirigiendo ese proyecto y hacen un gran trabajo manteniendo su hoja de ruta actualizada. Y a veces tienen un punto sobre, sabes, lo que viene o lo que acaba de implementarse. Y están usando palabras que no entiendo porque ahora están realmente interesados en la teoría de tipos. Realmente están intentando mover grandes partes. Un desarrollo de framework puede ser expresado en información de tipos. TypeScript es malvado. Y desafortunadamente, la licencia para WebSR y la licencia para IntelliJ son separadas, pero tenemos algo llamado el paquete de todos los productos, que te permite acceder a todos nuestros IDs.

Y Alexa, tu punto sobre no salir del IDE. ¿Sientes que esta es una forma de desarrollo que te gustaría? Cuando puedo tener la disciplina para permanecer en este modo, es simplemente tan tranquilo. No me siento frenético. Quizás no sea la forma correcta de decirlo.

Sí. Bueno, gracias, Dylan. Lo aprecio. Quizás un día vea una presentación tuya y aprenderé algunas cosas de ti. Bien. Creo que estos son la mayoría de los comentarios. June, lo que realmente estás diciendo es, la cosa que me metió en esto es... No lo sé. Quizás solo sea yo.