No resuelvas problemas, elimínalos

Hola a todos. ¡Sí! Mi nombre es Kent C. Dodds, y soy un ingeniero de software, y voy a hablar sobre cómo deberíamos evitar resolver problemas e intentar eliminarlos en su lugar.

Pero antes de hacer eso, me gustaría que todos despertaran. Así que por favor levántense. Acabamos de almorzar. Tu cuerpo es como, oh, es hora de dormir. No, no lo es. Es hora de levantarse. Levántate. Vamos, vamos. Extiende tus brazos frente a ti así y agáchate y vuelve a subir. Esto es ejercicio, ya sabes. No tuvimos que hacer eso cuando estábamos encerrados en nuestras habitaciones.

Así que vamos a hacer 12 de estos juntos, y quiero que cuentes en voz alta. ¿Listos? Uno, dos. No estás contando. Tres. Ahí vas. Cuatro. Cinco. Seis. Esto es genial. Siete. Tus piernas son como, ¿qué estás haciendo? Nueve. Diez. ¿Eso es 11? ¿Deberíamos empezar de nuevo? 12. No, solo bromeaba. Estira lo más alto que puedas y estira hacia un lado y hacia el otro. Muy bien.

Ahora, antes de que te sientes, simplemente preséntate a la persona que tienes al lado y agradécele por venir. Y si estás en línea, puedes hablar con tu gato. Gracias. Por eso.

Bien. Primero solo quiero mencionar que reescribí mi sitio y lo relancé recientemente y es realmente genial y quiero que le eches un vistazo. De hecho, incluso tengo los registros funcionando aquí mismo. Así que si quieres hacer que estos registros se vuelvan locos, ve a KentCDONS.com ahora mismo y veremos cosas locas. Por favor. ¿No? Está bien. Bien. Tengo un pequeño error en el servidor, así que eso es bueno. Sí, ahí vamos. De eso estoy hablando.

Entonces, cuando estaba construyendo KentCDONS.com es cuando comencé a pensar en cómo queremos eliminar problemas en lugar de resolverlos. Y llegaré a eso un poco hacia el final. Así que de ahí surgió la idea para esta masterclass. Mi clicker no está funcionando. Es mío. No es de ellos. Es mi culpa. Así que simplemente usaré el teclado.

Entonces, de lo que voy a hablar en esta masterclass es sobre problemas, soluciones y compensaciones y cómo resolver es genial, eliminar es mejor, y evitar es aún mejor si puedes manejar eso. No voy a dar ejemplos de code. Esto no es una cosa de codificación en vivo. Por mucho que disfrute de esas masterclass, sí, de hecho, no se trata necesariamente de code. Es más sobre la vida en general y los problemas. Y sí, no es específico del dominio. Así que sé que estamos en una conferencia de React, pero esto no tiene mucho que ver con React excepto hacia el final donde intentamos aplicarlo. Así que este es un árbol de problemas.

No se supone que puedas ver lo que hay dentro de esos pequeños cuadrados. Pero el icono azul aquí representa el problema central que estás intentando resolver. Así que cualquiera que sea la misión de tu empresa, eso es lo que este problema central es. O cuál es el objetivo central. Y a partir de eso, tenemos diferentes problemas con los que necesitamos lidiar. Y cada uno de esos nodos extra es otra solución. Y a veces las soluciones que desarrollamos conducen a más problemas. Y así, eventualmente llegamos a la solución terminal que no tiene ningún problema que nos importe resolver. Y estos son mucho más grandes en la vida real. Si intentaras mapear todos los problemas que tiene tu empresa, o lo que sea en la vida, entonces sí. Tendrías muchos. Así que aquí tienes una versión simplificada de un árbol de problemas. Y vamos a referenciar esto un par de veces a lo largo de esta masterclass.

Así que, en primer lugar, creo que es importante reconocer que eres un solucionador de problemas. Eso es parte de por qué la humanidad es la especie dominante en el planeta, porque resolvemos problemas y hemos, supongo, dominado el planeta. Pero somos tan buenos en ello que también nos convertimos en buscadores de problemas. Donde estamos buscando problemas para resolver. Y esto, tengo una pequeña historia sobre esto. Y tal vez puedas relacionarte con esto.

Así que cuando la pandemia golpeó, mi hermana, que es una violinista muy consumada, vio a todos sus amigos músicos profesionales totalmente sin trabajo, y no estaban seguros de qué hacer. Y entonces ella vino a mí y dijo, oye, ¿puedes construirme una aplicación que pueda ayudar a resolver este problema? Y no entraré en los detalles de ello. Pero básicamente necesitaba que yo construyera un Google Calendar y Zoom en una sola cosa integrada. No integrar esos, sino construirlos todos. Siempre subestimamos la cantidad de trabajo que estas cosas llevarán. Y ella dijo que había hecho toneladas de investigación de mercado y había mirado qué soluciones había por ahí y todo, y sentía que estaba dispuesta a contratar a alguien para trabajar en este problema. Y le dije, sabes, como, tal vez necesitas realmente simplemente trabajar manualmente a través de estas herramientas y ser la que facilita lo que estás tratando de hacer aquí, y ella dijo, no, sólo quiero automatizar todas estas cosas y scale todo y todo. Y yo simplemente dije que no lo sé. Y así que al final lo que ella terminó haciendo fue nada. Decidió que no quería invertir en ello. Y creo que fue una decisión sabia. Una cosa que he aprendido es que es mucho más fácil resolver un problema cuando sabes cuál es el problema. Y asumimos que entendemos cuál es el problema desde el principio, y entonces, como, asumimos que vamos a necesitar un sistema de tickets y vamos a necesitar un sistema de calendario y una cosa de chat de video, y tenemos todas estas suposiciones. Y tal vez lo hagas, pero no conoces todas las complejidades de qué características necesitarán esas diferentes cosas. Y entonces, sugiero que primero sientas el dolor de la solución manual y luego resuelvas esos dolores a medida que vengan. Y entonces, la evitación de problemas es esto. Evitas resolver o evitar el problema por completo al no crear la solución prematuramente. Y Elon Musk recientemente tuvo una entrevista y realmente me encanta esta cita. Dijo, posiblemente el error más común de un ingeniero inteligente es optimizar la cosa que no debería existir. Y pensé que estaba hablando de mí. Así que, es mejor evitar problemas que resolverlos. Así que, aquí está nuestro árbol de problemas de nuevo. Si estamos evitando un problema, digamos que queremos evitar el problema en la solución 1B aquí. Y simplemente decidimos que no vamos a resolverlo.

Eso es lo que es la evitación de problemas. No lo resuelves. Y aquí está la conclusión que quiero que saques de esta masterclass. A menudo bajamos en este árbol de problemas y llegamos a un solo nodo. Y estamos trabajando en esta solución aquí. Y es una bestia de solución. Este problema aquí es súper difícil. Y mientras trabajamos en esta solución, decimos, hombre, esto es difícil. Y a veces incluso puedes decirte a ti mismo, si hubiera sabido que iba a ser tan difícil, nunca lo habría hecho.

Y entonces, ese es el momento en el que piensas, ¿realmente necesitamos resolver este problema en absoluto? Y a menudo, sí. Como que absolutamente... Todo esto no funciona si no resolvemos este problema. Pero tal vez todo esto no necesita existir tampoco. Y entonces, puedes subir en el árbol de problemas hasta llegar a una solución que dices, ¿sabes qué? Realmente no necesitamos eso. Entonces, los usuarios ni siquiera usan esta función mucho. Entonces, podemos simplemente deshacernos de esta función por completo. Si hubiera sabido lo caro que sería resolver este problema, nunca habría añadido esta función en primer lugar.

Entonces, reevaluar nuestro árbol de problemas puede ahorrarte mucho tiempo y en última instancia ser mejor para tus usuarios, porque cada minuto de cada día que pasas, o, todo lo que puedes hacer tiene la misma moneda, y ese es tu tiempo. Y cada minuto que pasas haciendo una cosa es un minuto que no puedes pasar haciendo otra. Y entonces, está totalmente bien decir, ¿sabes qué? No vamos a resolver ese problema, porque tenemos otras cosas de las que ocuparnos ahora. Por eso le digo a la gente que, oye, no pruebo todo lo que escribo. Mucha gente me ve como un chico de testing, como, 100% de cobertura de code y desarrollo test-driven. Ese no soy yo. Veo el testing como un mecanismo para automatizar la calidad y la confianza del code, pero eso no es lo único que estoy haciendo. El code no existe por sí mismo, así que tienes que ser práctico sobre las cosas en las que pasas tu tiempo. La evitación de problemas es fantástica. Lo recomiendo si puedes evitar problemas, pero a veces la casa está en el acantilado, supongo? No sé cómo ocurrió esto, pero me alegro de que alguien estuviera allí para tomar una foto al menos y tal vez dejó su cámara y fue a ayudar. No sé, pero a veces no puedes evitar el problema, así que en esta situación, antes de intentar resolver el problema, ve si puedes eliminarlo. No sé, volar la casa. Este es un mal ejemplo, supongo.

Entonces, aquí está la razón. Las soluciones te mantienen cautivo de su mantenimiento para siempre. Y daré un ejemplo en el mundo real. Aquí tenemos un motor de combustión interna, y hay muchos problemas que hemos enfrentado durante más de 100 años que hemos estado trabajando en motores de combustión interna que han sido resueltos de maneras notables. Primero, tenemos el escape. Cuando quemas gasolina, hay escape, y ese escape no es bueno para nuestros pulmones, y por lo tanto no queremos que entre en la cabina, así que tenemos toda esta tubería para dispararlo hacia la parte trasera del vehículo donde seguramente no hará ningún daño. Eso fue sarcasmo. Eso es hasta donde hemos llegado en la solución de ese problema. También al detenernos, tenemos pastillas de freno, aprietan los discos de freno, o los discos, y podemos detener el vehículo. Y eso ha funcionado, excepto que también, esos discos de freno no desaparecen mágicamente y tienes que reemplazarlos, ¿verdad? Esa goma se va al aire y todos la respiramos, pero eso es hasta donde hemos llegado en la solución de ese problema. Los coches realmente pueden incendiarse, es increíble que cuando estás literalmente quemando cosas y explotando cosas para hacerte mover que tal vez realmente se incendie. Pero han puesto mucho trabajo en evitar este problema o en tratar de resolver este problema tanto como sea posible. Y luego la sostenibilidad, bueno, este es el problema que simplemente decidimos que no resolveremos con los motores de combustión interna. No es posible hacer esto sostenible. Entonces, ¿qué pasa si miramos nuestro árbol de problemas y decimos, sabes qué, este problema de sostenibilidad o los incendios de coches o lo que sea, este es un problema realmente difícil de resolver. Subamos por el árbol de problemas y volvamos a la movilidad. Ahora, por supuesto, puedes montar en bicicleta y puedes saltar al metro o lo que sea, pero en algún punto la gente necesita tener movilidad individual. Entonces, ¿cómo vamos a resolver ese problema? ¿Qué pasa si cambiamos totalmente el enfoque por completo? Y este es el motor eléctrico de Tesla, este es el motor que alimenta el coche de producción masiva más rápido del mundo, el Tesla Model S. Y aquí están los problemas que prácticamente han eliminado. El escape está absolutamente eliminado. No hay escape. Ahora la gente habla sobre el tubo de escape largo, pero el hecho es que eventualmente todos nosotros vamos a estar alimentados con energía sostenible por lo que ese tubo de escape largo se corta. No tenemos problema de escape, punto. Yo tengo un Tesla y mi casa es alimentada por energía solar, así que estoy conduciendo con energía solar y es increíble. Cuando encendimos el sistema la semana pasada, empecé a conducir mi coche y a cantar, estoy conduciendo con energía solar. Es simplemente, tan, tan, una gran victoria. Y luego al detenernos, lo genial de lo eléctrico es que puedes convertir esa energía cinética en electrones reales y meterlos de nuevo en la batería y así que sí, mientras todavía tenemos pastillas de freno en los vehículos eléctricos, probablemente nunca necesitemos reemplazar porque la mayor parte de esa energía vuelve a la batería y por lo tanto no hemos eliminado ese problema por completo pero hemos reducido drásticamente el impacto de ese problema. Eso es súper impresionante. Los incendios de coches, en cuanto a, sé que los incendios de coches eléctricos salen mucho en las noticias pero en cuanto a los data se refiere, tienes 11 veces menos probabilidades de que tu coche se incendie si es un modelo de Tesla o sí, un Tesla. No sé sobre los otros fabricantes pero los data que he visto son de Tesla.

Eso es bastante significativo. Y luego la sostenibilidad, en última instancia podemos hacer esto sostenible y eso debería ser la única razón por la que hacemos esto. Si todas las demás cosas estuvieran bien, esta es razón suficiente para que hagamos este cambio. Y entonces, al subir un poco en el árbol de problemas y decir, oye, ¿qué tal si no necesitamos realmente resolver esto o qué tal si este es un problema demasiado difícil de resolver y volvemos un poco hacia arriba en el árbol de problemas y decimos, oye, ¿qué tal si cambiamos nuestro enfoque, y ahora tenemos una nueva solución, así que no lo hemos eliminado, no hemos decidido que no vamos a resolver este problema de movilidad personal, simplemente vamos a cambiarlo para que tengamos un árbol de problemas más pequeño. Ahora, ciertamente hay muchos problemas con los vehículos eléctricos también, pero el árbol de problemas es más pequeño y los problemas son más pequeños y por eso esta eliminación es tan genial. Tesla es en realidad un gran case study para la eliminación de problemas, así que si alguna vez quieres ver las cosas asombrosas que están haciendo con la fabricación, es realmente fenomenal, muy interesante.

Bueno, hablemos de software ahora. En software, tenemos algunos ejemplos, particularmente en React, de eliminación de problemas. ¿Cuántos de ustedes han escrito componentes de clase React? ¿Algún usuario de Create Class de React por aquí? Veo a algunos de ustedes. Sí, eso fue divertido. Sí, y luego obtuvimos componentes de clase. Y esta captura de pantalla aquí proviene de la publicación de blog de Amelia Weittenberg sobre los hooks de React, que es muy buena. Te recomiendo que le eches un vistazo. Pero uno de los grandes problemas que teníamos con los componentes de clase era la reutilización de code. Y tendrías una única preocupación en tu componente de clase que se repartiría entre estos tres ciclos de vida. Tendrías tu componentDidMount, componentDidUpdate, componentWillUnmount. Si querías suscribirte a Firebase o querías actualizar el título del documento, tenías que repartir todo esto en tu componente. Así que reutilizar eso era un poco complicado. ¿Usamos un componente de orden superior para que pudiéramos hacer un componente que hiciera todo eso y luego simplemente pasamos nuestro componente a eso para que podamos aceptarlo como props? Bueno, había muchos problemas con eso. Tenías problemas de espacios de nombres, era muy difícil de tipar, así que empezamos a hacer render props. Y eso fue divertido. Realmente poderoso. Pero luego tenemos, como, estos árboles gigantes, o una pirámide de la perdición, tratando de conseguir todas estas cosas compuestas. Simplemente no se componían muy bien. Y funcionó, y no estuvo mal. Como viví a través de eso, y fue un buen momento. Me divertí mucho con eso. Pero, ¿no sería genial si simplemente no tuviéramos el problema en primer lugar? Entonces llegaron los hooks y agruparon todas las preocupaciones en un solo fragmento de code. Así que podría ser como un use date y use effect y un par de otras cosas ahí. Pero todo podría estar en este mismo fragmento de code. Entonces, ¿qué haces cuando quieres reutilizar code? Puedes crear una función a partir de ella, y no podías hacer eso con nuestros componentes de costos porque la preocupación se repartía a través de varios hooks de ciclo de vida. Pero con estos hooks, puedes simplemente tomar eso y meterlo en otra función. Eso fue brillante. Tuvo un impacto enorme en nuestra capacidad para reutilizar code. Redujo drásticamente la cantidad de cosas que necesito enseñar en mi masterclass de patrones de componentes de React. Las cosas se volvieron mucho más fáciles cuando simplemente subimos al árbol de problemas, decidimos, oye, ¿qué pasaría si hiciéramos las cosas de manera diferente y luego fuéramos en esa dirección.

Ahora, hay problemas al realizar este tipo de migraciones. Todos sentimos el dolor de tener que pasar a las clases y, como, ¿deberíamos incluso molestarnos con todo eso? Al final de todo, estamos mucho mejor. Y estoy realmente agradecido al equipo de React por crear los hooks. Ha facilitado mucho mi trabajo.

Así que ahora es mi parte favorita, y quiero hablarles sobre Remix. ¿Cuántos de ustedes han oído hablar de Remix? ¿Cuántos de ustedes que están levantando la mano lo conocieron porque no paro de twittear sobre él? Sí, la mayoría de ustedes. Así que sí, twitteo sobre Remix sin parar porque me encanta. Así que para que quede claro porque la gente siempre lo quiere. Ha habido una transacción entre mí y el equipo de Remix, así que tuve que pagarles dinero para acceder a Remix. Pero eso no va a ser el caso. Dicen que en unas pocas semanas, Remix será completamente de código abierto y gratuito, y así ustedes también podrán usar Remix. Así que déjenme emocionarlos suficientemente sobre esto. No tengo mucho tiempo para pasar por todo, pero quiero darles una visión general porque Remix es la razón por la que comencé a pensar en la eliminación de problemas en primer lugar.

Así que lo primero que hace Remix que lo hace fenomenal es el enrutamiento anidado. Una cosa buena de esto es que ya no tienes una ruta que es como slash users, slash IDs, slash contacts o algo así. Ahora tienes en ese archivo de ruta, cualquier framework que estés usando, probablemente tienes que renderizar tu ruta de diseño. Y eso incluirá tu encabezado y pie de página y todo. Con Remix, tienes enrutamiento anidado. Así que cada uno de esos va a ser solo el componente que se preocupa por la parte de la ruta que esta parte de la URL de la ruta se preocupa. Eso es realmente agradable. Pero para llevarlo aún más lejos, eso es solo una especie de experiencia de developer agradable. Pero debido al enrutamiento anidado, Remix puede hacer muchas optimizaciones impresionantes en cuanto a la carga de tus data y la validación de la caché y la carga de los data correctos para que no cargue más innecesariamente. Eso es algo realmente genial, porque Remix tiene enrutamiento anidado incorporado.

Otra cosa que me encanta de Remix es la interacción fluida entre el cliente y el servidor. Al igual que Next tiene las props del servidor Git, también tienes un cargador con Remix. Pero Remix hace un gran trabajo al hacer esa conexión muy fluida, como digo aquí. Así que tienes un puede ser completamente tipado. Puedes hacer todas tus solicitudes a database o GraphQL o lo que sea, y luego todos esos data están disponibles en tu componente y tienen un manejo de errores declarativo muy agradable y así en lo que respecta a tu componente, los data están ahí y nunca tienes que preocuparte por los estados de error o de carga, porque todo eso se maneja de manera declarativa para ti, así que para cuando llega a tu componente, simplemente no usas use use effect, tal vez eso es todo lo que necesito decir, ¡como whoo! Sí, no use effect, está bien, y no necesitas una herramienta como React query, si no estás usando remix, deberías usar React query, pero si estás usando remix, no la necesitas porque React query resuelve un gran y asombroso problema, gracias, tanner, por crearlo y a aquellos que lo están manteniendo ahora, pero ¿no sería genial si no tuviéramos el problema para empezar, y eso es lo que nos da remix con su impresionante interacción cliente-servidor.

Otra cosa que me encanta de remix es que se basa en la web, así que todo es cosas de la API fetch incluso en el servidor, tienes una solicitud y una respuesta, y si necesitas aprender algo sobre eso, no vas a los docs de remix, vas a MDN para aprender cómo funcionan las APIs web para eso. Y aparte de la transferibilidad del conocimiento, también obtienes el hecho de que, porque son las APIs web, podemos ejecutar esto en un trabajador de Cloudflare, o en un trabajador de servicios, y Cloudflare los trabajadores están actualmente soportados, los trabajadores de servicios eventualmente, ellos apoyarán eso.

Y clavar esa abstracción ha abierto muchas oportunidades realmente impresionantes con remix. Y lo genial es que realmente no tienes que cambiar nada de tu code. Ahora, si vas a trabajar en ciertos entornos, algunos de ellos como serverless, no puedes conectar para tener una conexión larga a una database o algo así, pero en lo que respecta al código específico de remix, nada de eso necesita cambiar porque todo se basa en la web y remix suaviza todo para ti. Es algo así como jQuery para el servidor. Nunca lo había dicho antes, pero, sí, algo así. Otra cosa que me encanta de remix es su simple mutación. Así que todas las mutaciones en remix tienes un formulario, así que incluso como tu botón de eliminar, la forma en que hacemos esto es que tenemos el pequeño icono de basura. Tenemos un controlador de clics que hará la solicitud, para eliminar el elemento. Con remix usas un muy declarativo aquí está mi formulario, aquí está el icono de eliminar, y haces clic en eso, eso envía el formulario, y luego remix se encarga de todo para hacer la solicitud y ¿qué pasa si hago otra solicitud y estamos cargando data y remix cancelará el correcto, asegurándose de que todo se carga en orden. Incluso si JavaScript falla al cargar, lo cual sucede a veces, la mayoría de las personas no desactivan JavaScript pero fallar al cargar JavaScript sucede, o JavaScript que tarda un tiempo en cargar, lo cual sucede aún más, todas tus mutaciones aún funcionan porque estás usando forms regulares y están haciendo posts regulares o eliminaciones regulares y terminarás con una actualización completa de la página por lo que no es una experiencia tan impresionante. Pero esto es lo que llamamos mejora progresiva. Y así tu aplicación sigue funcionando incluso sin JavaScript y no requiere mucho esfuerzo para hacer que eso suceda, porque es simplemente la forma en que funciona. Y luego también me encanta la historia de CSS con Remix. Aquí está el gran secreto de cómo funciona CSS con Remix. Me sorprende lo simple que es esto. Así que para obtener CSS en la página, tienes una etiqueta de enlace y apuntas a la hoja de estilo. Todos nosotros, estamos usando Webpack y agrupándolo todo, o usando styled components y teniendo parte de nuestros componentes, y es realmente agradable tener esa co-ubicación o lo que sea que es. Pero en cada aplicación que he usado, si tienes CSS regular, todo va a ser agrupado y estará disponible en cada página. En Remix, cada ruta puede definir las etiquetas de enlace que quiere tener activas cuando esa ruta está activa, o quiere tener en la página cuando la ruta está activa. Y cuando te alejas de esa página, entonces esas etiquetas de enlace se eliminan. Y así si quiero tener algún CSS especial que se aplique solo a esta ruta en particular, entonces puedo decir, oye, aquí está la etiqueta de enlace para eso. Y digo, aquí está el archivo CSS que quiero en esta ruta. Y cuando me alejo, Remix elimina la etiqueta de enlace. Y eso es todo. Ese es todo el secreto. Pero aquí está por qué es tan genial. Es porque cuando estoy en ese archivo CSS, sé exactamente qué rutas ese archivo CSS va a impactar. Y así normalmente en cualquier otra empresa en la que he trabajado, cualquier otro proyecto significativo en el que he estado, cualquier archivo CSS en el que estabas trabajando, o SaaS o lo que sea, sabías que este CSS se aplicaría a todas las páginas. Y así siempre estabas preocupado por eliminar algo, porque algo podría romperse. Estás desarrollando, por supuesto, estás viendo lo que está pasando aquí.

Y por lo tanto, te preocupa que puedas romper algo que no estás mirando. Pero con remix, sabes exactamente en qué páginas va a estar activo. Y por lo tanto, sabes exactamente cuáles mirar. Y en términos prácticos, normalmente es solo en una sola ruta. Y mientras lo desarrollas, puedes hacer cualquier cambio que quieras en el CSS, miras la página, y si se ve de la manera que quieres, entonces sabes que tu archivo CSS es bueno. Y no tienes que preocuparte de que impacte en otras páginas del resto de la aplicación.

Este es otro gran ejemplo de eliminación de problemas. Eliminó el problema de los choques inesperados de CSS. Es simplemente fenomenal. Todo el trabajo que hemos estado haciendo durante todos estos años para intentar hacer que el CSS sea más fácil de usar, especialmente como desarrolladores de React, con CSS y JS y CSS modules y todo lo que está entre ellos ha sido para ayudarnos a evitar choques de CSS y remix no elimina completamente el problema. Pero lo hace predecible, y me encanta eso de remix. Nota al margen, simplemente salta al final y usa tailwind para todo porque es increíble. Pero es realmente agradable saber que si quisiera algún CSS único, podría agregarlo a la única ruta y no preocuparme de que impacte en ninguna otra página. Y no necesito ningún tiempo de ejecución ni ninguna herramienta de construcción extra divertida o algo así. Todo simplemente funciona y es la web. Es fantástico.

Hay tantas cosas más que quiero contarte sobre remix, pero simplemente no tengo el tiempo así que vamos a terminar esto. Y de hecho, si quieres saber más sobre remix, estaré más que feliz de hablar contigo durante el resto de la conferencia sobre ello, y tengo un montón de pegatinas que compré yo mismo. Así que de nuevo, remix no me está pagando por ninguna de estas cosas. Les pregunté, ¿puedo imprimir pegatinas? Dijeron que no podían enviarme pegatinas. Las compraré yo mismo. Porque estoy muy emocionado con este framework. Así que muchos de ustedes podrían estar pensando, bueno, la eliminación de problemas suena como elegir compromisos. Y sí, eso es lo que es. Eso es lo que es la eliminación de problemas. Así que la idea detrás de la eliminación de problemas es eliminar problemas grandes a cambio de problemas más pequeños. Y la razón por la que esto es digno de una charla para mí es que no sé ustedes, pero cuando estoy involucrado en un problema, no estoy pensando en si ese problema necesita ser resuelto o si puedo subir por el árbol de problemas y repensar el problema en la parte superior. Por eso los Hooks fueron tan fenomenalmente impresionantes porque todos estábamos trabajando, ¿cómo podemos resolver este problema de compartición de código en la parte inferior del árbol de problemas? Y el equipo de React subió un par de niveles y dijo, oye, ¿sabes qué? Tal vez podríamos tomar un enfoque completamente diferente. Y funcionó. ¿Verdad? A todos nos encanta.

La mayoría de nosotros lo hacemos. Yo lo hago. Así que en conclusión, resolver problemas es genial. Por favor, sigue resolviendo problemas. Hay tantos problemas en el mundo, y quiero verlos a todos ustedes siendo solucionadores de problemas. Eliminar problemas es aún mejor. Encuentra diferentes compromisos y toma lo que sea más fácil. Evitar problemas es aún mejor. Así que si no puedes evitar el problema, entonces intenta eliminarlo cambiando tu enfoque, y solo si eso falla, entonces resuelve ese problema.

Una última cosa antes de ir a mi última diapositiva, olvidé presentarles a todos a Cody el Así que este es Cody, y eso es lo que la gente a menudo me pregunta ¿qué pasa con el koala? Así que cuando la gente me pregunta eso, sé que no han asistido a mis masterclasses, porque Cody te ayuda a pasar por todas mis masterclasses, todo el material de la workshop. Así que de todos modos, me sentí mal teniendo este koala al azar a mi lado, y olvidé presentarlo. Así que ese es Cody. De hecho, puedes conseguir el tuyo en Epic React.dev y conseguir el tuyo, y es adorable. A los niños les encanta.

Muchas gracias a todos. Gracias. Gracias, Sr. Kent C Dodds. Hot seat, por favor. Oh sí. Oh sí. Tenemos mucho de qué hablar. Solo soluciones, sin embargo. No problemas. Bueno, en realidad, una de nuestras primeras preguntas fue ¿cuál es la historia con el koala? Así que supongo que resolvimos eso. Ah, ahí lo tienes, sí. Ese es Cody. No sabía que tenías una tienda de merchandising. Sí. Es muy emocionante.

Así que tienen camisetas y chaquetas, la chaqueta más cómoda que he usado. De hecho, una historia rápida sobre la chaqueta, conseguí una chaqueta similar en el React Rally hace unos años y la destrocé realmente mal cuando me caí de mi one wheel. Como todo el hombro estaba simplemente destrozado. Y estaba tan triste que encontré, pregunté a los organizadores de la conferencia de dónde sacaron la chaqueta y encontré la compañía, y la creé en mi tienda de merchandising para poder comprarla. Por eso está en la tienda de merchandising. Porque me gusta mucho la chaqueta. Es suave. Es súper cómoda. Vamos a tener que comprobar eso. ¿Sabes si se envía a Londres? Sí. No estoy seguro de cuánto cuesta, pero probablemente sea demasiado. Lo escuchaste aquí primero, gente.

Lo siento. Muy bien. Adil pregunta, ¿vienen algunas masterclasses de remix? Oh sí. De hecho, si vas a KentC.com slash workshops, encontrarás que ya tengo dos programadas, así como una masterclass de TypeScript con React en camino. Increíble. Sí. Cosas divertidas. Todo lo que voy a estar hablando durante el próximo no sé cuánto tiempo es remix. Voy a enseñarte a todos lo genial que es remix. Mac pregunta, ¿cómo abordas la falacia del costo hundido? ¿En qué etapa dirías que es demasiado tarde para eliminar el problema en el que estás trabajando? Quiero decir, nunca es demasiado tarde a menos que como la falacia del costo hundido es básicamente, oh hemos hundido tanto en esto, no podemos renunciar ahora, lo que sea. Pero si simplemente lo evalúas ahora tal como está, el trabajo que necesito hacer para resolver el problema y el beneficio que obtengo de eso y el trabajo que necesito hacer para cambiar mi enfoque y el beneficio que obtengo de eso, simplemente haces el análisis de costo beneficio de eso. Sí. No diría que es demasiado tarde para resolver un problema. Es solo como, ¿cómo están las cosas ahora y vamos con la mejor dirección? Eso tiene sentido.

Cuando eliminas un problema, ¿cómo aprovechas lo desconocido? No sabes los problemas a los que te enfrentarás en el otro camino. Sí. Eso es realmente genial. Esa es un poco mi historia con mi hermana, que está intentando resolver el problema para los músicos que están sin trabajo. Y aquí es donde digo, hazlo manualmente primero. Como, simplemente sigue adelante y asegúrate de que estás evaluando a medida que avanzas y te das cuenta, sabes qué, si hubiera sabido esto, nunca lo habría hecho y no creo que valga la pena seguir adelante, o lo que sea. Eso es un buen advice.

Un poco relacionado con nuestros oradores anteriores, de nuestro último espacio, ¿cómo se lleva Remix con los enfoques de microfrontends? Así que Remix es bastante nuevo, por lo que es difícil de decir. Y básicamente no tengo experiencia con microfrontends en un sentido práctico, por lo que realmente no puedo responder. Pero Remix en general es muy abstractable. Eso es una de las cosas que me gusta de él. Así que supongo que sería bastante posible hacer que se lleve bien, pero nadie lo ha hecho aún. Mi sitio web es literalmente la implementación más grande de Remix, y no es pequeño, pero son 27,000 líneas de código, y es la más grande, por lo que todavía es bastante nuevo. En resumen, es bastante popular.

¿Qué es Remix? Remix es un framework para ayudarte a construir mejores sitios web. Es comparable a Next. Renderizado en el servidor. ¿Crees que Remix eliminará todo lo que hemos aprendido hasta ahora? React, query, etc? Bueno, no todo. Una de las cosas que amo de React en particular, y Remix usa React para ser claro, pero una de las cosas que amo de React en particular es que cuanto mejor te vuelves en React, mejor te vuelves en JavaScript. Sí, me encanta eso viniendo de otros frameworks. Con Remix, una de las cosas que amo es que cuanto mejor me vuelvo en Remix, mejor me vuelvo en desarrollo web. Porque está basado tanto en la plataforma web. Y entonces creo que todas las cosas buenas que has aprendido sobre la plataforma web con cualquier framework que hayas estado usando, traes todo eso contigo a Remix. Y Remix te enseñará más. Cualquier otra cosa... Sí, probablemente no vas a usar React Query con Remix. Podrías. Hay casos de uso potenciales para ello. Así que sí, cualquier cosa específica que sepas de React Query, eso no se llevará a cabo, pero es no porque tú... Hay un enfoque diferente o un API diferente que necesitas aprender. Es porque no hay un API que necesitas aprender. Y eso es aún mejor.

Hay un par de preguntas sobre la comparación de Remix con diferentes cosas, como Next o Recoil. ¿Tienes algún pensamiento preliminar sobre eso? Sí. Así que Next compara la mayoría de eso. En una aplicación que está, por así decirlo, terminada, no en el proceso de migración, no usarías ambos juntos. Recoil es una solución de state management producida por Facebook para resolver un problema muy particular y absolutamente podrías tener ese problema al construir una aplicación con Remix. Y entonces podrías usarlos juntos. Pero la típica aplicación CRUD que estás construyendo, no necesitas una biblioteca de state management ciertamente porque Remix gestiona el server cache para ti y todo lo demás funciona bien con el contexto. Se compara bien. Y luego también otro grande es Gatsby. Remix se renderiza en el servidor y sé que Gatsby ahora también puede hacer algo de renderizado en el servidor. Pero, sí, Remix toma un enfoque drásticamente diferente y creo que eso conduce a una mejor user experience.

Muchas preguntas sobre Remix. ¡Remix es lo mejor! ¡Lo amo! ¿Crees que está listo para una aplicación de producción a gran scale? Bueno, oficialmente no son de código abierto y técnicamente no hay forma de obtener acceso a él hasta que se conviertan en código abierto. Porque cerraron nuevas suscripciones y cosas así. Así que si quieres trabajar en ello hoy, entonces no. Pero en las próximas semanas, entonces ciertamente. Creo que definitivamente le faltan algunas cosas. No quiero hacer parecer que es la solución perfecta para todo, especialmente ahora. Pero esas cosas vendrán. Me emocioné con Remix cuando se lanzó por primera vez, de hecho, incluso antes. De hecho, compré la suscripción de prueba porque estaba tan ansioso. Y accidentalmente compré una suscripción de prueba por un dólar. Así que tengo dos suscripciones a Remix, en realidad. Pero sí, sabía desde el principio que Remix se basaba en un fundamento realmente sólido. Y que todos los huecos que había en Remix en ese momento, y algunos huecos que aún están allí, se llenarán fácilmente debido a la capa de abstracción en la que están operando.

Y habiendo trabajado en ello ahora para tu sitio, ¿cómo crees que se integraría con quizás una base de código code heredada? Creo que hay varios enfoques que puedes tomar para integrar Remix. Entonces, como, una cosa que podrías decir, vamos a empezar a hacer Remix para estas rutas, y luego vamos a tener alguna redirección allí, y será, como, una aplicación separada. Esa sería una forma muy fácil de hacerlo, pero también hay formas - Estaba hablando con alguien recientemente sobre la integración de su renderización PHP con Remix, y podrías totalmente hacer eso. Haz que PHP renderice algunas cosas. Remix renderizará algunas cosas en el servidor junto con eso y enviará todo ese HTML al cliente, y eso también sería posible. Así que tienes mucha flexibilidad.

Genial. Lo escuchaste aquí primero, gente. Antes de pasar a un par de preguntas sobre la resolución de problemas, Alex pregunta, ¿es el estiramiento parte de tu reunión diaria? No. No tengo reunión diaria, porque trabajo para mí y por mí mismo, es muy solitario. Pero - Estamos aquí para ti, Ben. Aprendí las sentadillas de aire de Ben Ornstein. Hace años dio una charla llamada cómo hablar con los desarrolladores, allá por 2013, creo, en RailsConf. Y fue una charla fenomenal. La recomiendo si quieres mejorar en hablar con los desarrolladores. Y eso fue una cosa que él hizo. Y yo, sí, lo tomé prestado de él. Maravilloso. Ahí lo tienes. Todos deberían intentarlo. He dado casi cien charlas ahora, y me pongo nervioso antes de cada una. Lo que te hace preguntarte, como, ¿por qué incluso hago esto? Pero las sentadillas de aire me ayudan a relajarme mucho. Así que gracias por complacerme.

Hablemos de problemas. Hastu pregunta, ¿cómo identificas un problema que necesita eliminarse sin haber pasado por X iteraciones de soluciones y problemas asociados antes de decidir que podríamos necesitar retroceder? Sí. Eso es complicado. Eso está relacionado con el problema del costo hundido. De ahí es de donde viene el término spike. Así que como que te pones un límite de tiempo que vas a pasar investigando una cierta solución o buscando soluciones a un problema. Sí, a veces es por eso que, como creo que es donde la financiación puede realmente ayudar a los emprendedores donde están como no estamos seguros de que esto va a funcionar pero creemos que lo hará. Así que danos algo de dinero para que nos dejes intentarlo y hay riesgo involucrado en eso. Y así esperamos que acabe funcionando o que aprendas lo suficiente para encontrar otra forma de hacer lo. Y algo relacionado es ¿tienes un conjunto de criterios o heurísticas que usas para evaluar un problema al decidir si abordarlo o eliminarlo? No realmente, normalmente creo que sólo necesita convertirse en una parte de tu rutina regular donde simplemente reevalúas tu espacio de problema actual y piensas bien, hombre, trabajé realmente duro en esa solución y todavía no he terminado con ella y sólo piensa como dar unos pasos atrás, ¿por qué tenemos este problema? Bueno, por esto. Bueno, ¿por qué tenemos ese problema? Por eso y sigue retrocediendo. Ahora, nos hemos quedado sin tiempo para algunas de las preguntas, pero un par de cosas, primero, ¿alguna otra mascota que venga o sólo será Cody? Bueno, hay muchos Emoji en mis masterclasses, tenemos a Marty la bolsa de dinero, eso podría ser divertido. Como bolsas de dinero para ti, pero no tengo planes para extras, Cody es mi favorito. Justo después de esto, Kent tendrá una sala de oradores para la gente en casa, puedes unirte en el chat espacial para la gente aquí, si quieres seguir charlando con Kent, síguelo después de esta charla. Justo después, también tendremos la sala de discussion híbrida justo en la sala de discussion. Gracias. Gracias.