Las Cosas Raras de React

Así que buenos días a todos. Vamos a entrar en materia. Hablemos de las cosas extrañas sobre React. Y gracias al comité roto por permitirme alienaros justo por la mañana y hacer que lamentéis vuestras decisiones de vida.

Pero antes de hacer eso, brevemente sobre mí, soy Nick Graf. Trabajo en Serenity con un equipo de tres o cuatro. Está cifrado, también soy tutor, y dependiendo de quién pregunte, soy consultor o freelancer. Y continuemos conmigo.

Mi viaje con React en realidad comenzó con la versión 0.12, o 0.13, y en ese momento todo era realmente, realmente impresionante. JavaScript no tenía clases, así que solo teníamos la función, crear clase en React, y era bastante bueno. Y luego llegó la 0.14, y entonces ocurrió la primera cosa, y yo estaba como, eso es una señal de advertencia ¿qué está pasando? ¿Qué, 15 ahora? ¿Por qué no 1.0? Y sabían que habían hecho algo extraño aquí, porque publicaron este post de blog realmente largo explicando por qué estaban haciendo esto, cómo funciona Semware, pero que lo estaban haciendo un poco diferente y demás. Y así, o esto es arrepentimiento, o dedicación, o compromiso. Y para mí, no me importaba. Sentí que, bueno, al menos lo saben, son conscientes, esto es suficiente para mí, y el mundo siguió adelante. Tuvimos 16, 17, 18, y las cosas estaban bien, de nuevo.

Y lo que realmente me gusta de React es que tienes React.js.org, la documentación, pero todos los detalles técnicos, todo el pensamiento detrás de ello lo puedes encontrar en los documentos no oficiales en Twitter.com. Es realmente genial. Sigue estos tres perfiles, y sabrás sobre el pensamiento, sobre el trasfondo, realmente querrás saber si estás usando React durante un tiempo prolongado. Permíteme darte un par de ejemplos. ¿Sabías que puedes usar el atributo key para básicamente volver a montar componentes? Así que si miras esto, es como una aplicación de componente muy simple. Pero lo que haces es, cuando haces clic en el botón, en realidad estás actualizando el ID. Así que por ejemplo, si esto pasa de ABC, una cadena, a GHI, lo que sucede es que en realidad estás volviendo a montar el componente. Y esto no aparece en ninguna parte en los documentos oficiales. Pero una vez que descubrí esto, fue fantástico porque sé que no deberías usar esto todo el tiempo, pero a veces es realmente, realmente útil. Si tienes a alguien que construyó un componente realmente malo que está usando useEffect completamente mal y no puedes arreglarlo. Puedes simplemente volver a montar el componente. Genial. Un truco muy bueno. Y no encontrarás esto en los documentos oficiales. En ninguna parte en absoluto.

Así que escribí una entrada de blog sobre ello y le dije a la gente, oye, no lo uses. Pero esta es como información interna que puedes aprovechar si realmente sabes de ella. Pero luego vas a Twitter.com y en realidad, Sebastian explica, este es un caso de uso completamente válido. Y es como, ¿por qué esto no está en ninguna parte en los docs oficiales? Me pareció extraño. Así que propuse, ¿por qué no están añadiendo esto a la documentation? Pero gracias a Dan, él realmente dijo que lo tendrá en cuenta para la reescritura. Así que todavía, no está allí en los docs beta, pero estoy buscándolo, que eventualmente vendrá. Con suerte.

Y eso me lleva a las otras cosas. ¿Quién de ustedes ha visto los nuevos docs beta? Excelente. ¿Quién de ustedes los ha leído desde el principio hasta el final? Bueno, realmente deberías. Son tan excelentes. Todavía puedes aprender algo allí. Cada vez que hay una nueva sección, como iría directamente a ella y la leería. Y realmente lo disfruto porque incluso como he estado haciendo React durante años y siento que soy un consultor. He visto mucho, ya sabes. Pero todavía aprendo algo allí. Y es genial. Así que si te llevas una cosa de hoy o al menos de esta masterclass, lee los docs. Es realmente, realmente bueno.

Les prometí más ejemplos. ¿No sabían que desde 2018 pueden devolver un render indefinido y devolver indefinido? Entonces, este es un componente válido. Y, bueno, eso fue en realidad una publicación oficial del blog, por lo que lo mencionaron, pero fue como cero menciones de por qué. Y yo estaba como que null era una gran decisión y realmente no quiero molestar a las personas que devuelven accidentalmente indefinido y luego tienes errores extraños. Y yo estaba como, vamos, ¿por qué está pasando esto? ¿Por qué este cambio ahora? ¿Por qué no hace un año? Y no tiene nada. Y aceptas en Twitter.com. Quiero decir, les llevó algún tiempo. Creo que fueron 15 días o algo así. Pero luego realmente publicaron una explicación en sus RFCs y esta es la segunda cosa. ¿Quién de ustedes sabe sobre los RFCs, esta nueva cosa de RFC de React? Levanta la mano. Vaya, no muchos. Lee esto. Esto es excelente. A veces se retrasa, como indefinido, les llevó un tiempo. Solo después de que la gente hizo muchas preguntas. Pero realmente explican el pensamiento y puedes proponer un RFC por ti mismo. Como si quisieras ver algo cambiado en React. Entonces, las charlas beta y los RFCs resuelven este problema de Twitter.com. Y no todo el problema de Twitter.com, pero al menos el problema de React con la charla no oficial problema. Vale.

Sigamos. Tema completamente diferente. Otra cosa extraña sobre React. Composición. La composición para mí comenzó, de nuevo mi historia. Mixins. Si alguno de ustedes ha visto Mixins. Esto fue como 0.12 o 13. Esto fue maravilloso, ya sabes. Tenías enlace de data bidireccional, porque todos veníamos de Angular en aquel entonces. Y entonces tienes que tener enlace de data bidireccional. Teníamos memo mucho antes de que jamás hayas visto memo. Y fue genial. Estábamos construyendo muchas cosas y los mixins eran buenos y podíamos componer lógica.

Pero entonces, ya sabes. Otra publicación de blog salió. Entonces, los mixins son considerados dañinos. Así que tienes dos opciones, o refactorizas tu base de código o renuncias a tu trabajo y sigues adelante. Sí. La gente hizo cosas diferentes. Entonces, ¿cómo componemos ahora? ¿Cómo manejamos la composición? Bueno, pasamos a los componentes de orden superior. Y yo estaba totalmente a favor. Yo estaba como, enseguida, en ese punto en este tren de hype con programación funcional y componentes de orden superior, era tan hermoso. Y podrías componer todo y era completamente inmantenible. Era como, era terrible. La cosa es - quiero decir, era bueno para la consultoría, ya sabes, muchos buenos ingresos, pero era como realmente enviar algo no era una buena idea. Entonces nos dimos cuenta, nah, esto es una mala idea. Twitter y él se unieron al equipo de React. Y entonces hizo este anuncio. Los componentes de orden superior son una mala idea.

Así que nos deshicimos de ellos. Bueno, casi. Todavía tenemos mem en forward ref. Desearía que forward ref no existiera, pero eso es otra historia. Y en este punto, sentía que era parte de un experimento. Como si constantemente tuviera que cambiar mi code base para hacer bien la composición. Y sí, encontré esto extraño. Y no se detuvo ahí. Obviamente.

Luego tuvimos render props y realmente los odiaba. Es como, quiero decir, todo este anidamiento sobre anidamiento sobre anidamiento, era horrible. Y nunca lo dije en voz alta. Bueno, tengo que decir eso. Pero, vaya, las render props fueron lo peor.

Entonces llegó nuestro salvador, los hooks. Y los hooks son geniales, porque son un concepto realmente extraño. Son funciones con estado para resolver nuestro problema con las clases no extensibles que teníamos antes. Y todo lo que podemos hacer es lógica de plantillas en nuestra lógica de negocio code. Es fantástico. Pero en realidad, estoy bien con los hooks. Los hooks son buenos. Tienen un conjunto de reglas claro con, como, solo deben usarse en un componente de React, no debería haber uso condicional. Pero al final, en realidad vuelves a Twitter de nuevo. Y te das cuenta de que puedes usar el contexto de manera condicional. Simplemente no te permitió usarlo desde ESLint. Pero básicamente funciona y no causará ningún problema. Puedes hacerlo. Probablemente todavía no sea la mejor idea. Pero todo es una mentira, ya sabes. Pero al final, creo que los hooks son realmente algo con lo que al menos me siento cómodo, y espero que estemos casi al final de toda esta historia de composición, pero el tiempo lo dirá.

Hablemos de algo completamente diferente de nuevo, otra cosa extraña, o llegamos a la cosa extraña. Me encantan las exportaciones nombradas. Son realmente geniales. Ya sabes, la experiencia de autocompletar en el editor, es fantástica. Y en un momento, hace un par de años, pude estar de acuerdo con todos los equipos con los que estaba trabajando, solo usamos exportaciones nombradas. Todos estaban a bordo, fue fantástico. Pero entonces llegó esto, React Lazy, porque React Lazy requiere que tengas una exportación predeterminada para tu componente. Yo estaba como, no. Todas nuestras decisiones se fueron por el desagüe y tuvimos que repensar de nuevo. Y creo que con todos los equipos que volvieron a tener exportaciones predeterminadas para los componentes, no estábamos contentos, pero bueno, lo aceptamos. Quiero decir, bueno, lo aceptamos. En este punto, también sientes que tal vez la hierba debe ser más verde en el otro lado. Así que, por ejemplo, miramos Angular, y encontramos como, okay, ¿cuál es la versión actual de Angular? Así que tienes como uno, dos, tres, no, tres, uno, dos, cuatro. Y estás como, okay, olvídalo. De vuelta a React, veamos cómo va esto. Y sí, todavía hacemos exportaciones predeterminadas ahora. Me parece extraño, pero está bien. Y sí, incluso como, creo que hace un par de días, hubo como una serie de tweets donde la gente estaba copiando y pegando el mismo tweet y tuiteando que las exportaciones predeterminadas fueron un error en JavaScript, y estoy de acuerdo. Pero hay un consejo, un truco que quiero mostrarte. Si tienes a alguien, si tienes un componente que es una exportación nombrada, y no puedes controlarlo porque viene de una biblioteca, puedes usar named. Parece feo, probablemente confunde a los juniors en tu equipo, los confunde mucho, pero aún así, hay una forma de hacerlo. Sí. Por qué probablemente todavía quieras, por qué nos quedamos con las exportaciones predeterminadas, porque todos los marcos prefieren las exportaciones nombradas de todos modos. Así que sí, es un poco extraño, pero podemos vivir con ello.

Pasemos al siguiente tema, TypeScript. Me encanta TypeScript. Es impresionante. Me encanta la tipificación. La seguridad de ello, es genial. Lo único que no siempre me encanta son los tipos de react.

Permíteme darte un ejemplo. Cuando empiezas a escribir, tu primer componente React, aprendes, de acuerdo, hay un componente de función React, y lo haces así, y luego te das cuenta, de acuerdo, pero la gente no usa esto. La gente usa React.fc. Y yo estaba como, no tenemos diversión, funky, y divertido para la función como una palabra clave en JavaScript. ¿Por qué hacer esto? ¿Por qué no podemos tener una forma de hacer las cosas para que puedas enseñar de una manera, y puedes aprender de una manera, y puedes ser bueno en ello? Pero esto no es el final de la historia porque entonces, cuando realmente empiezas a leer sobre cómo tipar componentes, y así sucesivamente, te das cuenta de que muchos expertos, TypeScript expertos, te dicen que no hagas React.fc.

Básicamente, y todo se reduce a que casi todos ellos se quejan de un problema que existía en, sí, alerta de spoiler, ahora está resuelto. Básicamente, los tipos siempre implícitamente, así es como sucedió, las implicaciones de React.fc añadieron los hijos implícitos. Así que si tenías un componente, como un modelo, que cuando realmente necesitas tener hijos, nosotros los esperamos, podrías pasarlos o podrías dejarlos fuera. Pero si tienes otros componentes donde no haces uso de los hijos en absoluto, tú no puedes declararlo de ninguna manera porque siempre estarán opcionalmente allí con React.fc. Y básicamente, lo que propusieron es usar esto en su lugar. Y haces esto y migras toda tu base de code con tu equipo, y luego incorporas a nuevos juniors y están realmente, realmente emocionados porque sienten que, hey, tienen una mejora de la que pueden hablarte. ¿Sabías que hay un React.fc y podríamos migrar a esto? Y la única reacción es como, hablemos de otra cosa. Y te sientes realmente mal por ellos. Pero todo cambió. Por cierto, los tipos de React no son mantenidos por el equipo central de React. Pero quienquiera que los mantenga, tomó una decisión realmente genial porque con React 2018 y cambio disruptivo, introdujeron un cambio con sus tipos, eliminando los hijos implícitos. Ta-da. Y yo estaba como, aleluya, resolvió todos mis problemas, puedo volver a React.fc. ¿Por qué? Porque si tengo esto aquí, si tengo hijos, ahora tengo que tiparlos explícitamente, o puedo tiparlos explícitamente y básicamente decir de acuerdo, los hijos son una nota de React. Y lo que está pasando aquí es que si miras este componente, el componente utiliza hijos, y básicamente se espera que pongas a los hijos. Si haces esto, todo estará bien. Pero si haces esto aquí, obtendrás un error de typescript. Así que te dirá como, hey, este componente realmente sólo funciona bien si pasas hijos. Así que por favor pasa a tus hijos. Y también puedes hacerlo al revés. Si dejas a los hijos fuera del todo, lo bonito es que si haces esto, estará bien. Pero si haces esto aquí, te dará una advertencia, hey, deberías proporcionar hijos. No deberías proporcionar hijos porque este componente no acepta ningún hijo. Así que este es un truco muy ingenioso. Realmente arreglaron los tipos y realmente se ajusta a mi modelo mental de básicamente como quiero decir, esto es Wikipedia, pero el objetivo es evitar que las operaciones que esperan un cierto tipo de valor se utilicen con valores con los que esa operación no tiene sentido.

Siempre quieres tener como si TypeScript fuera una herramienta para ayudarte a dar sentido a las cosas y no como refrescar y luego descubrir, oh, en realidad no usa hijos en absoluto. Así que eso fue realmente, realmente genial. Lo más extraño o lo más raro de los tipos TypeScript en React se solucionó en realidad. La cosa es que ahora cuando actualizas a React 18, en realidad tienes que cambiar todos tus componentes, y esta es la lástima de nuevo. Como, oh, Dios, ahora tengo que ir a cientos de miles de componentes y arreglarlos, pero hay algo llamado code mod. ¿Quién de ustedes ha oído hablar de code mods, JS Codeshift? Vale, algunos de ustedes. Son básicamente scripts que te permiten ejecutar en toda tu base de code y lo genial es que arreglarán tu code. Así que si estás actualizando, si estás actualizando a React 18 y actualizas los tipos, puedes básicamente ejecutar este script en tu carpeta de origen y se hará y se actualizará todo. Entonces, ¿qué hace? Toma este componente, por ejemplo, y lo actualiza a este, y yo estaba como, sí, resolvió todos mis problemas, y luego estaba como, en una segunda mirada, espera un segundo. Este componente en realidad no usa hijos. ¿Qué estás viendo aquí? Props con hijos, y pensé, como, tal vez mal utilicé el script o hice algo mal, pero quiero decir, empiezas a investigar. Entonces miras este tipo, como qué son props con hijos, y luego ves los hijos opcionales allí de nuevo, y sentí como, ¿por qué? Vamos. ¿Realmente me estás haciendo esto? ¿Por qué me estás haciendo esto? Al menos, cuando haces esto, ten la dignidad y llámalo props con hijos opcionales para que sepa lo que está pasando. Bueno, no es perfecto, es mejor, digamos.

Siguiente tema, hablemos de use effect. Oh, Dios. Todos amamos use effect. No puedo arreglar use effect para ti. Lo único que puedo decirte es que muchos problemas surgen porque las personas no utilizan la función de limpieza. Al menos, esto es lo que he visto. Una cosa que encuentro muy molesta, la gente a menudo no sabe que deberían hacer una función de limpieza y luego la olvidan y es muy fácil pasarla por alto en una revisión de code. Así que después de mucha frustración, finalmente, decidimos, hagamos algo al respecto. Podríamos hacer ahora ESLint y demás, pero la forma más fácil fue, corrijamos los tipos reales de React porque podemos sobrescribirlo. Así es como se ven básicamente los tipos de React para use effect, y lo que puedes ver aquí en la parte superior derecha en la segunda línea es destruct.avoid. Básicamente, la gente puede dejar fuera la función de limpieza y no tiene que devolverla. No te preocupes demasiado por los tipos. Lo único que quiero decirte es que podríamos simplemente corregirlos. Lo sobrescribimos y decimos, no, void no está permitido. Y luego también podemos corregir el nombre, porque, vamos, en toda la documentation dice no destructor, dice función de limpieza. Así que llamémosla función de limpieza. Y luego no lo llamemos callback de efecto porque esto es muy inespecífico. Llamémoslo callback de use effect. Realmente me gusta, cuando ya estoy allí, corregir cosas de todos modos. ¿Y qué te da esto? Básicamente te ves obligado a devolver una función de limpieza. Y básicamente si no lo haces, te dará una advertencia agradable, oye, te falta una función de limpieza, básicamente. Y básicamente la gente tiene que hacer esto. Y sí, la gente todavía podría hacer esto. Pero si ves esto en una revisión de code, al menos es muy visible que esto está sucediendo. Así que este es un pequeño truco agradable que quería compartir. No hace que React sea menos extraño, pero al menos hace que nuestras vidas con effect sean más racionales. Lo que me lleva al siguiente tema.

Advertencias. Tengo una enorme relación de amor y odio con las advertencias. Todos ustedes probablemente conocen esta. No se puede realizar una actualización de estado de React en un componente desmontado. Tienes docenas de ellas. Esto es realmente bueno. Me gusta. Porque realmente te dice, oye, hay algo que hiciste mal. Puedes solucionarlo. Pero no estamos lanzando un error, pero al menos te estamos dando una advertencia. Estoy de acuerdo con eso. Esta es la parte de amor más. Sé que todavía las odio cuando las veo, porque sé que hice algo mal. Y sí, no me culpes, React. Pero al menos estoy intentando solucionarlo.

Está bien. Pero lo cierto es que no soporto cuando proviene de un paquete. Esto es tan molesto. Y te lo mostraré. Esta es una situación real. Estas eran dos advertencias que teníamos que pasar cada vez que solo queríamos mirar nuestros registros de console. Esta es la segunda advertencia. Es como, es una aplicación de React Native Web. ¿Por qué tengo que pasar por esto cada vez? Viene de un paquete. Sí, ya he reportado el problema. Y sí, alguien tiene que hacerlo. Pero a veces es realmente difícil de reproducir. Es como, oh, Dios. Y nosotros, o al menos yo, estuve de acuerdo con ellos durante algún tiempo. Y luego pensé, en algún momento, tengo que hacer algo al respecto. Ya no puedo soportarlo más.

Entonces, estaba tratando de buscar cómo puedo solucionar esto. ¿Cómo podemos hacer algo al respecto? Y luego descubrí algo que fue muy, muy interesante, al menos cambió mi vida. ¿Sabías que puedes parchear el registro de console? Es fantástico, me encanta. Y sí, en este punto, cuando descubrí esto, debería haber hecho lo otro y hablar con mi equipo y solucionarlo. Pero lo primero que hicimos, o hice, fue encontrar una forma de gastar bromas a otras personas. Básicamente, sobrescribiendo el registro de console al limpiar la console en casi menos de un segundo. Básicamente, podemos pegar esto aquí. Y luego, cada vez que intentas registrar algo, lo registras y quieres inspeccionar la salida. Y se borra de inmediato. Genial.

Y sabes, la parte importante de una buena broma es que debe ser lo suficientemente molesta para que se molesten, pero no deberían hacer nada al respecto. Sienten que, está bien, eché un vistazo a la salida, tal vez esto sea suficiente. Es una línea fina para hacer una buena broma. Y luego, por supuesto, no quería facilitar demasiado a todos los que se encuentran con ella. Así que creé otra versión donde puedes mirar en tu base de code y encontrar cualquier cosa que esté relacionada con console, log, o clear.

Realmente lo haces difícil. Si logras meterlo en la code base, tendrán dificultades para encontrar esto. Por favor, usa esto. Esto está completamente bien. Creo que sí. No lo sé. No me demandes. Y sí.

Entonces, finalmente, después de haberme divertido lo suficiente, volví a la cosa de adulto. Y sentí que, está bien, vamos a hacer algo acerca de nuestras molestas advertencias. Y lo parcheamos. Creamos un pequeño script que básicamente parchea estas advertencias para componentes específicos y así sucesivamente. Básicamente puedes hacer un poco de coincidencia de patrones con RegEx.

Y luego sentí que, está bien, tengo que dar charlas en conferencias este año. ¿Qué hago? Esto es algo nuevo. Así que vamos a crear la biblioteca de eso, para que realmente pueda tener algo que anunciar en las conferencias. Y esto es, React reduced stress. Esto realmente existe en NPM. También hay un repositorio en GitHub. Puedes encontrarlo. Puedes usarlo. Y sí. Puedes obtener simplemente React reduced stress y suprimir las advertencias. Y puedes ver, como, para el orden de los hooks puedes básicamente pasar en qué componente. Y para la clave única en la lista, sí, estamos usando una biblioteca avatar group. Estaban haciendo algo y estropeando los hijos. Era como, oh, Dios, lo reporté, pero ya no estoy esperando más por nuevas versiones. Y luego algunas cosas de React native que también suprimimos. Entonces, sí. Puedes usar esto.

Esto realmente funciona. Y si tienes preocupaciones, repórtalo. Y le puse mucho amor. Como una noche, ya sabes. Pero funciona. ¿Y qué te da? Tranquilidad en tu console. ¡Ta-dah! Lo que me lleva a un tema relacionado.

Y creo que, sí, este es el último. Así que, suficiente con los registros, suprimiendo registros. Pero hay otro que quiero mencionar. ¿Quién de ustedes, la última cosa extraña, quién de ustedes usa el modo estricto de React? No muchos. ¿Por qué? Solo bromeo. Entonces, por razones. Y esto está realmente copiado de los docs oficiales. Quiero decir, la mayoría de esto es básicamente solo, como, razones legítimas. Si tienes un code antiguo, el modo estricto es bueno, porque te ayuda a identificar qué está yendo mal y así sucesivamente. Pero la cosa es, hay dos cosas que son completamente nuevas desde React 18. Básicamente, detectar efectos secundarios inesperados y garantizar un estado reutilizable. Y lo que hace es, si estás usando el modo estricto en desarrollo en React 18, vuelve a renderizar tu componente dos veces, y también ejecuta el use effect y el use layer effect dos veces. Quiero decir, el use layer effect normalmente solo se ejecuta si te comprometes con el DOM, pero aparentemente entonces se renderiza dos veces. No creo que realmente se comprometa dos veces con el DOM, pero es como ejecutar el use layer y use effect dos veces. Esto tiene un buen propósito porque muchos de nosotros estamos abusando de use effect y luego haciendo cosas que no deberían ejecutarse dos veces. Si habilitas el modo estricto, básicamente verás muchas situaciones de use effect rompiéndose. Esto es realmente molesto, pero tiene un propósito. Muchas de las nuevas características que vendrán con React, como el componente fuera de pantalla y así sucesivamente, Puedes prerenderizar páginas. Las cosas que no están en la página no tienen que renderizarse. Así que puedes tener un renderizado más rápido, cosas más rápidas en el DOM. Salida más rápida en el DOM. Todas estas cosas esperan que use effect no tenga efectos secundarios extraños y haga cosas mal. Pero el problema es, entiendo esto, y OK, básicamente necesitamos limpiar nuestro code.

Y lo entiendo. Pero el problema es que la gente no lo entiende. No hay, como, ninguna pista de que esto está sucediendo. Si actualizas a React 18 o si simplemente lo instalas en una nueva versión, en un proyecto completamente nuevo no tienes información de por qué esto está sucediendo. Y la gente no lo entiende. Y esta es una conversación real de un amigo que básicamente perdió el día porque estaba construyendo un reproductor de video en su aplicación. Y como, no sé qué hizo, pero el efecto de montaje, el use effect de montaje básicamente reprodujo el reproductor de video dos veces, y el reproductor de video pudo manejarlo, y yadda, yadda, yadda, y un par de palabrotas que tuve que ocultar. Y yo estaba como, ¿por qué no hay, quiero decir, tenemos un registro de console para todo, pero por qué no hay un registro de console para esto? ¿Sabes? Estamos mostrando a las personas si no tienen las DevTools y están ejecutando en DevMode, nosotros les mostramos por favor instala las DevTools, pero no les estamos dando ninguna información acerca de por qué está sucediendo este doble renderizado y ¿sabes por qué? Solo está sucediendo en DevMode, no está sucediendo en producción. Entonces, en realidad tienes un comportamiento diferente si estás ejecutando en producción o no. Así que esta vez hice lo otro, ¿sabes? Realmente fui al repositorio de REG.js, abrí un problema, propuse ¿podemos tener un registro de console para esto y así sucesivamente? No hubo mucho feedback, tiene un par de semanas. Nadie del equipo de React lo ha visto. Pero, ya tengo React Reduce Stress así que pensé como, puedo solucionarlo yo mismo. Porque lo que puedes hacer es, podemos extender React Reduce Stress con el componente Reduce Stress que puedes poner en tu code. Así que todos los nuevos juniors que vendrán si estás usando el modo estricto, puedes importar Reduce Stress, solo tienes que agregar un componente allí. Y lo que hará es, si estás en modo estricto en modo de desarrollo, esto es completamente no está haciendo nada, te dará esta pista. Porque estás usando el modo estricto en desarrollo, React desmontará y volverá a montar cada componente cada vez que el componente se monte. Da-da-da. Básicamente ayudando a tus desarrolladores a descubrir qué está pasando. Y sabes, de nuevo, le puse mucho amor. Uh, dos noches o algo así. Y tiene un par de características. SMDS, ¿quién lo ha oído? Vale. Sistema de Detección de Modo Estricto. ¿Dónde lo encontré? Está en el núcleo de React. ¿Y sabes qué hacen? Sobrescriben el registro de console para detectar si el bloqueo del modo estricto está sucediendo. Es genial. Tiene soporte para el modo oscuro. De verdad. Así que la console, el rojo, cambia ligeramente en la console.

Y solo es compatible con navegadores modernos. Así que Firefox, Chrome, Brave y Edge. Y no damos soporte a Safari o Internet Explorer. Sí. Y esto es básicamente todo.

¿Cuál es la conclusión para ti? Hubo mucho como balbuceo. Lee la React docs. Consulta los RFCs. Lee el grupo de trabajo. Diviértete gastando una broma a alguien con el bloqueo de console. E instala React Reduce Stress.

Y a pesar de tener, como esto fue una charla de 30 minutos aquí. Quiero decir que ha sido un viaje bastante interesante. He aprendido mucho. Fue muy divertido. Y realmente me quedaré por aquí. React es increíble. Tiene sus defectos. Pero es un viaje súper interesante. Y he aprendido mucho. Y soy Nick Graf. Y espero que hayas disfrutado hoy. Muchas gracias. Increíble. Muchas gracias, Nick. ¿Está esto encendido? Por favor, entra en mi oficina. Solo tenemos un par de minutos. Pero hay un par de preguntas en el Slido de la audiencia. Recuerda que es slide.do y el code es 0212 si quieres hacer una pregunta. Nick, cuando enseñamos a los nuevos desarrolladores de React, ¿deberían aprender sobre estas rarezas o deberíamos ocultarlas hasta que hayan pasado el punto de no retorno? Definitivamente después del punto de no retorno.

No vas a una cita y cuentas lo más raro de ti. Sí, creo que sí. Quieres tener una introducción sutil. Y luego puedes contarle más a la gente con el tiempo. Use effect es algo que tienes que decirles de inmediato. Y tal vez si alguien es nuevo en React, no los introduzcas a use effect de inmediato. Pero mantén eso en segundo plano y céntrate en las cosas que son fáciles y mantienen a la gente en marcha. Quieres mantener la felicidad porque así es como la gente aprende mejor, creo. Creo que es un buen advice.

La otra pregunta que tenemos es ¿cómo detectas si la aplicación está actualmente funcionando en modo estricto? Realmente es esto, hay un console log. Quiero decir, solo revisa el code. Pero básicamente, hay un console log que está sucediendo creo, y luego lo haces así. Oh sí, oh, no. Es una advertencia de un componente heredado que básicamente está obsoleto. Así que estamos detectando si el componente heredado es, así que el React Reduced REST utiliza el componente heredado que debería estar obsoleto, y luego lanza una advertencia y estamos detectando si se lanza la advertencia, y así es como estamos detectando que el modo estricto está funcionando. Es una locura. Pero esto está en una prueba de núcleo de React, así que pensé, OK, esto parece ser la mejor manera. Vamos a copiar y pegar. No hay ninguna variable interna oculta que puedas usar para averiguarlo. Sí, justo.

Hay un par de preguntas interesantes al margen. ¿Cuál es tu opinión sobre re-script en esta etapa? Para dar contexto, yo era parte de la temprana comunidad de Reason.ml, y re-script es básicamente un sucesor de ella, y sí, me encanta re-script. Me encantan los buenos sistemas de tipos, y es realmente genial, pero ahora mismo no lo estoy usando. Simplemente porque, como, tengo un producto y tengo desarrolladores que estaban familiarizados con TypeScript, pero no con re-script, y entonces, como, introducirlos a re-script habría llevado mucho tiempo, y al final fue una decisión muy práctica no ir con ello. Quiero decir, me encantan los sistemas de tipos, me encanta escribir code limpio, pero sí, a veces lo práctico es simplemente más fácil y mejor. Tenía más sentido.

Tiene sentido, a veces tienes que ser práctico. Eso es todo el tiempo que tenemos para preguntas, pero Nick estará en la sala de conferencias junto a la recepción para preguntas uno a uno en la vida real. Gracias, Nick. Muchas gracias.