Lecciones para sobrevivir a React

Hola, Cumbre de React. Estoy aquí para ofrecer siete lecciones para sobrevivir a React. Entonces, la premisa de esta charla es que React es más antiguo que jQuery cuando React fue lanzado por primera vez. Y jQuery no está muerto. Todavía alimenta una gran cantidad de Internet, pero ya no es tan genial como antes. Y ese destino también llegará para React algún día. Deberíamos tratar de pensar en lo que durará más allá de React.

Entonces, mientras miramos a React en su ascenso y entrando en su fase muy madura, deberíamos pensar en qué lecciones aprendemos de este enorme éxito. Hola, soy swix. Trabajo en muchas cosas diferentes. Y hago mucho en la comunidad de React. Pero principalmente doy charlas sobre React, que es la calificación más relevante para esta conferencia. Y muchas de estas charlas se centran en elementos individuales de React. Pero esta es la primera charla que realmente cubre la filosofía general, que creo que puede llevarse de eso. Si desea profundizar en detalles individuales, estas charlas son realmente buenas para cubrir sobre cubrir las bases técnicas de las que extraigo muchos de estos principios.

Entonces, las siete lecciones de antemano se presentan aquí. Hablaremos sobre el reconciliador, el área de superficie de la API, el diseño de la API, la optimización para el cambio, las pruebas, las herramientas de desarrollo y la comunidad. Entonces, la primera parte es que el patrón de reconciliador y programador es probablemente una muy buena idea para un montón de trabajos diferentes. Y esto en realidad proviene de Jordan Walk, que es su visión original. Que sea lo que sea que tu programa produzca, píxeles, archivos, cualquier cosa, simplemente haz que tu programa regenere todo cada vez, agrega almacenamiento en caché y compartición estructural para hacerlo rápido y eso es todo. Y obviamente eso es gran parte del discurso original, que capturé del original charla de JSConf. Y esa es la forma en que React se diferenció desde el principio.

Pero tal vez también esté pasando por alto el otro MVP de React, que es la programación. ¿Verdad? Que es la otra parte. Y estamos viendo mucha innovación ahora, cuando cambias de viejo React a modo concurrente de React, empiezas a obtener los beneficios del rebanado de tiempo, del cual se habla mucho. Si desea una introducción más detallada a la programación en React, definitivamente consulte la publicación de blog de Philips Spice, que presenté aquí. Este programador en realidad está empezando a ver implicaciones más allá de React. Entonces, el equipo central de React en realidad dividió el paquete del programador en su propio paquete con la esperanza de que otros frameworks puedan usarlo. Y están trabajando en el equipo de desarrollo de Chrome, eso debería ser del equipo de desarrollo de Chrome, para tal vez incorporarlo a su navegador. Entonces, si quieres que React se integre en el navegador, este es el comienzo.

Pero en general, creo que esto encapsula la idea de un mullet DX UX. Ese es mi término para ello. Donde tienes el modo inmediato en el frente y el modo retenido en la parte trasera. Modo inmediato, simplemente vuelve a renderizar todo cada vez tanto para el frontend, el usuario, como para el desarrollador. Y el modo retenido, que es el sistema en el medio que realmente conserva el estado. Y esto es realmente cierto para los sistemas de construcción. Entonces, Jared Palmer está trabajando en un sistema de construcción donde tiene exactamente el mismo patrón. Y empieza a ver este patrón una y otra vez en GraphQL, en las tuberías ETL y Nullify. Y muchos otros aspectos diferentes de la vida donde tienes a un desarrollador trabajando con un sistema y quieres que sea rápido, pero también fácil de razonar.

Bien. Segunda lección. Área mínima de la API. Esta, por supuesto, proviene de la charla seminal de Sebastian Markburger que realmente expone esta filosofía. Y básicamente, basado en su experiencia trabajando con herramientas Mood, dice que muchos patrones de biblioteca son simplemente demasiado grandes. Es simplemente demasiada API y no van a durar y es realmente difícil de deshacer una vez que has creado esa API. Así que su solución es simplemente no intentarlo en primer lugar. Y prefieres una API explícita y repetitiva en lugar de una implícita.

El compromiso, por supuesto, es que tendremos mucho más... ¡Spoiler! Plato. Ves muchos de estos ejemplos en cómo crece React con el tiempo. React ha eliminado voluntariamente su propio formato de clase propietario para las clases ES6. Puedes ver realmente que el diseño de React usa... Como, por ejemplo, con los hooks, donde puedes ver los hooks de terceros, como los hooks definidos por el usuario, están al mismo nivel que los hooks centrales de primer nivel. Y ese es un concepto que proviene de la charla de Guy Steele Growing a Language, que recomiendo encarecidamente. Y puedes ver que React intenta colapsar las API. Tendrán estas tres API de clase de componente muy comunes, y las colapsarán en GDSFP, y luego también escribirán una entrada de blog para recordarte que es posible que no la necesites, especialmente si usas funciones. Así que cada vez menos API con el tiempo, y realmente aprecio al equipo central de React por eso. Pero hay un costo, que es que renuncias... No hay solución de enrutamiento, no hay solución de gestión de estado, no hay estilo, y todo eso que viene con React. Y estas son cosas que otros marcos dan por sentado, y con las que los desarrolladores de React luchan. Así que hay un costo para eso. Comentaremos sobre eso en una futura lección.

Pero la lección número tres es que el diseño de la API es el diseño del lenguaje. Y esto es muy similar al punto anterior, pero distinto. Y el punto en esto, y el énfasis aquí es la denominación, y la forma en que la gente habla sobre React. Así que Lee Byron en realidad tuvo una gran contribución a esto, incluso antes de que co-fundara GraphQL. Al sentarse y realmente definir los conceptos, las acciones, los operandos y las notificaciones, puedes ver el resultado de eso en las elecciones de diseño de la API de React. Y estos son los que nos son familiares. Pero han cambiado mucho con el tiempo.

Pero todavía hay una gramática que se ha establecido que podemos esperar y recomendar. Y tiene sentido para nosotros como desarrolladores de React. Nos ayuda a pensar en React basado en el lenguaje. Y eso es una parte muy importante de esta hipótesis de aparecer-valioso, que es que la denominación realmente ayuda a moldear nuestro pensamiento. Las palabras que usamos ayudan a moldear nuestro pensamiento.

También puedes ver esto en los hooks. La forma en que se usa lo que sea es una sintaxis de denominación muy común para los hooks. O la sintaxis de denominación recomendada para los hooks. Y solo el nombre de los hooks en sí. Estos son los otros 50 nombres que se consideraron para los hooks antes de que se decidieran por hooks. Y en parte, es con la consideración de que, sí, quieres algo que sea de una sílaba, para que puedas referirte a ello en la conversación diaria. Pero también es una API que los humanos usan en lugar de las computadoras. Y en general, creo que tal vez Dan lo expresó mejor. Dice UI antes que API. Quieres empezar con el resultado final, y luego trabajas hacia atrás para crear las API que te ayuden a llegar allí. Pero su otro principio es realmente interesante también. Hacks y luego idiomas. Lo que significa que está dispuesto a dejar que los usuarios hackeen lo que sea que tengas, en lugar de construir una API extra solo para acomodarlos.

Y aquí, es muy claro lo que es, si eres de una cierta generación en React, donde tienes muchos componentes de envoltura solo para inyectar algo con redux o GraphQL. Y esta pirámide del destino, me encanta agregar un poco de Hadoop allí, solo para simbolizar lo profundo que realmente va. Hay muchas soluciones que intentan resolver esto. Hay muchas soluciones que resultan en esto, y simplemente no tienes opción porque React realmente no te dio otra forma. Entonces, si querías inyectar estado, necesitabas un componente de orden superior. Hubo una breve revolución para las props de renderizado, de nuevo, de las mismas personas que recomendaban componentes de orden superior. Intentando resolver este gran problema de la pirámide del destino, introduje un RFC de React llamado React.headless component. Y todas estas fueron solo formas de inyectar comportamiento, que simplemente no eran realmente correctas. Y todos nos dimos cuenta de que los hooks eran simplemente una opción mucho mejor hacia el final.

La lección número cuatro es optimizar para el cambio. Entonces, este es el punto final sobre el diseño de la API, que es que no deberías optimizar para, ya sabes, no te repitas, o no deberías optimizar para líneas mínimas de código. Optimiza para el cambio, y aquí está el por qué.

Entonces, el primer orden de design es que tu code debería ser fácil de leer y escribir. Deberías tener todas estas características. Realmente me gusta la del pozo del éxito. Se dice comúnmente que quieres hacer que lo correcto sea lo fácil. Quieres ser memorable, como Lee Byron haciendo la gramática para React. Eso es muy memorable. Necesitas ser adivinable. Ese es un muy buen consejo de Jon O'tander. Y también quieres fomentar el performance, la accessibility, la seguridad y la user experience. Todos estos son, ya sabes, igualmente importantes. No hagas juicios de valor sobre cuál es más importante. Pero una vez que has escrito la cosa, entonces los requisitos comienzan a cambiar. Y ahí es donde entra el diseño de segundo orden. También quieres que sea fácil de cambiar. Entonces, si tienes un código muy frágil, entonces un ligero cambio en los requisitos hará que tu código se desmorone. Entonces, el gran diseño de API realmente anticipa que querrás renombrar o copiar y pegar, unificar en abstracción o descomponer en abstracción, eliminar o añadir un hack. Hacer todo tipo de cosas a tu código, y necesita no desmoronarse cuando intentas hacer eso. Entonces, una gran API no solo te permite caer en un pozo de éxito, sino que te ayuda a permanecer allí. Y eso es una observación realmente, realmente buena. Y eso es algo que ves mucho en otros formatos. Entonces, dos referencias a las que me gustaría señalar si quieres investigar más sobre esto, es el blog de Stack Overflow, donde llaman a esto volatilidad de requisitos, así como Hillel Wain, que llama a esto perturbaciones de requisitos. Misma idea, diferentes enfoques. La solución del equipo de React para resolver esto es habilitar el razonamiento local, para tratar de reducir tanto contexto global como sea necesario, y simplemente enfocarte en el código frente a ti, y eso debería permitirte cambiar lo que necesites. Porque entonces en realidad no tienes que tener acción espeluznante a distancia. Ves esto en las publicaciones de blog de Dan, en Sophie Alpert blogueando sobre Data Loader. Puedes ver esto en Style Components, Tailwind, o el diseño del compilador Relay. Hay muchas formas diferentes en las que puedes habilitar el razonamiento local que ayuda a optimizar las cosas para el cambio.

Tengo muchas más diapositivas que estas. Tuve que recortar porque no tengo tiempo, pero no dudes en contactarme porque optimizar para el cambio es una idea fundamentalmente muy importante que durará mucho, mucho más tiempo que React.

Bueno, lección número cinco, prueba la API pública. Muy, muy simple. Deberías escribir pruebas, no demasiadas, principalmente de integración. No pruebes detalles de implementación. Esto es obviamente muy, muy importante para React porque React emprendió una gran reescritura de todo el código base, pero mantuvo las pruebas y las pruebas realmente sobrevivieron al código base, y eso no es algo que sea muy revelador para tus aplicaciones. Obviamente, también implementaron este pequeño rastreador para IsFiberReadyYet, donde realmente rastrearon la finalización hacia la reescritura. Y es solo una cosa realmente motivadora de ver para el código base de React, que en realidad se ha extendido como un movimiento hacia las aplicaciones de React, ¿verdad? Así que hemos visto que la enzima está relativamente en declive en comparación con la Biblioteca de Pruebas de React, y eso es como debería ser, porque nuestra Biblioteca de Pruebas de React tiene este enfoque en probar solo la API pública de los componentes. Y eso es lo que tus usuarios usarán, y eso es lo único que realmente deberías cuidar en tus pruebas. Y lo hace mucho menos frágil en comparación con lo que había antes. OK, lección número seis. Pasamos a DevTools. DevTools no son opcionales, y puedes ver cuánto enfatiza React DevTools. Entonces, por supuesto, los DevTools oficiales de React, el complemento de Chrome, es mantenido por Brian Vaughan en el equipo central de React, y hace un trabajo increíble. Como, no sé cuánto pagaría por esto, pero pagaría por esto. Y deberías aprender todas las complejidades si quieres depurar. React también utiliza Codemods. Esto no es opcional para React básicamente porque el equipo de React en realidad tiene que mantener las decenas de miles de componentes que están en el código base de Facebook, y tienes que actualizar todos ellos cada vez que cambian las API, así que, por supuesto, tienes que automatizar estas cosas. Y nosotros, como la comunidad de React, nos beneficiamos. Las advertencias de desarrollo de React es algo que realmente se lleva al límite con React. Así que puedes ver la superposición de errores de React, o puedes ver advertencias de lint, o puedes verlo en la consola. Incluso tenemos códigos de error, por lo que puedes ver errores agradables en producción, pero no tener peso extra en los artefactos de construcción finales, y es una experiencia de decodificador muy agradable, que desearía que más herramientas de desarrollo copiaran. No puedes automatizar todo, así que es bueno introducir algunos fixtures. Realmente me gusta esto como una forma de aprender React también, porque puedes comenzar a activar banderas de características y cambiar diferentes navegadores y ver cómo cambia el comportamiento. Es solo una forma muy agradable de probar cosas manualmente al tener todo en su lugar para que no pierdas tiempo configurándolo. Y finalmente, el último consejo es una especie de meta-consejo. DevTools para ayudarte a construir DevTools. Para React, porque está construyendo una biblioteca que se incrustará en millones de otras aplicaciones, necesitan mantener el tamaño del paquete pequeño y nunca aumentarlo involuntariamente, y es algo que podemos tomar prestado para nuestras aplicaciones también. Deberíamos ser conscientes de lo que estamos construyendo y enviando y deberíamos ser conscientes de las grandes regresiones.

Entonces, las DevTools no son opcionales. La última lección es que no debemos descuidar la comunidad. También queremos construir una comunidad. Esto obviamente se remonta al principio de la apertura del código de React. De hecho, Jordan Walk tuvo que introducir JSX porque estaba siendo ignorado internamente dentro de Facebook. Y una vez que introdujo JSX, les gustó mucho más. Pero luego, sucedió exactamente lo contrario cuando lo abrieron al público. Este es Jordan durante los faros tratando de introducir JSX a una muy mala recepción, y aquí está Pete Hunt tratando de rescatarlo diciendo, hey, es opcional, chicos, no se preocupen tanto. Y creo que finalmente nos acostumbramos a la idea. Pero el núcleo de esto es que todo el primer equipo central realmente escuchó los comentarios. Estaban en IRC en Stackoverflow 24-7, y respondieron a cada crítica viéndolas como su culpa. Y ese trabajo en la comunidad dio sus frutos. Comenzaron a atraer a muchos usuarios, en particular a David Nolan de la comunidad ClojureScript que construyó Omen, realmente comenzó a promocionar React bastante. Y creo que es mucho trabajo que tal vez se olvida con el tiempo. Pero creo que si estamos empezando a crear nuestros propios proyectos que queremos que sean tan populares como React, necesitamos empezar a prestar atención a la comunidad tal como lo hicieron. Y esa es una lección que llevamos con nosotros.

Además, necesitamos empezar a resolver puntos de dolor. Entonces, uno de los grandes puntos de dolor era que React es tan pequeño que no resuelve el resto de las otras aplicaciones y la gente empezó a hacer memes y bromas al respecto. Entonces, Dan Abramov realmente fue y creó Create React App. Y esa es una historia que cuento en una charla separada llamada Create React App.

Pero en general, la historia de esto es básicamente que es una distribución de React, ¿verdad? Empaquetas React con otras cosas, Next.js y Gatsby lo empaquetan con enrutamiento y Blitz y Redwood empaquetan Next.js y así sucesivamente. Puedes empaquetar y empaquetar y empaquetar. Y lo que realmente estamos viendo aquí es un enfriamiento en la destrucción creativa de los marcos de trabajo y la maduración y despliegue de React y estamos empezando a construir encima de React en lugar de tratar de competir con React. Y lo principal que React, el contrato para React empieza a cambiar, ¿verdad? Ahora lo principal que cambia React, no son las características. Es la estabilidad. Por supuesto, la curva S no es un fin. Puede empezar a ser S de nuevo cuando concurrentemente React está completamente fuera.

Entonces las siete lecciones que cubrimos son todas estas. Creo que va a ser un poco difícil de recordar si eres siete. Ya sabes, la memoria de trabajo es solo de tres a cinco. Así que aquí está mi desglose. Primero, tienes una idea central de lo que tu biblioteca o marco de trabajo va a hacer. Luego quieres trabajar en la interfaz entre el desarrollador y tu biblioteca central. Así que ese es tu diseño de API. Luego quieres producirlo, ya sabes, trabajando en las pruebas, trabajando en las herramientas de desarrollo. Y finalmente, quieres humanizarlo para asegurarte de encontrarte con las personas donde están. Y esas son las siete lecciones. Eso no son las únicas siete lecciones que puedes aprender de React. Y hay más en camino. El equipo de React es muy generoso en compartir sus lecciones sobre concurrente React. Y deberías prestar atención a esas. Pero en general, la lección de metal que quiero dejarte es que deberías enamorarte de los problemas porque las soluciones van y vienen, pero los problemas siempre permanecerán. Eso es todo. Si quieres aprender más sobre estos principios, que creo que durarán toda nuestra carrera, deberías consultar mi libro en learningpublic.org. Pero de lo contrario, muchas gracias por tenerme y nos vemos en el resto de las charlas. Adiós.

Parece que la mayoría de las personas dicen área de superficie de la API mínima y optimizan para el cambio. Obtenemos muchos empates en estos, como 36%, 36%. Así que dividido por la mitad, ¿era eso lo que esperabas de esta pregunta? ¿El área de superficie de la API? Creo que sí. Creo que se ajusta a lo que la gente responde muy bien. Sí. Genial. Asombroso.

Bueno, tenemos un montón de preguntas para ti, pero quería empezar con una. Y eso es, ¿qué estás haciendo ahora? Así que en tu introducción, estaba como, eras un defensor senior de desarrolladores para AWS, pero sé que te has movido porque ese es el equipo en el que estoy. Entonces, ¿qué pasa? ¿Qué estás haciendo ahora? Oh, te pusieron a cargo y tuve que irme. Eso es una broma, todos. Se fue antes de que me convirtiera en el gerente. No. Sí, por supuesto. No, realmente. De todos modos, sí, acabo de unirme a temporal.io. Es una startup de orquestación de microservicios de back end. Muy, muy diferente a lo que normalmente hago. Y quería, supongo, ampliar. Pero también apostar por una pequeña empresa. Ya sabes, donde es la Serie A, muy temprano y esperando ser la próxima gran, supongo, ya sabes, startup de orquestación de back end. Y si alguna vez has trabajado en tareas de larga duración como, ya sabes, como sagas para el back end, esto es algo que realmente deberías revisar. Pero no voy a promocionarlo en una conferencia de React. Así que tuve que idear una charla diferente para esta. No, eso es genial. Eso es realmente, realmente genial. Tenemos más preguntas también. Esta es de Juan Segebre. ¿Cuáles son las trampas comunes y mentalidades que nos evitan optimizar para el cambio? ¿Eso evita? Lo siento. Supongo que es ¿nos ayuda a optimizar para el cambio? ¿O que nos hace evitar el cambio? Uno de los dos.

Porque se supone que eso es bueno. No estamos tratando de evitarlo. Espera. Estoy pegando mis diapositivas y mis enlaces en el Discord. Ahí es donde los tengo. Y no sé si hay otros canales donde debería publicarlo. Pero si alguien quiere seguir todas las recursos que pegué, puede seguir allí.

Pero, sí, esencialmente hay tanto, ¿verdad? Creo que simplemente pensando en tu design al pensar en qué cambios podrían llegar y arruinar tu día es esencialmente la idea. Y por lo tanto, puede ser tan pequeño como cosas como depender del orden de los argumentos. Entonces, si te das cuenta en React, las props realmente no les importa el orden de los argumentos. Y eso es porque básicamente es un objeto de opciones. Que es algo que si miras una de mis charlas favoritas, Simple Made Easy de Rich Hickey, depender del orden de algo es en realidad complejidad. Realmente te hace necesitar recordar, ¿qué viene después de qué? Mientras que si pones las cosas en orden independiente, te liberas. Pero luego se vuelve tan grande como si estás co-localizando data y facilitando las cosas para eliminar. ¿Verdad? Porque el código solo de anexar es una fuente importante de deuda técnica. Si tienes miedo de eliminar cosas porque no sabes qué efectos globales va a tener, entonces tienes esencialmente lo que llamo momificación de tentáculos. Porque estás poniendo vendaje tras vendaje tras vendaje y terminas con una momia de deuda técnica. Y sí, hay muchas formas de optimizar para el cambio y planeo escribir un artículo más grande sobre esto en el futuro, pero quería meterlo allí.

Eso es impresionante. Y la gente definitivamente debería seguirte en las redes sociales para ver todas tus entradas de blog porque es tan, tan impresionante cómo escribes sobre las cosas. Y sacas artículos y ves un tema un par de veces y escribes sobre él. Y creo que eso es impresionante. Sí, lo llamo la regla de los tres golpes. Creo que la gente tiene una barrera hacia cuándo deberían escribir sobre algo porque sienten que necesitan ser un experto en ello para escribir sobre ello. O tienen lo contrario completo. Sacan cada pensamiento despierto. Y esos dos extremos no son muy ideales, ¿verdad? Porque estás publicando demasiado o estás publicando muy poco. Entonces, mi regla de los tres golpes es que una vez que te has referido a una idea tres veces, deberías intentar y escribir un blog sobre ello. Porque eso ha permanecido el tiempo suficiente para demostrar que probablemente va a permanecer un poco más en tu mente. Pero no es demasiado tiempo que te has aburrido con

Eres un escritor muy pulido. Y creo que eso es algo que tenemos que entender como creadores de contenido. Tu blog transmite una expectativa de la cantidad de trabajo que se invierte en él. Y ahora, creo que si te desvías de eso, la gente se sentiría un poco... incómoda con ello. Así que, creo que necesitas encontrar un medio diferente donde puedas experimentar más y donde la gente no espere que tengas ese nivel de pulido. Así que, soy fan de usar diferentes medios para diferentes propósitos. Oh, me encanta eso. Me encanta eso. Me estás dando todos los advice aquí. Me encanta la idea del jardín digital también. La gente parece realmente interesada en eso especialmente en la community de egghead. Así que, debería profundizar más en eso. Ya publicaste todos tus recursos, lo cual es increíble. Esa era nuestra siguiente pregunta. Luego la siguiente es de Sasha. ¿Hay algún framework específico nuevo y mejorado basado en estas lecciones en el que preveas que podría reemplazar a React en el futuro? Wow. No quería ir allí pero realmente me gusta Svelte. Vamos a tener una masterclass en dos semanas. Así que puedes venir a ver Svelte Summit. Está en YouTube. Creo que es general para open source. Si estás trabajando en marketing de desarrollo o empezando un proyecto de open source o quieres apostar temprano en open source, estas son las cosas a tener en cuenta. Estas siete lecciones no son las únicas lecciones y estoy interesado en que otras personas entiendan lo que pueden aprender de React. React es uno de los frameworks de open source más exitosos del mundo. Todo el mundo está interesado en replicar

Eso es genial. Y es la tesis de pregrado más impactante. Como que no recuerdo mi propia tesis de pregrado . Recuerdo la mía. Escribí un montón de tweets y todo era sobre cómo la gente discute sobre diferentes políticos en las redes sociales, pero sí, eso es una visión super, super interesante, pero sí, HyperApp. Está escrito en JavaScript, pero tiene la architecture de Elm. Me gusta mucho porque es ligero. Me gusta la architecture de Elm, pero encuentro que el lenguaje de programación es un poco difícil de usar, así que no sé. Eso es divertido.

Esta es de Katre. ¿Cómo se llega a un buen sistema de nombres cuando eso no es tu fuerte? ¿Cuánto tiempo se debe dedicar a eso? Tengo una publicación de blog sobre cómo nombrar las cosas. He intentado responder a esta pregunta porque es uno de los problemas conocidos difíciles. Deberíamos tener cierta perspectiva sobre la nomenclatura de las cosas. Si dices que simplemente no eres bueno en eso y no lo intentas, entonces básicamente te estás rindiendo antes de empezar. No creo que sea una forma muy productiva de manejar las cosas porque vas a tener que nombrar las cosas. Eso es mucho de lo que hacemos como parte de Coders. No sé. ¿Cuál era la pregunta de nuevo? ¿La respondí? Muchas de mis respuestas son simplemente como tengo una publicación de blog para eso. Y esa es una buena forma de vivir porque es un buen aprovechamiento del tiempo porque paso horas en esa cosa. No voy a dar en esta pequeña charla. Si a la gente le interesa realmente, puede buscarlo. Sí. Es casi como tu segunda fuga cerebral. No tienes que recordar todas estas cosas porque

Eso es increíble. Esos son grandes consejos de advice. Muchas gracias. Ha sido divertido ponerse al día y también escuchar tus advice y tu charla. Genial. Sí. Muchas gracias por invitarme y nos vemos a todos en el chat.