Café con Tech

Testing, React, Typescript and Remix with Kent C. Dodds

July 20, 2021 Matias Hernández / Kent C. Dodds Season 3 Episode 1
Café con Tech
Testing, React, Typescript and Remix with Kent C. Dodds
Show Notes Transcript Chapter Markers

The first episode of this new special season, and what better way to start than having the one and only Kent C. Dodds

In this episode, we talk about different topics on web development, starting with how to "sell" testing to your project owner or manager, reviewing some React goodness and pitfalls, and more.

Summary

  • Testing is an important topic in the development process but: How to get it done right and actually do it in a project? In Kent's words: "Identify the company's mission and make the assumption that everybody is motivated to push that mission forward."
  • React is a state management tool.
  • Practical React is about giving you a deterministic way to manage and declare your state.
  • Composition and prop drilling are big tools when developing React applications.
  • Typescript can help you a lot when developing for the web.
  • Remix is cool, and we should keep an eye on it. 

Links


Music Credits

Opening and Outro Music by DanoSongs https://danosongs.com/

Background Music Music:
Cool Rock by Kevin MacLeod Link: https://incompetech.filmmusic.io/song/3552-cool-rock License: https://filmmusic.io/standard-license

Auth0
Auth0 es una plataforma de autenticación y autorización lista para usar en tu app!

Cloudinary
Distribuye tus experiencias digitales de forma rápida y sencilla.

Clevertech
Clevertech, code the life you want with remote done right. Check out our website clevertech.biz

Support the show (https://www.buymeacoffee.com/matiasfha)

Español

Matias: [00:00:00]
Bienvenidos a este primer episodio de Café con Tech en inglés. Hoy estoy con el único e inigualable Kent C Dodds. Kent, gracias por venir.  Gracias por aceptar ser mi invitado en este particular episodio que inicia su primera temporada.


Kent: [00:00:14]
Sí, me siento honrado de ser invitado. Es realmente genial y genial de tu parte tener un podcast en español y, y agradable de tu parte invitarme a hacer uno en inglés. Porque yo, , no comprendo mucho español. 


Matías: [00:00:33]
Eso es habitual. Además, creo que todo desarrollador latinoamericano debería aprender inglés de todos modos. Si quieres tener más puertas abiertas y subir de nivel en tu carrera, pero, para empezar, Kent, ¿puedes presentarte? No sé. Si alguien más necesita una presentación tuya, pero hagámoslo.


Kent: [00:00:56]
Estoy seguro de que hay mucha gente que no me conoce, pero, sí, mi nombre es Kent C. Dodds y vivo en Utah, en los Estados Unidos. Soy padre de cuatro hermosos hijos, marido, tengo un perro y enseño a la gente a escribir software de calidad. En particular, me enfoco mucho en React, pero también hago mucho Node. Así que prácticamente todo es JavaScript para mí.  He estado haciendo eso durante poco más de dos años, antes de eso fue PayPal y luego un par de otras empresas. He trabajado en bases de código realmente grandes y por eso conozco el dolor y la lucha. Trato de tomar esa experiencia que he tenido para ayudar a otras personas a aliviar algo de ese dolor y hacer del mundo un lugar mejor con lo que están haciendo.


Matias: [00:01:44]
Me gustó mucho esa cita, "Haz del mundo un lugar mejor con código. "En general, la gente tiende a pensar que sólo escribimos código, pero en realidad resolvemos problemas. Así que eso es lo que me ha gustado. Tengo una pregunta, en algún momento fuiste conocido como el chico de las pruebas, uh ahora eres más un chico de React en términos de pruebas. Y ya que has mencionado esto, que tienes experiencia con una gran base de código, ¿cómo puedes vender las pruebas a tus jefes? El testing es una especie de área gris que nadie quiere que hagas porque lleva tiempo, pero siempre es deseable tenerlo, porque mejorará tu proceso, pero ¿cómo lo vendes? 


Kent: [00:02:26]
Sí. Así que en realidad tengo una entrada de blog titulada, "Alineación de Negocios e Ingeniería", que es donde hablo de cómo conseguir que la gente de negocios haga lo que quieras. El truco es la parte de cambiar lo que quieres, para estar en línea con lo que la gente de negocios quiere que hagas. En realidad, se trata de identificar la misión de la empresa y suponer que todo el mundo está motivado para impulsar esa misión. Y si tienes gente que no está motivada para impulsar la misión, entonces, estás en un mal lugar de todos modos. Así que tenemos que asumir que la gente está motivada para impulsar la misión.

Kent: [00:03:24]
Así que identificas la misión y luego averiguas cómo puedes explicar a la gente de negocios que lo que quieres hacer va a impulsar mejor esa misión. Va a ayudarle en sus objetivos.  Y para poder hacer eso, primero tienes que convencerte de que esto realmente va a ser un retorno valioso de tu inversión de tiempo.

Kent: [00:03:40]
Y si no puedes convencerte a ti mismo, si realmente, después de analizarlo y pensarlo, estás como, oh, no sé, sólo estamos en la etapa de prototipo y no puedo convencerme realmente de que las pruebas son realmente súper valiosas ahora mismo en esta etapa, entonces eso es fácil. Usted ni siquiera necesita tener la conversación. Pero para la mayoría de nosotros, no estamos trabajando en una situación en la que las pruebas son innecesarias. La mayoría de nosotros estamos trabajando en una situación en la que necesitamos escribir pruebas. Su trabajo es ser capaz de tener un vínculo tan fuerte como sea posible entre las pruebas y la misión de la empresa. Así que puedes decir que si no probamos o porque no probamos, estamos teniendo todos estos errores que estamos enviando y debido a esos errores, no somos capaces de impulsar la misión tanto como nos gustaría. 


Kent: [00:04:41]
Así que podemos resolver esto muy fácilmente escribiendo pruebas. Puede que no sea fácil dependiendo de dónde te encuentres, pero la respuesta es bastante simple. La respuesta es bastante sencilla: se trata de hacer pruebas, pruebas automatizadas, para no tener que probar todo manualmente. Ahí es donde se reduce, sólo hacer o comunicar efectivamente con las personas que toman estas decisiones, los gerentes o lo que sea, que esta es una parte importante de su retorno de su inversión de tiempo y no hacer esto es peor que hacerlo. 


Matias: [00:04:56]
Sí, me gusta. Me gusta la idea de alinearse con la misión y vender la necesidad técnica de esto con más como la necesidad del producto. En realidad estamos resolviendo problemas y entregando productos. Así que debemos estar seguros de que estamos haciendo un buen trabajo allí, pero dejando de lado las pruebas, como siempre y todo el mundo, usted tiene una charla que siempre es interesante para mí. Y creo que ya la he visto como dos o más veces, en diferentes lugares. Y la que mencionaste que React es en realidad una herramienta de gestión de estados, no sólo una herramienta de UI. ¿Puedes resumir el concepto que quieres transmitirnos?


Kent: [00:05:38]
Sí, claro. Recuerdo que cuando empecé con React, una de las primeras preguntas que tuve fue ¿cuál es la diferencia entre props y state? Creo que mucha gente se lo pregunta al empezar. Y recuerdo haber encontrado este diagrama de flujo que Ryan Florence había hecho que describe esas diferencias. Desde el principio, React siempre ha sido capaz de gestionar el estado. Antes de entrar en React, pensaba que una gran parte de ello era que React te anima a no tener estado.


Kent: [00:06:37]
Así que tienes tu estado que vive fuera de React, y luego sólo pasas eso a React y luego, renderiza tu cosa basada en el estado externo. Y mientras puedes hacer eso, puedes hacer todos tus componentes sin estado y luego simplemente pasarlo a través de, eso es posible. Y este tipo de encarna el, ya sabes, UI como una función de estado, una cosa que mucha gente habla. Eso no es en realidad lo que es Reactor, no es Reactor práctico. Uh, es realmente acerca de la falta de estado, es más acerca de darle una forma determinista para gestionar su estado y una forma declarativa para interactuar con las cosas que cambian con el tiempo para que usted no tiene que pensar en ellos.


Kent: [00:07:21]
Y sólo piensas en ello basándote en el estado actual, aquí está mi UI actual. Y cuando esto ocurra, actualizaré el estado, pero no me voy a preocupar de lo que ocurra con mi IU en ese momento. Eso será un render completamente diferente y todo. Así que desde que React existe, siempre ha sido un gestor de estados. Desde el principio, la gente trató de añadir cosas a React para mejorar sus capacidades allí por varias razones que te encuentras cuando estás tratando de construir una aplicación a escala, como una aplicación realmente considerable, un término común es la perforación de prop. Y eso básicamente significa que estás manejando un, bueno, déjame dar un paso atrás.


Digamos que tienes este pequeño componente y es pequeño. Entonces estás construyendo esta aplicación, te das cuenta de que necesitas dividir las cosas en múltiples componentes. Entonces dos componentes hermanos necesitan acceder al mismo estado. Así que sólo tienes que mover ese estado hasta el padre menos común y eso es lo que llamamos levantar el estado.


Con el tiempo, a medida que continúas levantando lentamente al estado, eventualmente vas a tener algún estado que viene de la parte superior, como todo necesita acceder a este estado. Así que cuando lo estás haciendo tienes todas estas diferentes capas de componentes, tienes que pasar los accesorios hacia abajo a los componentes que lo necesitan.


La verdadera frustración es cuando tienes un componente que está muy abajo en el árbol de componentes de Reactor que necesita un estado que está muy arriba en el árbol de componentes, pero ninguno de los componentes entre esos dos lo necesita. Y así, todos los demás componentes entre estos son sólo pasar a lo largo de accesorios que ni siquiera necesitan a sí mismos.


Es que hay una relación entre los bisabuelos y el bisnieto. Eso puede ser frustrante. Esto es lo que llamamos "prop chilling", y no sólo tienes que pasar el estado, sino también el mecanismo para actualizar el estado. Sí, eso hace que sea un poco molesto tener que pasar esas cosas.


Creo que este fue probablemente el mayor desafío que llevó a la gente a empezar a explorar cosas fuera de react para la gestión de estado. Podemos hablar de eso un poco más, pero la, la otra cosa que creo que motivó a la gente a llegar fuera de react fue cuando Facebook salió con su idea detrás de flujo, que es una forma de gestionar el estado donde usted tiene este mecanismo para enviar un evento que usted maneja un evento que despacha, , en algún otro evento con alguna carga útil y luego que se establece en algún estado y luego que se propaga a través de toda la aplicación. Y, y hay varios beneficios a este enfoque y varias compensaciones que este enfoque hace, , que sólo descubrimos después de que todos se subieron a este, flex que la balsa, bajando el río, no nos dimos cuenta de que alguien se olvidó de la orden o algo así.


Todo el mundo decidió que esta es la única manera. Y entonces esta es la manera de reaccionar cuando realmente no lo es, la manera de reaccionar siempre ha sido, , tu, tu manejas el estado dentro de un componente. Si un hermano lo necesita, entonces usted levanta el estado y si ningún hermano lo necesita y sólo un hijo lo necesita, entonces empuja ese estado en el hijo.


No hay razón para que exista fuera de esa situación. React siempre ha sido una librería de gestión de estados. Pero debido a estos problemas, buscamos otras cosas y ahí es donde entró Redux, porque resolvió ambas cosas. Era una implementación de Flex, o una implementación parecida a la de Flux y, usaba la API de contexto no oficial.


Uh, que en los documentos de react, fue documentado, pero tenía esta gran advertencia que era aterrador que decía, ya sabes, no use esto, va a cambiar todo. Así que la gente no quería, pero literalmente todo el mundo era porque estábamos usando react router y que estaba usando. Probablemente estábamos usando un proveedor de temas CSS y JS que lo estaba usando.


Y luego Redux lo estaba usando. Y así todos estamos usando esta API para resolver el problema de la perforación previa. Y, y en realidad había algunas otras implementaciones mucho más simples de la API de contexto que utilicé. Hubo uno llamado react broadcast por Michael Jackson que realmente me gustó.


Fue increíble. Sólo para que sea más fácil para obtener su estado de uno de la parte superior del árbol hacia abajo, , Pero, sí, así que yo, yo usé Redux por un tiempo y, por el tiempo suficiente para mí para darse cuenta de que no estaba super feliz con él. Terminé abriendo como 30 archivos para hacer un solo cambio. Uh, no disfruté de eso en absoluto.

Sólo lo he utilizado para un proyecto. Tampoco lo elegí para ese proyecto. Entré en el proyecto que ya lo tenía, y luego cualquier otro proyecto después de eso, ese fue el único proyecto con el que usé Redux sólo porque vi que resolvía muchos problemas. pero si cambio mi enfoque, no tengo esos problemas.

No necesitaba preocuparme por ello. Así que de todos modos, eso es, eso es una larga manera de decir que sí, reaccionar es un gestor de estado.


Matias: [00:12:15]
Mencionaste dos cosas que quiero como gritar, esta idea de, no necesitas resolver el problema que simplemente no tienes, o simplemente no lo declaras que tienes, y la gente tiende a, o solía pensar que la perforación de prop es un problema. Así que tenemos que resolverlo incluso antes de tenerlo y usamos redux y cualquier otro, un montón de posibilidades allí. Pero en realidad hay otro concepto que es nativo de Reactor, que es la composición. Y siento que sí, los estudiantes y los principiantes en realidad no utilizan la composición en absoluto. Es como los niños bajo los niños bajo los niños, pero no hay otra idea allí, su composición. ¿Puede usted, tipo de, , hablar de eso.


Kent: [00:12:59]
Sí, sí, absolutamente. Así que, y estoy bastante seguro de que mencioné esto en la entrada del blog. No lo hice originalmente, y lo añadí después porque era una parte evidente, que faltaba en esa entrada del blog. Así que la composición es como, digamos que usted está construyendo un poco de interfaz de usuario basada en el chat y quiere tener, no sé, usted está manejando un poco de estado en el nivel superior que dice que los usuarios están actualmente conectados. Y luego tienes esta barra lateral aquí que enumera esos usuarios y tiene que estar en el nivel superior porque también tienes otra cosa que indica el recuento total de personas que están actualmente conectadas o algo así. Así que eso tiene que estar más arriba en el árbol. Pero, pero tienes dos cosas, dos componentes que están más abajo en el árbol que necesitan acceder a estos datos. Así que una cosa bastante natural que la gente hace cuando están escribiendo reactores es que tienen un componente que hace esta cosa, y luego esos, esos componentes hacen esta cosa y, y esos componentes hacen esto, estas cosas.


Y así, cuando haces cosas así, naturalmente tienes que apuntalar el taladro. Así que tienes que pasar este valor hacia abajo a ese. Luego hacia abajo a ese y hacia abajo a ese todo el camino hasta llegar a donde estás. Sin embargo, ¿qué pasa si en lugar de, , y, y a menudo estos otros componentes son una especie de raperos y a menudo son como componentes de diseño. Uh, por lo que es como, bueno, tengo mi, mi barra lateral, pero eso es dentro de mi nav principal para algo así. Y entonces, , y por lo que hacen que el principal responsable de la representación de la barra lateral, , donde en realidad no hay estado siendo gestionado por el principal. No hay nada que diga que tiene que ser el responsable de la barra lateral. Así que si, en lugar de decir, Hey, voy a renderizar el principal y que es responsable de la disposición. Y luego, , voy a pasarle lo que quiero que ponga en él como los niños para ese diseño. Así que voy a ser responsable de decir lo que usted renderiza en las diferentes partes de lo que usted está poniendo.


Esto significa que el componente de nivel superior puede renderizar la barra lateral por sí mismo. Y así no hay perforación de prop, , de ningún tipo, porque el componente de nivel superior puede simplemente pasar esas indicaciones directamente al componente que lo necesita. Uh, es un poco difícil describir esto de forma audible. Así que, , el blogpost tiene un ejemplo, y, y en realidad hay un video de Michael Jackson donde explica esto muy bien.


y, y en realidad Michael Jackson hizo ese video porque, él estaba haciendo la sugerencia de que,, la mayoría de las aplicaciones no necesitan contexto en absoluto. ...lo cual creo... Usted podría ser capaz de salirse con la suya, , tal vez, pero no lo hago. Creo que la mayoría de las aplicaciones probablemente tienen al menos uno o dos casos de uso útil para el contexto, pero en espíritu es correcto.


El contexto es útil sobre todo para las bibliotecas, lo que creo que es el caso. Pero, de todos modos, si como, como usted dijo, también, , si usted cambia su enfoque de la, sólo la forma en que usted está escribiendo sus componentes, entonces usted puede simplemente eliminar el problema de la propulsión por completo y usted no tiene que llegar a contexto.


Y, y la otra cosa que, que reaccionó para ayudar a eliminar el problema de la perforación rápida, o al menos, reducir el impacto de, de prop babeo es haciendo contexto oficial y hacer que sea una API bastante sencillo de usar en relación con lo que solía ser, , antes de ganchos y esas cosas. 


Matias: [00:16:33]
Eso fue realmente útil.

Y al mismo tiempo, creo que fue una especie de daño al concepto de composición en términos de como un contexto tan fácil de usar que sólo lo utiliza y la gente va a empezar a caer en los mismos patrones que con redux, como, era tan fácil de empujar todo lo que se hace sólo con él. Pero por alguna razón, la composición no es ni siquiera enseñado por los instructores de todo el mundo, como el uso de este patrón de render prop como, porque es una especie de similar donde se pasa el componente como un prop, no los datos. ¿Y por qué crees que es tan difícil enseñar o aprender la composición y utilizarla realmente? Y porque he estado en un montón de proyectos de React y sí, este no es el patrón. Esto es, puedes encontrarlo, pero no es lo habitual 


Kent: [00:17:28]
Sabes, tienes razón. Y en realidad, no creo que haya hablado de ello directamente ni siquiera en mis propias cosas. Lo uso de forma natural en la forma en que construyo cosas, pero no lo enseño específicamente. Y eso cambiará en una próxima versión de epic react. Voy a incluir una sección sobre el aprovechamiento de la competencia. Porque esa es una de las cosas geniales de Reactor. Así que eso es como una de las principales características clave


Creo que veo los componentes de react como funciones, que son, por supuesto, pero, incluso el JSX que veo es como las funciones que usted está pasando estos argumentos a estas funciones y no realmente a menudo aprovechar la composición, incluso en nuestras funciones. No tan fuertemente como lo ves cuando estás aprovechando la composición con react, donde sólo pasas esta función y pasas esta llamada a esta función, a esta otra función y cosas por el estilo. Creo que hay algo en nuestros cerebros, se siente más natural decir, bueno, aquí está este bloque de cosas.


Voy a poner esto en una función. Y ahora esta función es responsable de este bloque de cosas donde en realidad esa función sólo está a cargo de lo que una parte de eso y el resto se puede pasar como un argumento. Creo que ese es el gran desafío allí es que no parametrizamos lo suficiente cuando se trata de nuestro componente, 

Matias: [00:19:00]
Es una especie de modelo mental que vienes con un modelo mental imperativo, como la mayoría de nosotros. Y luego hay que cambiar un poco, como en el camino de la programación funcional, como declarativo, más donde la composición es una especie de rey, pero estamos tipo de caer en el medio con JavaScript y reaccionar en sí. 


Kent: [00:19:24]
Sí, yo diría que, que una de las cosas más interesantes de JavaScript es su flexibilidad para, , atender a los diferentes casos de uso de la gente para la forma en que les gusta escribir su código, , ya sea funcional o, , orientado a objetos o, o lo que quieran.


Y así, , Porque JavaScript es tan flexible de esa manera, pero también, porque es tan omnipresente para bien o para mal, es el lenguaje de la web. Y es el lenguaje más popular en el mundo y la gente tiene que usarlo quieran o no. En muchos casos, tienes un montón de gente con diferentes antecedentes y preferencias, de lo que sería en, en un diferente, un lenguaje en una plataforma diferente.


porque no sólo están en diferentes entornos, sino que también están desplegando a diferentes objetivos y tienen diferentes casos de uso y, y todo tipo de cosas. Así que ninguno de ellos está necesariamente equivocado. Son sólo, son sólo diferentes casos de uso y diferentes preferencias. Y creo que debido a eso, tenemos una gran variedad de, , de, sólo la forma en que la gente escribe su código.

, cuando están ejecutando javascript 


Matias: [00:20:33]
Tiene sentido. Avanzando con esta parte de la cosa del estado, tema, en la charla y, y otros lugares que son una especie de apoyo muy duro en la consulta de reacción y diciendo básicamente lo mismo que Tanner ha dicho o Tanner dijo lo mismo que hiciste, No sé - que el estado es en realidad dos naturalezas diferentes.

Uno es la interfaz de usuario y reaccionar es una herramienta y uno es un estado del servidor que o caché que es reaccionar herramienta de consulta. Así que entiendo que su reac-query es su atasco aquí. Y, pero puede poco describir esta diferencia entre la naturaleza del estado? 


Kent: [00:21:10]
Absolutamente. Descubrí o empecé a pensar en esto, tal vez hace dos años, cuando me di cuenta de que podríamos simplificar drásticamente nuestro estado de la interfaz de usuario si no tratamos el estado del servidor como su estado de la interfaz de usuario.


Y abrazar el hecho de que el estado del servidor es un efectivo. Y así Tanner y yo, Tanner vive muy cerca de mí en realidad. Y así que estábamos almorzando y él estaba hablando de esto antes de crear la consulta de react. Y él está diciendo que he estado construyendo algunas utilidades realmente interesantes para, para mi aplicación en el trabajo.


y hablamos de ello un poco, y luego salió con react query y fue un cambio de juego para mí. Sí, sólo cuando se separa su, lo que, por lo que en primer lugar, cuando usted abrazar el hecho de que su estado del servidor es una caché, , en lugar de, es sólo un estado que necesita para mantener actualizada, que hacer un par de cosas diferentes.


Así que una cosa que hice mucho antes fue, , cuando yo haría una actualización de, así que permítanme dar un paso atrás cuando, cuando usted está construyendo algún estado de la aplicación, algunas cosas de la interfaz de usuario, olvidando el servidor, cuando hay una actualización, se actualiza ese valor en la memoria. Así que usted está diciendo establecer el estado o establecer, , estado modal o lo que sea que usted está, usted está actualizando.


 Y así es como operamos de esa manera cuando estamos. Así que cuando traemos en el servidor y estamos empezando a hablar sobre el estado del servidor, sólo tipo de sensación natural para seguir adelante y actualizar ese estado y luego tal vez tener un useEffect o algo que vamos a actualizar en el backend.


...y más a menudo lo que terminamos haciendo es decir, no, no quiero tener una inconsistencia aquí. Así que voy a decir, ir a hacer esta solicitud de obtención para ir a actualizar esto. Y entonces me devolverá el nuevo estado y actualizaré mi estado local para que sea el nuevo estado. Y, en realidad, Apollo hace esto mucho, no, no es para criticar a Apollo ni nada.


Están resolviendo grandes problemas, pero tratan de mutar su caché para que coincida con lo que reciben del backend.  Y react query tiene un enfoque diferente.  Creo que, como, usted debe ser capaz de, para hacer que el trabajo, pero reaccionar consulta sólo dice, oh, usted hizo una mutación. Déjame ir a buscarlo de nuevo.


porque aceptas el hecho de que es un caché y, cuando haces eso, tienes que decir, tan pronto como obtengo estos datos, son obsoletos. Está mal. Uh, sólo, aceptas ese hecho. Y así estoy haciendo una solicitud adicional para ir a decir, de acuerdo, hice una mutación, déjame ir a obtener lo que el estado actual es y poner todo eso dentro de la consulta de reacción como un paquete significa que usted no tiene que preocuparse por mantener ese estado hasta la fecha a ti mismo.


Y así se simplifica drásticamente la gestión de sus cosas. Yo solía tener, como estos proveedores de contexto realmente grandes que tenían todos estos métodos diferentes o que estaban en un reductor, todos estos diferentes, ya sabes, cosas de reductores de declaraciones de conmutación para gestionar como, oh, lo agregué para hacer lo que tengo que empujar a la, la lista de matrices o lo que sea, pero con react query, ahora sólo digo seguir adelante y agregarlo a la API de backend y luego react query se encarga de obtener el estado fresco para mí. Este enfoque tiene sus desventajas, pero también hay formas de evitarlas, pero me gusta el valor por defecto que me da react query, que me hace más correcto.


Y, , porque he movido todo el estado del servidor a esta caché. Ahora lo que me queda para el contexto o la composición o lo que sea es muy simple. Y si estoy co-localizando mi estado, a menudo ni siquiera necesito algunas de esas cosas en un proveedor de contexto, simplemente lo pongo en el área de la aplicación que se preocupa por ese estado.

Y así, sí, el, , react query ha sido fenomenal para mis aplicaciones del lado del cliente. Realmente no lo uso mucho para cosas como remix, , porque remix elimina los problemas que react query resuelve. Y podemos hablar de eso si quieres. Pero, , para, si estoy haciendo una aplicación del lado del cliente, , cien por ciento, voy a estar usando react query. Me ahorra mucho tiempo. 


Matias: [00:25:11]
Sí. Una de las cosas que me resonó fue esta diferencia de que básicamente un estado de la UI es síncrono y el estado del servidor o de la caché es asíncrono, y tienes todo el paquete en una solución realmente genial e inteligente. Así que no tienes que preocuparte por la sincronización de esos datos.


Y entonces sólo te preocupas de tu propia lógica, básicamente, porque los estados del servidor no son tu lógica, pertenecen a otro lugar. Así que eso me resuena mucho. Uh, sí. Quiero preguntar sobre el remix también, pero tengo mucha curiosidad, pero tengo otra pequeña pregunta ahí y estoy seguro de que recibes esta pregunta muchas, tantas, tantas veces que ya tienes un post sobre ello.


Uh, pero de todos modos, bueno tienes un post para casi todo junto con un gif. UseEffect es tan complejo como para que la gente simplemente suelte las dependencias en el useeffect y sólo siga las reglas. Como, eh, como tienes otra charla. Creo que se llama, "common react pitfalls" donde bromeas como las reglas de LinkedIn es Diana Vermont diciendo, usa estas cosas críticamente. 


Eh, lo sé, eh, Por qué, por qué la gente sólo, por qué usted, si usted piensa que es tan difícil de seguir estos efectos, la sincronización o permanecer sincronizado por el móvil, que el uso de efecto necesidad. 


Kent: [00:26:46]
Creo que hay varias razones por las que la gente se esfuerza por seguir la regla del linting. Si ya tienes experiencia con react, entonces tu reto es desaprender. Con esto quiero decir que si tienes experiencia con los componentes de clase de Reactor, estás pensando en los componentes de Reactor de una manera antigua. La forma en que solíamos pensar en ellos era ciclos de vida. Y entonces piensas, bien, cuando el componente se monta, y luego cuando el componente se actualiza, entonces cuando el componente se monta, quiero que estas cosas sucedan.


y con efecto de uso. Porque realmente no funciona de esa manera. Tratamos de hacer que funcione de esa manera, porque estamos pensando en, la forma en que, solíamos, pensamos en los componentes y los ciclos de vida, pero esa no es la manera de pensar en esas cosas. Así que, creo que es uno de los, los principales para las personas que han tenido experiencia con react ya, , es que están tratando de doblar el efecto de uso para operar en los ciclos de vida, , en lugar de sincronizar el estado del mundo con el estado de la aplicación.

...así que otra razón es que... ...a veces no entendemos o la gente no entiende cómo funciona la matriz de dependencia. ...así que el hecho es que tienes una matriz que proporcionas al efecto de uso y, cada vez que cualquiera de esos elementos cambia, incluso si es la misma forma exacta de un objeto, si es un objeto nuevo, va a desencadenar una repetición de tu efecto de uso.


Y si no entiendes eso y ves que tu efecto de uso se está ejecutando una y otra vez, vas a decir, bueno, vale, no importa. Yo sólo, , voy a apagar la regla y entonces tu, cuando apagas la regla, estás encendiendo un error. Eso es, eso es realmente lo que es. ...es como encender el modo de bicho, supongo, si quieres pensarlo así.


, pero, Pero su gente está haciendo esto porque están terminando con un bucle infinito porque se utiliza efecto llamado set state o algo así. y, o incluso peor que está llamando a una API y luego llamando a set state. Y así, si usted tiene, una dependencia siempre cambiante, usted es sólo para siempre llamando a esta API y luego se obtiene la tasa limitada o algo así.


Me gustaría poder decir que nunca he hecho eso antes. Oh, sí. Todos lo hemos hecho. Sí. Así que sí, nos gusta, quitamos las dependencias por desesperación, , por eso. Y es porque no entendemos que, ya sabes, , cuando creas un nuevo objeto, estás creando, incluso si todas las propiedades son las mismas, estás creando una nueva referencia a, una cosa completamente diferente.


...y es, honestamente, bastante complicado. Y tienes que tener una buena comprensión y como, Por un lado, si no tienes una buena comprensión de la forma en que JavaScript funciona y cierres y, ya sabes, , JavaScript pasa por valor y cosas por el estilo, entonces, , , entonces es sólo una cosa que está en su camino, y usted no entiende por qué está causando tantos problemas y eso es, eso es frustrante.


Uh, así que no, realmente culpo a la gente por querer apagarlo y seguir con la vida. ...pero como dije, están encendiendo, en modo difícil, modo negro. ...pero, sí, el otro... El punto de todo esto es que creo que el uso de hecho es un nivel muy bajo primitivo. ...y lo que es realmente impresionante acerca de los ganchos en general es que nos da la capacidad de abstraer las cosas muy bien de una manera que nunca podríamos con los componentes de clase.


Probamos con, con accesorios de renderizado y componentes de orden superior y esas cosas, pero, y, y eso realmente funcionó bastante bien. Yo estaba bastante feliz con los accesorios de renderizado. Uh, en general había, había diferentes problemas con él, pero cuando los ganchos llegaron, , tantos problemas fueron simplemente eliminados porque ahora podemos compartir el código de la misma manera, compartir el código de react y la lógica de react de la misma manera que compartimos cualquier otro código y eso es haciendo una función y lo llamamos un gancho personalizado, pero es sólo una función que utiliza otros ganchos.

Eso es todo lo que es un gancho personalizado. Y así, yo, me estoy encontrando con el uso de efectos cada vez menos como estoy usando otros, bibliotecas. ¿Y qué es lo bueno de eso? Soy un autor de la biblioteca, por lo que es bueno para mí para entender cómo funciona todo esto, pero el más,, buenas abstracciones que construimos, menos la gente realmente tiene que utilizar, utilizar afectar a sí mismos.


Y, y muchas de las veces que estoy viendo en mi comunidad de discordia o en línea es, la gente está usando el efecto de uso para hacer un montón de las mismas cosas para las que hay bibliotecas desarrolladas que, , Sugiero que la gente use, , react query es un ejemplo perfecto de esto. Así que mucha gente está usando react query o use, , haciendo llamadas fetch ellos mismos y cosas así.


Cuando digo, ¿por qué no usas react query? Uh, y entonces no tienes que preocuparte por las dependencias. Y otra cosa sobre el efecto de uso que hace que sea un poco difícil es que tan pronto como se abstrae algo, fuera de un componente. Así que usted está tratando de hacer su propio gancho personalizado o algo así.


Si esa lógica está usando el efecto de uso, entonces algunas otras cosas se vuelven complicadas también, porque ya no tienes acceso directo a las variables que, ese interno podría estar usando, especialmente si, , estabas, si quieres que sea abstracto, como lo que sucede en el uso de hechos con algún tipo de devolución de llamada o algo así?

Uh, porque ahora, usted no puede poner la devolución de llamada directamente en el uso de hecho, ¿quieres generar eso? Y entonces ahora tienes que aceptar eso como un parámetro. Y ahora, a medida que las cosas se rerenderizan, ese callback podría cambiarse, podrías terminar con un kosher más cercano. Así que tienes que memorizar eso o, o tienes que usar este último patrón de ref.


Así que la abstracción del efecto de uso es creo que otra cosa que, , hace que la matriz de dependencia, y no es sólo el efecto de uso, también se utiliza memo y que acaba de llamar de nuevo, pero hace que la matriz de dependencia un poco difícil, , porque. No se puede simplemente inline cosas. Estos ganchos son, funcionan mucho más fácil si sólo inline todo, pegar todo lo que necesita directamente en esa devolución de llamada.


...pero, sí, es, es genial porque cuando tienes, cuando entiendes esas cosas, puedes construir algunas abstracciones realmente impresionantes que no puedes hacer antes. Por eso digo que el efecto de uso es una primitiva de bajo nivel sobre la que puedes construir otras abstracciones geniales para que la mayoría de la gente no lo haga, incluyéndote a ti mismo, para que no tengas que preocuparte de usar efectos de uso en tu código de aplicación normal.


Matias: [00:33:25]
Sí. Dos preguntas. Uh, ¿tienes algún recurso en particular con consejos y trucos para moverse con el efecto de uso, como el uso de una visión condicional del hecho sólo para evitar, para sacudir ese valor particular o lo que sea. Y segundo, ¿crees que el efecto de uso es de alguna manera una escopeta. Dispara a las armas. Dispara. 

Kent: [00:33:44]
Sí, sí.

Pistola de pie. Sí. Así que primero tengo algunos artículos muy buenos sobre epic react. Si vas a epic react.dev/articles, , así como en mi propio blog, Kent C dodds.com/blog, , donde hablé de usar efectos y también usar memo y, y, usar callback, también. Esos son, similares debido a la dependencia your'e situación.


...así que sí, esos son algunos recursos realmente buenos. Uno de ellos en particular es el, bueno, ahora debería, debería buscarlo. Así que te doy el título correcto. Es cómo react utiliza los cierres. Sí. Cómo react utiliza los cierres para evitar errores. Y eso describe la diferencia principal entre los componentes de clase de Reactor y los ganchos, y cómo Reactor ha cambiado el valor por defecto. 


Puede parecer que es más difícil, pero termina ahorrando un montón de dolor, en el largo plazo. Uh, y luego también tengo otra entrada de blog en allí atado a la última ref patrón en reaccionar, que resuelve muchos de los problemas que la gente encontraría, cuando están tratando de hacer algo similar a lo que solíamos tener en, , en componentes de clase.


En realidad es un patrón muy simple. ...pero es muy poderoso cuando construyes abstracciones. ...pero, sí. Así que tu, tu segunda pregunta sobre por qué es un uso efectivo de la pistola de pie. 


Matias: [00:35:17]
si crees que es porque sí, la API de nivel inferior es realmente difícil de usarla, pero al mismo tiempo es inferior, pero es, es describirla como una de las básicas que necesitas aprender para desarrollar realmente una agregación.

Así es, 


Kent: [00:35:32]
Sí. Sí, eso es cierto. Yo diría que el efecto de uso es, es relativamente avanzado, pero el hecho es que es muy simple. Como podría, podría explicarte lo que es el efecto de uso en dos o tres frases y cubrir todo. porque es una cosa relativamente simple. El reto es que, , en la aplicación práctica, puede ser difícil de hacer bien.


Uh, y, y no es fácil. Se basa en, , varios conceptos que la gente no tiene super, , clavado cuando están trabajando con JavaScript. ...y porque, o, perdón, déjame decirlo de otra manera. Se basa en, , o en ser capaz de usarlo efectivamente. Depende de lo bien que entiendas estos conceptos fundamentales de JavaScript.


Y así, si no entiendes, el hecho de que el render realmente recuerda tu función y lo que eso implica sobre las, funciones que estás creando dentro de tus componentes, así como las variables que estás creando dentro de tu componente. Sí. Si usted no tiene esa comprensión, entonces puede ser absolutamente una cosa difícil de hacer bien. 

...entonces, ¿es un arma de pie? Sí, tal vez, , potencialmente, pero creo que sigue siendo el enfoque correcto. Sólo porque algo sea difícil no significa que esté mal, , que puedas encontrar lo correcto encontrando lo que es simple porque no puedes construir una aplicación simple con abstracciones realmente complejas.


Es que eso no se puede hacer. Sin embargo, puedes construir una aplicación simple con abstracciones simples y, , y también puedes construir una aplicación compleja con abstracciones simples. No es como una bala de plata o algo así, pero, sí, si tienes simples, , primitivas, entonces puedes construir una aplicación simple a partir de eso y puedes construir abstracciones simples sobre ella.


Eso es lo que creo que es el efecto de uso, está destinado a. Vamos a proporcionar algo que es simple. La idea es sincronizar lo que ocurre fuera de Ray o sincronizar lo que ocurre dentro de react con cosas que están fuera de react. Ese es todo el objetivo de use effect.


Y, , y luego la gente puede construir en la parte superior de eso, para, para hacer buenas abstracciones para que la mayoría de la gente no tiene que trabajar con el perímetro de bajo nivel. 


Matias: [00:37:54]
tiene sentido. Quiero saltar a otro tema antes de que se acabe el tiempo y que te metas de lleno en TypeScript. Yo soy un desarrollador de JavaScript desde hace mucho tiempo, pero ahora te estás moviendo a, eh, lo que la onda nos da.


Eso es TypeScript. Todo el mundo está escribiendo TypeScript ahora mismo. Así que la pregunta es realmente sencilla. ¿Por qué escribir TypeScript? ¿Por qué TypeScript? 


Kent: [00:38:19]
Sí. Sí. Así que en realidad he estado usando TypeScript durante, , Tres o cuatro años. , pero yo, yo decidí durante mucho tiempo, hace mucho tiempo, y en realidad antes de que era el flujo. , Yo uso el tipo de flujo en PayPal durante mucho tiempo.

...pero, sí. , creo que reaccionar todavía está escrito en el flujo y esas cosas, pero sí, eso fue los únicos. Sí. Sí, de verdad. Así que sí, decidí no añadir tipografías a mi material de código abierto y a mi material educativo, porque no quería que fuera una barrera para que la gente se metiera en él. especialmente para el código abierto.

Simplemente sentí que no, no quiero limitar la gente que puede, participar en mis cosas de código abierto a los que saben TypeScript, porque hay menos gente que sabe TypeScript. La cosa es que. Y la gente que sabe TypeScript también sabe JavaScript, pero la gente que sabe JavaScript no necesariamente sabe TypeScript.


Así que si voy con el mínimo común denominador, puedo llegar a más gente tanto en mi código abierto, como en mi material educativo. Pero hace unos meses cambié mi forma de pensar después de hablar con Ryan Florence, porque me dijo que estaban empezando a pasar su material a TypeScript.

Y yo dije, bueno, ¿y esto? Y él dijo, por qué. Cuando nos pusimos a dar estos talleres, dijimos que quién usaba TypeScript y literalmente todo el mundo levantó la mano. Y, , y además, mientras ayudábamos a la gente a trabajar en los ejercicios y otras cosas, vimos que, estaban realmente confundidos cuando no tenían autocompletado para diferentes cosas básicas.


Y fue realmente frustrante para ellos. Y si lo haces bien. para el material educativo, puedes hacer que, para los estudiantes, TypeScript es mayormente opcional. ...así que configuras TypeScript para no tener que escribir todo, ya sabes, cualquiera está bien, lo que sea. Y así, si soy un desarrollador de JavaScript normal, la única diferencia para mí es que el archivo termina en punto TSX.

Todo lo demás es igual. No tengo que preocuparme por ello. Uh, y luego además de eso, si hay, , utilidades que son proporcionadas por, el, como parte del material que estoy llamando a esta función, estoy recibiendo auto-completar, que es realmente útil. Uh, incluso si sólo soy un desarrollador de JavaScript regular y no me importa sobre TypeScript.


Y así, si configuras las cosas, bien, , incluso los alumnos no tienen que saber TypeScript para poder utilizar un taller que está principalmente en TypeScript. Y, en el lado abierto, me he estado diciendo a mí mismo esto durante mucho tiempo que, mi preocupación sobre, TypeScript siendo una barrera de entrada, era simplemente falso, porque espero que la gente escriba pruebas, además de implementar lo que sea que estén haciendo y el script táctil es sólo pruebas.


Al final del día, eso es, eso es todo lo que es. Y así que ya estaba esperando que la gente, como yo ya tenía una barrera de entrada en el lado de la prueba de las cosas,, aprender a añadir algunos parámetros y esas cosas. ...ya sabes, tipos perimetrales y cosas así, no es mucho pedir. Concedida la biblioteca, TypeScript es mucho más difícil que el script de tipo de aplicación.


Así que veremos cómo se desarrolla todo esto, pero, y tal vez hay algunas personas que ya han tratado de contribuir a mi material de código abierto y decidieron no hacerlo, porque era TypeScript y me siento mal por eso, pero al final del día, el, el producto final es mucho mejor para la gente. Así que estoy bien con el intercambio porque lo bueno de TypeScript es que sí, son pruebas, pero también son pruebas que puedes entregar a los consumidores.


...porque las definiciones de tipo también están ahí, así que... sí, eso es... sí. Sí, es fantástico. Me encanta ser un consumidor de mis propias cosas ahora que todo está muy bien escrito. ...así que sí, ahí es donde ha estado el cambio públicamente. ...pero sí, he estado usando JavaScript mecanografiado durante mucho tiempo y, y, me parece obvio, realmente como es.

En realidad, nunca me gustó trabajar sólo en JavaScript después de que empecé a usar Flo y TypeScript en PayPal hace varios años. Pero lo hice por esas razones y no lo hago ahora por esas otras razones. 


Matias: [00:42:35]
Sí. Tu ordenador escribiendo TypeScript y luego volviendo a jugar con JavaScript.


Es algo así como, volver a los noventa. Sí, no, nunca más. Una pregunta más con TypeScript. Eh, ahora estás creando entradas de blog de material, principalmente con TypeScript. ¿Crees que vas a trasladar Epic React a eso también?


Kent: [00:42:54]
Absolutamente. Todo lo que estoy haciendo se está moviendo a TypeScript.

Así que, , probando javascript.com también será todo TypeScript cuando haya terminado. Uh, y epic reacts será todo TypeScript. Uh, antes de actualizar cualquiera de esos, sin embargo, estoy trabajando en un par de talleres de TypeScript, , porque quiero, para las personas que simplemente no tienen experiencia con TypeScript o que quieren subir de nivel su TypeScript, quiero darles un lugar para ir antes de ir a través de epic react y, y pruebas de JavaScript.


Así que puedo, por lo que si dicen, Hey, no puedo ir a través de epic react. No sé un TypeScript. Puedo decir, bueno, no, pasar por esto primero. Y entonces usted puede ir a través de epic react. No será un problema. Así que, , bueno, lo que estoy haciendo ahora mismo es que estoy actualizando todo el material y luego voy a hacer una, una especie de pequeña encuesta sobre mi material y ver qué características de TypeScript estoy usando.

Y me aseguraré de incluir todo eso en, estos tipos de talleres agarrados que la gente puede pasar primero. 


Matias: [00:43:52]
Bien, bien. Eso va a estar muy bien. , para terminar, creo que este rodaje para remezclar.


Kent: [00:43:59]
Sí. Me encantaría hablar de la remezcla. ¿Qué quieres saber? 


Matias: [00:44:03]
Uh, pero básicamente todo lo que no era capaz de, lo siento, mi llamada, lo siento, Ryan. No pude finalmente comprar mis propias lecciones en ese momento. , pero lo haces así puede, puede tipo de resumir de nuevo y es corto en, es sólo LD, pero ¿por qué remezcla tiene tan emocionado, como, para mí, es una especie de similar en algún momento acabamos de hablarlo por lo que yo sé, pero sí, soy todo oídos aquí.


Kent: [00:44:31]
Así que tengo cero experiencia con el kit de fieltro. Y en realidad tengo una experiencia bastante limitada con Next JS, con el que mucha gente compara la remezcla. Pero por la experiencia que tengo, no se parece mucho a Next JS. A mí me gusta. Hay mucha coincidencia en los casos de uso que pueden manejar, pero son bastante diferentes en muchos aspectos.


La cosa que, el elefante en la habitación, así que voy a abordar que rápidamente es, remezcla tiene licencia, , software donde usted tiene que comprar una licencia para utilizar el software. Esto va a eventualmente planear, tener un período de prueba para eso. Sé que mucha gente está realmente frustrada porque no hay manera de probarlo y ver si, si te gusta.


Uh, así que están planeando tener un período de prueba eventualmente. , pero en este momento son, son todavía . ...y por eso están ahí. Uh, centrándose en las personas que, , están dispuestos a pagarles para, , para trabajar en él para que puedan alimentar a sus familias y esas cosas. 


Matias: [00:45:35]
Creo que es un código abierto bastante impresionante para el modelo.


Kent: [00:45:40]
Estoy totalmente de acuerdo. Mucha gente se siente como si hubieras ofendido a su madre cuando sugieres que un software como este debería ser de pago, lo cual no entiendo en absoluto, pero, , sí. Algunas personas se sienten así. ...pero, sí, así que la remezcla, ¿por qué es tan impresionante? Me encanta la remezcla porque siento que abraza los fundamentos de la web de la manera que, , que siempre deberíamos haber estado abrazando esos fundamentos.


...así que, pasamos mucho tiempo, resolviendo problemas con JavaScript. Eso es lo que hacemos como humanos. Resolvemos problemas. ...y porque somos tan buenos resolviendo problemas, o al menos lo disfrutamos tanto... ...y tendemos a buscar problemas también. ...y cuando empezamos a necesitar hacer más cosas en el navegador con JavaScript...


Y, , y así, porque estábamos corriendo en el navegador, que era, que era el área de programación que nosotros, que poseía y, las estructuras del equipo tipo de cambio. Y así, usted tenía el equipo de front-end y el equipo de back-end. Y así, si usted necesita para resolver un problema en ese entorno, usted no va al equipo de backend.


Dijiste, ¿cómo puedo resolver esto sin hablar con el equipo de backend? Y así resolveríamos todo tipo de problemas, como el almacenamiento en caché. Así que no llamamos al backend si no es necesario o lo que sea, con, como tantas cosas diferentes que es, que hacemos como solucionadores de problemas. Y especialmente cuando, como gran parte de nuestras cosas con el lado del cliente ahora, las cosas se están moviendo más hacia una especie de enfoque híbrido con la hidratación y la representación del lado del servidor y esas cosas.


...pero aún así estamos en JavaScript y queremos usar nuestro JavaScript para resolver nuestros problemas. Y se nos ocurren estas soluciones muy, muy complicadas para, para estas cosas. Así, por ejemplo, digamos que estamos usando nuestra propia cosa Webpack, todo es cliente, y decimos, oh, sabes qué, hay un problema de SEO aquí.

Necesitamos pre-renderizar estas cosas, pero no quiero administrar un servidor. He estado disfrutando mucho enviando estos archivos JavaScript y HTML a los cubos de AWS S3. Y no quiero perder eso. Así que lo que si en lugar de pre, nosotros, porque reaccionar puede ejecutar un nodo. Puedo ejecutar este pequeño. Uh, script que generará todos los archivos HTML para todas las páginas.


Y luego envío eso a S3 y, y ahora todavía tengo la experiencia de despliegue agradable que he tenido sin tener que hablar con los ingenieros de backend o sin tener que gestionar un servidor. Y, , Y entonces yo, y sólo rehidratar todo en, , ya sabes, en el arranque y, y eso es lo que es Gatsby o reaccionar estática.


Uh, es este generador de sitios estáticos. Y, funciona, es una solución al problema de los problemas de SEO y, y, y varias otras cosas. Mejora el rendimiento percibido también. ...pero viene con toda una serie de otros problemas que una compañía entera ha estado trabajando para resolver durante años. Y, uno grande de esos problemas es lo que si tengo una tienda con muchos productos o cuando yo era un PayPal, trabajé en paypal.me y todo el mundo tiene su propio enlace. Y así evaluamos Gatsby y fue muy rápidamente obvio que esto no funcionaría porque tenemos millones de usuarios. Y así como tú, no puedes hacer eso. 


Se necesitarían semanas para construir todo, para construir todas esas, esas páginas HTML y la gente dirá bueno, pero lo bueno es que puedes cobrarlo y esas cosas, pero literalmente cada vez que vuelves a desplegar, estás volando todo tu dinero.


Y de hecho, Netlify está construido expresamente para hacer volar su dinero en cada despliegue. ...y esto no es necesariamente algo terrible porque Netlify es un CDN... ...pero el hecho es que está construido con eso en mente, donde si cambias el enfoque, puedes eliminar todos estos problemas en primer lugar.


Y creo que eso es lo que hace la remezcla: cambia el enfoque de tal manera que elimina muchos de los problemas que nos creamos al hacer todo en JavaScript. ...ahora estamos intercambiando problemas, ¿no? No es que eliminamos todos los problemas y eso es todo lo que hacemos. También estamos intercambiando, , por diferentes problemas porque ahora sí tenemos que manejar un servidor.


Ahora, voy a decir antes que nada que remix está planeando o es, , no es exactamente una ciencia de cohetes para hacer el soporte de remix, la generación de sitios estáticos, o completamente renderizado del lado del cliente. Y de hecho, creo que planean apoyar eso con trabajadores de servicio. Así que se ejecuta remix en el servidor, por lo que puede tener una aplicación totalmente fuera de línea con remix.


Por lo tanto. Remix será capaz de hacer estas cosas, pero el valor por defecto es lo que es mejor para ti y mejor para el usuario. Uh, a pesar de que ahora tienes que gestionar un servidor, lo bueno es que hoy en día tenemos servicios que nos permiten manejar miles de solicitudes por segundo por como 10 centavos de dólar al día. Es como, es ridículo lo barato y fácil que es gestionar estos, , objetivos de despliegue.


Yo diría que no es tan fácil como simplemente enviar un par de archivos a un cubo de S3, pero es llegar allí y es, usted S y entonces usted también tiene que preocuparse por como, por lo que la única razón por la que estoy mencionando esto es porque la gente siempre trae esto cuando digo esto. ...pero dicen, bueno, una de las cosas buenas de enviar archivos JavaScript y HTML a S3 es que ahora no tengo que preocuparme de que el servidor se cuelgue y de los problemas de ejecución, y no, no, tienes que preocuparte de los problemas de ejecución porque tu código se va a ejecutar.


Se va a ejecutar, si se ejecuta en el servidor o el cliente no hace ninguna diferencia, usted tiene problemas de tiempo de ejecución. Y por lo tanto, no es diferente con esto. La única diferencia real es que ahora tienes un servidor, que si estás usando cualquiera de estos servicios, que probablemente deberías, entonces, , entonces es básicamente un no problema.

...y sí, Remix está abarcando todas las cosas realmente geniales de, los fundamentos de la web, las bases de la web, con el almacenamiento en caché del navegador y el historial. Y, y luego añaden algunas de las cosas realmente geniales como, , enrutamiento anidado y, , Como archivo único real, componentes donde usted tiene, aquí es cómo obtener mis datos aquí.


Y esto se ejecuta en el servidor. Esto es lo que sucede cuando el usuario publica algún formulario o hace alguna mutación... Esa es mi acción. Y luego aquí está lo que va a renderizar para la interfaz de usuario. Y luego tienen como límites árabes, cosas para su, cada módulo. Usted puede especificar lo que sucede cuando hay un error. , y luego también tiene incluso una interfaz de usuario pendiente, por lo que puede, esto es tan loco, pero, pero pueden, pueden representar su aplicación.


Y si tienes una interfaz de usuario pendiente para un componente en particular, entonces ellos dirán, de acuerdo, voy a renderizar la interfaz de usuario pendiente. Y vamos a llenar eso en el cliente cuando la solicitud termina. Así que si tienes algo que es caro, sólo tienes que poner una interfaz de usuario pendiente allí y ya está. Y esto, esto, esto funciona incluso.

Incluso si ese UI pendiente es como un padre, y luego tiene hijos que no están pendientes. Simplemente, puedes renderizar los hijos que no están pendientes y entonces, ese padre puede tener la parte de su UI. Es increíblemente genial. Y el, sólo la API, y no API para remix es realmente genial.


Así que te dan acceso al documento HTML. Tú eres el que responde a la solicitud. Y así eres el que llama a react para renderizar, para, renderizar a stream si quieres, o renderizar a string. Uh, tú eres el que llama a react a hydrate. Y así, porque usted es responsable de todas estas cosas, usted tiene, una enorme cantidad de control con cero API, re remix.


No necesita, para darle una API especial para anular el documento o, o nada. Y porque está anidado, , , Un enrutador anidado. No tienes que preocuparte de renderizar tu componente de diseño para cada página, lo que haces con, con Gatsby y siguiente, , que es un punto de frustración para la gente que ha experimentado esto.


Y, sí, hay un montón de cosas realmente interesantes sobre la remezcla, pero fundamentalmente para mí, se trata de darme un mecanismo realmente agradable para usar las cosas geniales de los fundamentos de la web con los avances realmente impresionantes que hemos tenido en las innovaciones en la parte frontal de JavaScript, también.


Matias: [00:54:18]
Tengo la sensación de que se apropian realmente de esa frase de "usar la plataforma". " Sí. Creo que eso está llegando, pero esto es realmente real. Todos están ahí. El ATD, porque el video que Ryan grabó en YouTube, es realmente impresionante. Sí. Lo comparo con Belkin porque este es el producto final que puede entregar una aplicación sin ningún tipo de JavaScript, porque simplemente no se requiere como creo que es bastante sorprendente.


Kent: [00:54:49]
Bueno, con el remix, porque eres responsable de renderizar el elemento HTML. Así que el elemento raíz, , es muy trivial para, , no renderizar las etiquetas de script. Uh, y así puedes, , hacer toda tu aplicación y, debido a la forma en que hacen las mutaciones. ...toda tu aplicación puede funcionar sin... sin JavaScript.


Y, y lo que es realmente genial sobre esto es, , usted puede construir su, su aplicación para trabajar muy bien. El lado del cliente. Muestra mensajes de error y cosas, , para todas las mutaciones y lo que sea. Y luego, si por alguna razón, el JavaScript no se carga. Esto nos ha pasado a todos cuando el JavaScript no se carga por alguna razón, , con remix debido a la forma en que estructuran sus APIs.


y, y la forma que es la forma idiomática de hacer esto, su aplicación funcionará exactamente igual. Uh, incluso si no hay JavaScript en la página. Así que la gente será capaz de enviar sus formularios. Pueden obtener una actualización completa de la página, , ya sabes, porque es un formulario que se está publicando, , pero los mensajes de error todavía volverán a renderizar y todo.


Uh, y uh, como si, si hay un error en el formulario, todo será, seguirá funcionando. Y así. Uh, sí. Si usted tiene un caso de uso donde usted es como, Ooh, realmente no quiero tener, cualquier JavaScript en la página de inicio de sesión porque quiero que la página de inicio de sesión para cargar como un rayo entonces, , es trivial para, para añadir que no hay API para ello.



Matias: [00:56:22]
Es obvio por la forma en que está construido. Me parece, dos cosas, me parece que reinventan la idea de framework porque actualmente los frameworks de JavaScript son cosas que envías con tu obligación. Y esto es algo que es sólo la delegación de chips, no el marco en sí.


Uh, y la otra cosa es como remix, , un poco como una herramienta, mecanismo, derrame, kit, y otros son una especie de abrir la puerta a lo que puede ser llamado la tercera era de JavaScript. Como que estamos pasando de los frameworks de cliente a algo más. Es increíble. 


Kent: [00:56:56]
Sí. Y esto, y viene con construcciones que toman 50 milisegundos.


Bueno, sí, es bastante grande. Soy un gran fan de eso. 


Matias: [00:57:08]
Ok. Entonces estamos, casi al final de esta increíble conversación sobre Ken. Gracias por venir. Uh no. No estoy seguro. ¿Quieres obviamente mirar algo y recomendar algo a la audiencia?

 

Kent: [00:57:22]
Ooh, , sí, así que yo, no sé, como, una recomendación sólo en general.


...creo que puedes ser realmente, realmente impresionante. Un desarrollador sólido y realmente bueno en la codificación y esas cosas. pero no importa lo bueno que seas en la codificación, si no eres agradable, no encontrarás satisfacción en la vida. Siempre estarás persiguiendo algo que te haga feliz. Y creo que encontrar la felicidad en la vida tiene mucho que ver con la cantidad de felicidad que trabajas para traer a la vida de otras personas.


Y, , y la amabilidad tiene mucho que ver con eso. Así que, sí, supongo que si hay algo que recomendaría a la audiencia es, , evaluar lo amable que eres, , o lo amable que fuiste en tu última interacción y trabajar para mejorar eso cada día. 


Matias: [00:58:16]
Me encanta porque somos humanos y no somos sólo una colección de habilidades técnicas.


Somos humanos y trabajamos con otros humanos. Así que ser amable, ser feliz es parte de nuestro objetivo de alguna manera.


Kent: [00:58:29]
No sé qué haces si no quieres ser feliz. 


Matias: [00:58:33]
Sí. Sí. , obviamente como un enchufe, lo haré, eh, epic reactor dev ir a material react en la web. Así que todas estas cosas que Ray puede mencionar a través de su charla estarán en las notas del programa como siempre, y, espero que las transcripciones también.


Así que gracias por estar aquí. Uh, puede de nuevo, no estoy seguro. Oh, una última pregunta. ¿Quién más debería venir a este programa? 


Kent: [00:59:03]
Ooh, esa es una buena. Yo, tengo un número de, de personas en mi comunidad de discordia que son simplemente increíbles. que podría mencionar a usted y tal vez yo, yo te tiro un correo electrónico o algo así, pero,, yo.


Cualquiera que haya estado en uno de mis podcasts, sería increíble. Así que vayan a ver Kent C dodds.com/podcast. Tenemos tres temporadas, la cuarta temporada viene pronto. Y sí, como la gente que quiero escuchar en un podcast son, son los que invito a la mía. Así que también hay una reacción épica, una especie de podcast en ella también.


Así que usted puede ir a echar un vistazo a, a la gente que tenía en, en eso. Y todos ellos son como reaccionar centrado, obviamente. Así que sí, es la épica reaccionar a las entrevistas de expertos. ...y todos son personas fantásticas. Me encantaría verte en este podcast.


Matias: [00:59:53]
Un contenido realmente impresionante allí también. Así que sí. Gracias, Kent. Esto fue impresionante.


Kent: [00:59:58]
Gracias. Ha sido un placer 


Matias: [01:00:01]
y nos escuchamos, en la próxima semana.

--------------------------------------------------------------------------------------------------------------------

English

Matias: [00:00:00]
Welcome to this first episode of Cafe con Tech in English. Today, I'm with the one and only Kent C Dodds. Kent, thank you for coming by.  Thank you for accepting to be my guest in this particular episode that is starting the first season.


Kent: [00:00:14]
Yeah, I'm honored to be invited. It's really cool and cool of you to have a podcast in Spanish and, and nice of you to invite me to do one in English. Cause I, , don't comprende comprendo much español. 


Matias: [00:00:33]
That's usual. Also, I think that every Latin American developer should learn English anyway. If you want to get more doors open and to level up your career, but, to start , Kent, can you kind of introduce yourself? I don’t know. Should anyone else need an introduction from you, but let's do it.


Kent: [00:00:56]
 I'm sure there are plenty of people who don't know me, but,  yeah, my name is Kent C. Dodds, and I live in Utah in the United States. I'm the father of four beautiful children, a husband, I have a dog, and I teach people how to write quality software. In particular, I focus a lot on React, but I do plenty of Node as well. So pretty much all just JavaScript for me.  I've been doing that for just over two years. Before that was PayPal and then a couple of other companies. I've worked on really large codebases, and so I know the pain and the struggle. I try to take that experience that I've had to help other people relieve some of that pain and make the world a better place with what they're doing.


Matias: [00:01:44]
 I really liked that quote, ”Make the world a better place with code.” In general, people tend to think that we just write code, but in fact, we solve problems. So that is what I liked. I have a question. At some point you  were known as the testing guy, uh now you are more a React guy in terms of testing. And since you mentioned, that you have experience with a large codebase, how can you Sell testing to your bosses? Testing is kind of this gray area that no one wants you to do because it takes time, but it's always desirable to have because it will improve your process, but how do you sell it?


Kent: [00:02:26]
 Yeah. So actually, I have a blog post titled “Business and Engineering Alignment,” which is where I talk about how you get the business folks to do whatever you want. The trick is the part of changing what you want, to be in line with what the business people want you to do. What it really comes down to is identifying the mission of the company and making the assumption that everybody is motivated to push that mission forward. And so if you have people who aren't motivated to push the mission forward, then you're kind of in a bad place anyway. And so, we have to make that assumption that people are motivated to push the mission forward.


Kent: [00:03:24]
So you identify the mission, and then you find out how you can explain to the business folks that the thing you want to do is going to push that mission forward better. It's going to help you in your goals.  And to be able to do that, you have to convince yourself first that this is really going to be a valuable return on your investment of time.


Kent: [00:03:40]
 And if you can't convince yourself, if you really, after analyzing it and thinking about it, you're like, oh, I don't know, we’re only in the prototyping stage, and I can't really convince myself that testing is really super valuable right now at this stage, then that's easy. You don't even need to have the conversation. But for most of us, we're not working in a situation where testing is unnecessary. Most of us are working in a situation where we need to write tests. Your job is to be able to have as strong a link as possible between testing and the mission of the company. So you can say if we don't test or because we don't test, we are having all of these bugs that we're shipping, and because of those bugs, we're not able to push the mission forward as much as we would like to.


Kent: [00:04:41]
So we can solve this pretty easily by writing tests. It may not be easy depending on where you're at,  but the answer is pretty simple. , you know, you get tests, automated tests running,  so that you don't have to manually test everything. That's where it comes down to just making or communicating effectively with the people who make these decisions, the managers or whatever, that this is an important part of your return on your investment of time and not doing this is worse than doing it. 


Matias: [00:04:56]
Yeah, I like it. I like the idea of lining up with the mission and selling the technical need of this with more like the product need. We actually are solving problems and delivering products. So we should be sure that we are doing a good job there, but leaving testing aside, like always and everyone, you have a talk that is always interesting to me. And I think I already watched it like twice or more times,  in different places. And the one that you mentioned that React is actually a state management tool, not just a UI tool. , can you kind of summarize the concept you want to deliver to us?


Kent: [00:05:38]
 Yeah, sure. Uh, I remember when I got started with React, one of the first questions that I had was what's the difference between props and state? I think a lot of people ask that as you get started. And I remember coming across this flow chart that Ryan Florence had made that describes kind of those differences. Ever since the very beginning React has always been able to manage the state. Before I really got into React, I thought a big part of it was that React encourages you to be stateless.


Kent: [00:06:37]
 And so you have your state that lives outside of React, and then you just pass that on to React, and then, it renders your thing based on the external state. And while you can do that, you can make all of your components stateless and then just pass it on through, that's possible. And this kind of embodies the, you know, UI as a function of state, a thing that a lot of people talk about. That's actually not what react is really, not practical react. Uh, it's really about statelessness. It's more about giving you a deterministic way to manage your state and a declarative way to interact with the things that change over time so that you don't have to think about them.


Kent: [00:07:21]
And you just think about it based on the current state. Here's my current UI. And when this happens, I will update the state, but I'm not going to worry about what happens to my UI at that point. That will be a completely different render and everything. So for as long as React has been around, it's always been a state manager. From the very beginning, people tried to add things to React to enhance its capabilities there for various reasons that you run into when you're trying to build an application at scale, like a really sizable application, a common term is prop drilling. And that basically means that you are managing a, well, let me take a step back.


Let’s say you have this one little component, and it’s small. Then you’re building this application out. You realize you need to break things up into multiple components. Then two sibling components need to access the same state. So you just move that state up to the least common parent, and that’s what we call lifting state.


Over time, as you continue to slowly lift to state, eventually you're probably going to have some state that comes from the very top like everything needs to access this state. So when you’re doing it, you have all of these different layers of components. You have to pass the props down to the components that need them.


The real frustration is when you have a component that's pretty far down in the react component tree that needs to state that it's very high up in the component tree, but none of the components between those two need it. And so, all of the other components between these are just passing props along that they don't even need themselves.


It's just that there's this relationship between the great grandparents and the great-grandchild. That can be frustrating. This is what we call prop chilling, and you not only need to pass the state, but also the mechanism for updating the state. Yeah, that makes it kind of annoying to have to thread those things through.


I think this was probably the biggest challenge that led people to start exploring things outside of React for managing the state. We can talk about that a little bit more, but then, the other thing that I think motivated people reaching outside of react was when Facebook came out with their idea behind flux, which is a way of managing a state where you have this mechanism to dispatch an event that you handle an event that dispatches, at some other event with some payload and then that gets set into some state, and then that propagates through the whole app. And, and there are various benefits to this approach and various trade-offs that this approach makes, which we only discovered after we all clambered onto this, flex that raft, going down the river, we didn't realize somebody forgot the order or something.


Everybody decided that this is the only way. And then this is the react way when it really isn't. The react way has always been, you, you manage state inside of a component. If a sibling needs it, then you lift the state, and if no siblings need it and only one child needs it, then push that state into the child.


There's no reason for it to exist outside in that situation. React has always been a state management library. But because of these problems, we reached for other things, and that's where Redux came in because it solved both, both of those things. It was a flex implementation or a flux-like implementation and it used the unofficial context API.


Uh, which in the react docs, it was documented, but it had this big warning that was scary that said, you know, don't use this, it's going to change everything. So people didn't want to, but literally, everybody was because we were using react-router and that was using it. We were probably using a CSS and JS theme provider that was using it.


And then Redux was using it. And so, we are all actually using this API to solve the prep drilling problem. And, and there were actually some other much simpler implementations of the context API that I used. There was one called react broadcast by Michael Jackson that I really liked.


It was awesome. Just to make it easier to get your state from one from the top of the tree down, But, yeah, so I, I did use Redux for a while and, for long enough for me to realize I wasn't super happy with it. I ended up opening like 30 files to make a single change. Uh, I did not enjoy that at all.

I only used it for one project. I didn't choose it for that project either. I came into the project that had it already, and then any other projects after that. That was the only project I ever used a Redux with just because I saw that it was solving a lot of problems. But if I change my approach, I don't have those problems.

I didn't need to worry about it. So anyway, that's, that's a long way to say yes, react is a state manager.


Matias: [00:12:15]
 You mentioned two things that I want to kind of shout out, this idea of, you don't need to solve the problem that you just don't have, or you just don't declare it that you have, and people tend to, or used to think that prop drilling is a problem. So we have to solve it even before we have it, and we use redux and any other, a lot of possibilities there. , but actually, there is another concept that is native to react that is composition. And I feel that, yeah, learners and beginners don't actually use composition at all. It's like just children under the children, but there is no other idea there, their composition. Can you, kind of, talk about that.


Kent: [00:12:59]
 Yeah, yeah, absolutely. So, and I'm pretty sure I mentioned this in the blog post. I didn't originally, and I added it later cause it was a glaring, missing part of that blog post. So composition is like, let's say that you're building some chat-based UI and you want to have, I dunno, you're managing some state at the top level that says what users are currently logged in. And then you have this sidebar over here that lists those users, and it needs to be at the top level because you also have another thing that indicates the total count of people who are currently logged in or something. And so that does need to be up higher in the tree. But, but you have two things, two components that are lower in the tree that need to access this data. , well, so a pretty natural thing for people to do when they're writing react is they have one component that renders this stuff, and then those, those components render this stuff and, and those components render this, these things.


And so when you do stuff like that, you naturally have to prop drill. So you have to pass this value down to that one. Then down to that one and down to that all the way until you get to where you are. However, what if instead of, and, and often these other components are kind of like rappers, and often they're like layout components. Uh, so it's like, okay, well, I've got my, my sidebar, but what's inside of my main nav for something like that. And then, , and so they make the main responsible for rendering the sidebar, , where there's actually no state being managed by main. There's nothing like in there that says that it needs to be the one to render the sidebar. And so if, instead, you say, Hey, I'm going to render the main and that's responsible for the layout. And then, I'm going to pass you what I want you to put into it like the children for that layout. So I'm going to be responsible for saying what you render in the different parts of what you're laying out.


, that means that the top level component gets to render the sidebar by itself. And so there's no prop drilling, , of any kind, because the top level component can just pass those prompts directly to the component that needs it. Uh, it's a little bit hard to describe this audibly. So, , the blogpost has an example, and, and actually there's a video by Michael Jackson where he explains this very well.


, and, and actually Michael Jackson made that video because, he was making the suggestion that, , most applications don't need context at all. , which I think. You might be able to get away with, , maybe, but I don't. I think that most applications probably have at least one or two, useful use cases for context, but in spirit he's correct.


, he and his assertion is, , context is mostly useful for libraries, which I believe is, is the case. , but, anyway, if like, like you said, also, , if you change your approach from the, just the way that you're writing your components, then you can just eliminate the problem of propelling altogether and you don't have to reach for context.


And, and the other thing that, that reacted to help eliminate the problem of prompt drilling, or at least, reduce the impact of, of prop drooling is by making context official and making it a pretty straightforward API to use relative to what it used to be, , before hooks and stuff. 


Matias: [00:16:33]
That was really helpful.

And at  the same time, I think that was kind of damaging the composition concept in terms of like a so easy to use context that you just use it and people will start falling in the same patterns that with redux, like, it was so easy to push everything there that you do just using it. But for some reason, composition is not even taught by instructors around the world, like using this render prop like pattern, because it's kind of similar where you pass the component as a prop, not the data. And why do you think that it is so hard to teach or learn composition and really use it? And because I've been in a lot of React projects and yeah, this is not the pattern. This is, you can find it, but it's not the usual 


Kent: [00:17:28]
You know, you're right. And actually, , I don't think that I had talked about it directly even in my own stuff. I do use it just naturally in the way that I build stuff, but I don't actually teach it specifically. And that will change in an upcoming version of epic react. I'm going to include a section on leveraging competition. Cause that's one of the cool things about react. So that's like one of the primary key features


I think I see react components as functions, which they are of course, but, even the JSX I see is as functions that you're passing these arguments to these functions and we don't really often leverage composition, even in our functions. Not as heavily as you see it when you're leveraging composition with react where you just pass this function and pass this call to this function, to this other function and things like that. I think there's something just in our brains, it feels more natural to say, well, here's this block of stuff.


I'm going to put this in a function. And now this function is responsible for this block of stuff where actually that function really is only in charge of what a portion of that and the rest of it can be passed as an argument. I think that's the big challenge there is we fail to parameterize enough when it comes to our component, 

Matias: [00:19:00] It's kind of the mental model that you come with an imperative, mental model, like most of us. And then you need to change a little bit, like in the path of functional programming, like declarative, more where composition is kind of the king, but we are kind of falling in the middle with JavaScript and react itself. 


Kent: [00:19:24]
Yeah, I would say that, that one of the coolest things about JavaScript is its flexibility to, , cater to people's different use cases for the way that they like to write their code, , whether it's functional or, , object oriented or, or whatever they want to.


And so, , Because JavaScript is so flexible that way, but also, because it is so ubiquitous for better or worse, it's the language of the web. And it's the most popular language in the world and people kind of have to use it whether they want to or not. , for many instances you get a lot of people with different backgrounds and preferences, , than you would in, in a different, , a language in a different platform.


, because not only are they in different backgrounds, but they're also deploying to different targets and they have different use cases and, and all sorts of things. So none of them are necessarily wrong. , they're just, it's just different use cases and different preferences. And so I think because of that, we get a very wide variety of, , of, just the way that people write their code.

, when they're running javascript 


Matias: [00:20:33]
Makes sense. Moving forward with this part of the state thing, topic, in the talk and, and other places you are kind of supporting really hard on react query and saying basically the same as Tanner's said or Tanner said the same thing you did, I don't know - that state is actually two different natures.

One is UI and react is a tool and one is a server state that or cache that is react  query tool. So I understand that your reac-query is your jam here. And, but can you little describe this difference between the state's nature? 


Kent: [00:21:10]
Absolutely. I found out or kind of started thinking about this , maybe two years ago when I realized that we could drastically simplify our UI state if we don't try to treat the server state like its UI state.


And embrace the fact that the server state is a cash. , and so Tanner and I , Tanner lives pretty close to me actually. And so we were having lunch and he was talking about this before he created react query. And he's saying I've been building some really interesting utilities for, for my app at work.


, and so we talked about it quite a bit, and then he came out with react query and it was a game changer for me. Yeah, just when you separate your, what, so first, when you embrace the fact that your server state is a cache, , rather than, it's just some state you need to keep updated, you do a couple of things differently.


So one thing that I did a lot before was, , when I would make a update to, so let me take a step back when, when you are building some app state, some UI stuff, forgetting about the server,  when there's an update, you update that value in memory. So you're saying set state or set, , modal status or whatever it is that you're, you're updating.


 And that's just how we operate in that way when we're. , so when we bring in the server and we're starting to talk about server state, it just kind of feels natural to go ahead and update that state and then maybe have a useEffect  or something that we'll update on the backend.


, and more often what we end up doing is to say, no, I don't want to have an inconsistency here. So  I'll say,  go do this fetch request to go update this. And then it'll give me back the new state and I'll update my local state to be what that new state is. And , actually Apollo does this a lot, not, not to rag on Apollo or anything.


They're solving big problems, but they try to mutate their cache to match what they get back from, from the backend.  And react query kind of takes a different approach.  I think that like, you should be able to, to make that work, but react query just says, oh, you made a mutation. Let me just go get it again.


, because you embrace the fact that it's a cache and, and when you do that, you have to say, as soon as I get this data, it is stale. It's wrong. Uh, you just, you embrace that fact. And so I'm making an extra request to go say, okay, I made a mutation, let me go get what the current state is and putting all of that inside of react query as a package means that you don't have to worry about keeping that state up to date yourself.


And so it drastically simplifies the management of your stuff. I used to have, like these really big, context providers that had all of these different methods or  it was in a reducer, all of these different ,you know, switch statement reducers stuff  to manage like, oh, I added it to do so I've got to push that onto the, the array list or whatever, but with react query, now I just say go ahead and add it to the backend API and then react query takes care of getting the fresh state back for me. There are trade-offs with this approach, but there are ways to work around some of those trade-offs too, but I like the default that react query gives me, which makes me more correct.


And, , because I've moved all of the server state into this cache. Now what I have left for context or composition or whatever is very simple. And if I'm co-locating my state, I often don't even need some of that stuff in a context provider, I just put it in the area of the app that cares about that state.

And so, yeah, the, , react query has just been phenomenal for my client side applications. I don't really use it a whole lot for stuff like remix, , because remix eliminates the problems that react query solves. And we can talk about that if you want to. But, , for, if I'm doing a client side application, , a hundred percent, I'm going to be using react query. It just saves me so much time. 


Matias: [00:25:11]
Yeah. One of the things that resonated with me was this difference that basically a UI state is synchronous and server or cache state is asynchronous, and you have all of the package into a really cool and clever solution. So you don't have to worry about the synchronicity of that data.


And then you just worry about your own logic basically because the server states not your logic, it belongs to somewhere else. So that kind of resonates a lot with me. Uh, yeah. I want to ask about  remix too, but I'm really curious, but I have another little question there and I'm sure that you receive this question a lot, so many, so many times that you already have a post about it.


Uh, but anyways, well you have a post for almost everything along with a gif. UseEffect is so complex for people to just drop the dependencies into the useeffect and just follow the rules. Like, eh, like you have another talk. I think it's called, “common react pitfalls” where you joke around like LinkedIn rules is Diana Vermont saying, use these things critically.


Eh, I know, eh, Why, why people just, why would you, whether you think that is so hard to follow these effects, synchronicity or staying synchronized by mobile, that use effect need. 


Kent: [00:26:46]
I think there are various reasons that people struggle to follow the linting rule. If you have experienced react already, then your challenge is unlearning. By that I mean if you have experience with react class components, you're thinking about react components in an old way. The way we used to think about them was life cycles. And so you think, okay, when the component mounts, and then when the component updates, then when the component mounts, I want these things to happen.


, and with use effect. Because it doesn't really operate that way. , we try to make it operate that way, , because we're thinking about, the way that, we used to, we think about components and life cycles, but that's not the way to think about those things. So I, I think that's one of the, the major ones for people who have had experience with react already, , is they're trying to bend use effect to operate in life cycles, , rather than synchronizing the state of the world with the state of the app.

, so another reason is that. , sometimes we don't understand or people don't understand what, how the dependency array works. , so the, the fact is that you have an array that you provide to use effect and, , anytime any of those elements changes, even if it's the exact same shape of an object, , if it's a brand new object, it's going to trigger a rerun of your use effect.


And if you don't understand that and you see that your use effect is running over and over again, you're going to just say, well, okay, nevermind. I'll just, , I'll turn off the rule and then your, when you turn off the rule, you are turning on a bug. That's, that's really what it is. , it's like switching on bug mode, I guess, if you want to think about it that way.


, but, But your people are doing this because they're ending up with an infinite loop because they're used effect called set state or something. , and, or even worse that it's calling an API and then calling set state. And so if you have, an ever-changing dependency, you're just forever calling this API and then you get rate limited or something.


I wish I could say I've never done that before. Oh yeah. We've all done it. Yeah. , so yeah, we like, we removed dependencies out of desperation, , for that. And it's because we don't understand that, you know, , when you create a new object, you're creating, even if all the properties are the same, you're creating a new reference to, an entirely different thing.


, and so it is, honestly, it is fairly tricky. , and you have to have a good understanding and like, For one, if you don't have a good understanding of the way JavaScript works and closures and, you know, , JavaScript passes by value and stuff like that, then, , , then it's just a thing that's in your way, and you don't understand why it's causing you so much trouble and that's, that's frustrating.


Uh, so I don't, really blame people for wanting to turn it off and just move on with life. , but like I said, they are turning on, on hard mode, black mode. , but, yeah, the, the other. , point to all of this is I think that use of fact is a pretty low level primitive. , and what's really awesome about hooks in general is that it gives us the ability to abstract things really nicely in a way that we never could with class components.


We tried with, with render props and higher order components and stuff, but, and, and that actually worked out pretty well. I was pretty happy with render props. Uh, generally there were, there were different problems with it, but when hooks came around, , so many problems were just eliminated because we can now share code the same way, share react code and react logic in the same way that we share any other code and that's by making a function and we call it a custom hook, but it's just a function that uses other hooks.

That's all that a custom hook is. And so, , I, I'm finding myself using use effects less and less as I'm using other, libraries. And so what's cool about that? I'm a library author, so it's good for me to understand how all of this works, but the more, , good abstractions that we build, the less people actually have to use, use affect themselves.


And, and a lot of the times that I'm seeing in my discord community or online is, people are using use effect to do lots of the same things for which there are libraries developed that, , I suggest people use, , react query is a perfect example of this. , so many people are using react query or use, , making fetch calls themselves and stuff.


When I just say, why don't you just use react query? Uh, and then you don't have to bother worrying about the dependencies. , oh, and one other thing about use effect that makes it a little tricky is that as soon as you abstract something, , out of a component. So you're trying to make your own custom hook or something.


If that logic is using use effect, then some other things become tricky too, because you no longer have direct access to the variables that, that inmate might be using, especially if, , you were, if you want it to abstract, like what happens in the use of facts with some sort of callback or something?

Uh, because now, you can't just put the callback directly in the use of fact, do you want to genericize that? And so now you have to accept that as a parameter. , and now, as things rerender, that callback could get changed, you could wind up with a stale closer kosher. So you either have to memorize that or, or you have to use this later latest ref pattern.


So abstracting use effect is I think another thing that, , makes the dependency array, and it's not just use effect, it's also used memo and you just call back, but it makes that dependency array a little tricky, , because. You can't just inline things. These hooks are, work a lot easier if you just inline everything, stick everything that it needs directly into that callback.


, but, yeah, it's, it's cool because when you have, when you understand those things, you can build some really awesome abstractions that you can never do before. , and, that's why I say that use effect is a pretty low level primitive upon which you can build other cool abstractions so that most people don't and including yourself, that you don't have to worry about using use effects in your regular application code.


Matias: [00:33:25]
Yeah. Two questions. Uh, do you have any particular resource with tips and tricks to get around with use effect, like using a conditional insight of the fact just to avoid, to shake that particular value or whatever. And second, do you think that use effect is somehow a shotgun. Shoot guns. Shoot. 

Kent: [00:33:44]
Yeah, yeah.

Foot gun. Yeah. , so first I do have some really good articles on epic react. If you go to epic react.dev/articles, , as well as on my own blog, Kent C dodds.com/blog, , where I talked about use effects and also use memo and, and, use callback, as well. Those are, similar because of the dependency your'e situation.


, so yeah, those are some really good resources. , one of one in particular is the, well, now I should, I should look it up. So I give you the right title. , it is how react uses closures. Yeah. How react uses closures to avoid bugs. And that kind of describes the, , the primary difference between react, class components and, and hooks and how react just kind of changed the default.


, it might seem like it's harder, but it ends up saving us a lot of pain, in the long run. Uh, and then I also have another blog post on there tied to the latest ref pattern in react, which solves a lot of the problems that people would find, when they're actually trying to do something similar to what we used to have in, , in class components.


Uh, it's actually a really simple pattern. , but it's pretty powerful when you're building abstractions. , but, yeah. So your, your second question about why is a use effective foot gun?


Matias: [00:35:17]
if you think that it's  because yeah, API lower level API is really hard to use it, but at the same time it's lower, but it's is, is describe it as one of the basic ones that you need to learn to actually develop an aggregation.

So is what, 


Kent: [00:35:32]
yeah. Yeah, that's true. I would say that use effect is, It's relatively advanced, but the fact is that it's very simple. Like I could, I could explain to you what use effect is in two or three sentences and cover everything. , because it is a relatively simple thing. The challenge is that, , in practical application, it can be hard to get right.


Uh, and, and it's not easy. It relies on, , several concepts that people don't have super, , nailed down when they're working with JavaScript. , and because, or, sorry, let me say that differently. It relies on, , or being able to use it effectively. Depends on how well you understand these fundamental JavaScript concepts.


And so if you don't understand, the fact that render actually recalls your function and what that implies about the, functions that you're creating within your components, as well as the variables you're creating within your component. , yeah. If you don't have that understanding, then it can absolutely be a hard thing to get right.

, so is it a foot gun? Yeah, maybe, , potentially, but I think it still is the right approach. Just because something is hard doesn't mean it's wrong, , that you can find the right thing by finding the thing that is simple because you can't build a simple application with really complex abstractions.


It's just that that's not a thing you can do. However, you can build a simple application with simple abstractions and, , and you can also build a complex application with simple abstractions. It's not like a silver bullet or anything, but, yeah, if you have simple, , primitives, then you can build a simple application out of that and you can build simple abstractions on top of it.


That's what I think use effect is, is intended for. Let's provide something that is simple. The whole idea is to synchronize what happened outside of Ray or let's synchronize what happens inside of react with things that are outside of react. That's the whole objective of use effect.


And,  and then people can build on top of that, to, to make nice abstractions so that most people don't have to work with the low level perimeter. 


Matias: [00:37:54]
makes sense. , I want to jump to another topic before the time goes and you are actually diving deep into TypeScript. I you're been a JavaScript developer for a long time, but now you're moving to, eh, what the wave is given us.


That is TypeScript. Everyone is writing TypeScript right now. So the question is really simple. Why type TypeScript? Why TypeScript? 


Kent: [00:38:19]
Yeah. Yeah. So I have actually been using TypeScript for, , Three or four years. , but I, I decided for a long time, a long time ago, and actually before that it was flow. , I use flow type at PayPal for a long time.

, but, yeah. , I think react is still written in flow and stuff, but yeah, that was the only ones. Yeah. Yeah, for real. , so yeah, I decided to not add typings to my open source stuff and my educational material, because I didn't want that to be a barrier for people getting into it. , especially for open source.

I just felt like I don't, I don't want to limit the people who can, participate in my open source stuff to those who know TypeScript, because there are fewer people that know TypeScript. The thing is that. And people who know TypeScript also know JavaScript, but the people who know JavaScript don't necessarily know TypeScript.


So if I just kind of go with the least common denominator, I can reach more people in both my open source, as well as my educational material. , but a few months ago I changed my thinking around that actually after talking with Ryan Florence, cause he told me that they were starting to move their material over to TypeScript.

And I said, well, what about this? And he said, why. , we found that as we were going to give these workshops, we'd say who here uses TypeScript and literally everybody would raise their hand. And, , and on top of that, as we were helping people work through the exercises and stuff, we saw that, they were really confused when they didn't get autocomplete for different, basic things.


And it was really frustrating for them. , and if you do it right. , for the educational stuff, you can make it so that, , for the learners, TypeScript is mostly opt-in. , so you configure TypeScript to not have to type everything, you know, any is fine, whatever. And so if, if I'm just a regular JavaScript developer, the only difference for me is that the file ends in dot TSX.

Uh, everything else is the same. I don't have to worry about it. Uh, and then on top of that, if there are, , utilities that are provided by, the, as part of the material that I'm just calling into this function, I'm getting auto-complete, which is really helpful. Uh, even if I'm just a regular JavaScript developer and I don't care about TypeScript.


And so if you configure things, right, , even the learners don't have to know TypeScript to be able to use a workshop that's primarily in TypeScript. , And, on the open side, I I'd been telling myself this for a long time that, my concern about, TypeScript being a barrier to entry, was just fake, because I expect people to write tests, in addition to implementing whatever they're doing and touch script is just tests.


, at the end of the day, that's, that's all that it is. , and so I was already expecting people, like I already had a barrier to entry on the test side of things, , learning how to add some parameters and stuff. , you know, perimeter types and stuff is a, it's not that much of a bigger ask. , Granted library, TypeScript is a lot harder than app type script.


So, we'll see how this all plays out, but, and maybe there are some people already who have tried to contribute to my open source stuff and decided not to, because it was TypeScript and I feel bad about that, but at the end of the day, the, the end product is way better for people. And so I'm okay with the trade-off because the cool thing about TypeScript is that yes, it is tests, but it's also tests that you can hand off to the consumers as well.


, because the type definitions there too, so, , yeah, so that's yeah. Yeah, it's fantastic. I love being a consumer of my own stuff now that it's all really nicely typed. , so yeah, that's kind of where the turnaround publicly has been. , but yeah, I've been using typed JavaScript for a long time and, and, it just seems obvious to me, really like it's.

, I never really enjoyed working in just JavaScript after I started using, Flo and TypeScript at PayPal several years ago. , but I did it for those reasons and I'm not doing it now for those other reasons. 


Matias: [00:42:35]
Yeah. Your computer writing TypeScript and then going back to playing JavaScript.


It's kind of, moving back to the nineties. Yeah, no, never again. , one more question with TypeScript. Eh, now you are creating material blog posts, mostly with TypeScript. Do you think that you will move epic react to that too?


Kent: [00:42:54]
Absolutely. Everything that I'm doing is moving to TypeScript.

So, , testing javascript.com will also be all TypeScript when I'm done. Uh, and epic reacts will all be TypeScript. Uh, Before I update either one of those though, I am working on a couple TypeScript workshops, , because I want to, for people who just aren't experienced with TypeScript or who want to level up their TypeScript, I want to give them a place to go before they go through epic react and, and testing JavaScript.


So I can, so if they say, Hey, I can't go through epic react. I don't know a TypeScript. I can say, well, no, go through this first. And then you can go through epic reacting. Won't be a problem. So, , well, what I'm doing right now is I'm updating all of the material and then I'm going to just take a, a kind of little survey over my material and see which features of TypeScript I'm using.

And I'll make sure to include all of those in, these types gripped workshops that people can go through first. 


Matias: [00:43:52]
Nice, nice. That will be really good. , to finish, I think that this shoot to remix.


Kent: [00:43:59]
Yeah. I'd love to talk about remix. What do you want to know? 


Matias: [00:44:03]
Uh, but basically all I wasn't able to, sorry, my call, sorry, Ryan. I wasn't able to finally buy my own lessons at that point. , but you do so can, you can kind of summarize again and it's short in, it's just LD, but why remix have you so excited, like, to me, it's kind of similar at some point we just spoke it as far as I know, but yeah, I'm all ears here.


Kent: [00:44:31]
So I have zero experience with felt kit. , and I actually have pretty limited experience with next JS, which a lot of people compare remix to. , but from the experience that I have, it's not really like next JS a lot. I like it. There's a lot of overlap on use cases that they can, handle, but, they're pretty different in a lot of ways.


The thing that, the elephant in the room, so I'll address that quickly is, remix is licensed, , software where you have to purchase a license to use the software. , this is going to eventually they plan on, , having a trial period for that. , I know a lot of people are really frustrated that there's no way to, to just test it out and see if they, if you like it.


Uh, so they are planning on having a trial period eventually. , but right now they're, they're still . , and so they're there. Uh, focusing on people who, , are willing to pay them to, , to work on it so they can feed their families and stuff.


Matias: [00:45:35]
I think that it's pretty awesome open source for model.


Kent: [00:45:40]
I totally agree. A lot of people feel like you offended their mother when you suggest that software like this should be paid, which I don't understand at all, but, , yeah. Some people feel that way. , but, yeah, so remix, why is it so awesome? I love remix because I feel like it embraces the fundamentals of the web in the way that, , that we always should have been embracing those fundamentals.


, so it, it, we spend so much time, , solving problems with JavaScript. That's what we do as humans. We solve problems. , and because we are such good problem solvers, or at least we enjoy it so much, , And we tend to like, kind of seek problems too. , and, and so when, when we started needing to do more in the browser with JavaScript, we built entire frameworks that all ran in the browser.


And, ,and so, because we were running in the browser, that was, that was the programming area that we, we owned and, the team structures kind of changed. And so, you had the front end team and the backend team. And so if you needed to solve a problem in that environment, you didn't go to the backend team.


You said, how can I solve this without talking to the backend team? , and so we would solve all sorts of these problems, like with caching. So we don't call the backend if we don't need to or whatever, , with, like so many different things that that's, That we do as problem solvers. And especially when, like so much of our stuff with client side now, things are moving more toward a kind of a hybrid approach with hydrating and server side rendering and stuff.


, but still we are in JavaScript and we want to use our JavaScript to solve our problems. And we come up with these very, very complicated solutions to, to these things. So, for example, let's say that we're using our own Webpack thing, everything's client, and we say, oh, you know what, there's an SEO problem here.

We need to pre-render this stuff, but I don't want to manage a server. I've been really enjoying just sending these JavaScript and HTML files up to AWS S3 buckets. And I don't want to lose that. So what if instead we pre, we, because react can run a node. I can run this little. Uh, script that will generate all the HTML files for all the pages.


And then I send that to S3 and, and now I still get the nice deployment experience that I've had without having to talk to the backend engineers or without having to manage a server. And, , And so then I, and we just rehydrate everything on, , you know, on start-up and, and that's what Gatsby is or react static.


Uh, it's this static site generator. And, it works, it's a solution to the problem of SEO issues and, and, and various other things. It improves perceived performance as well. , but it comes with a whole host of other problems that an entire company has been working to solve for years. And, a big one of those problems is what if I have a store with many products or when I was a PayPal, I worked on paypal.me and everybody has their own link. And so we evaluated Gatsby and it was very quickly obvious that this would not work because we have millions of users. And so like you, you can't do that. 


It would take weeks to build everything, , to build all those, those HTML pages and people will say well, but the cool thing is that you can cash it and stuff, but literally every time you redeploy, you are blowing away all of your cash.


And in fact, Netlify is built expressly to blow away your cash on every deploy. , and this isn't necessarily a terrible thing because Netlify is a CDN. , but the fact is that it's, it's built with that in mind, , where if you change the approach, you can just eliminate all of these problems in the first place.


And I feel like that's what remix does is it changes the approach in such a way that it eliminates a lot of the problems we created for ourselves by doing everything in JavaScript. , now we're trading off problems, right? It's not like we eliminate all problems and that's all we do. We're also trading, , for different problems because now we do need to manage a server.


Now, I'll say before anything else that remix is planning or it's, , not exactly a rocket science to make remix support, static site generation, or completely client side rendering. And in fact, I believe they plan on supporting that with service workers. So you run remix on the server, so you can have a totally offline app with remix.


So. Remix will be able to do these things, but the default is what's better for you and better for the user. Uh, even though you do have to now manage a server, the cool thing is that nowadays we have services that allow us to handle thousands of requests a second for like 10 cents a day. It's like, it's ridiculous how cheap and easy it is to manage these, , deployment targets.


It's I would say it's not quite as easy as just sending up a couple of files to an S3 bucket, but it's getting there and it's , you S and then you also still have to worry about like, so the only reason I'm mentioning this is because people always bring this up when I say this. , but they say, well, , What about like the, one of the nice things about just sending up, , a JavaScript files and HTML files to S3 is now I don't have to worry about like the server crashing and runtime problems and like, no, no, you absolutely have to worry about runtime problems because like, eventually that your code is going to run.


It's going to run, whether it runs on the server or the client makes no difference, you have runtime problems. And so, , You that is no different with this. The only real difference is now you have a server, which if you're using any of these services, which you probably should be, then, , then it's basically a non issue.

, and so yeah, remix is embracing all of the really cool things of, the, , fundamentals of the web, the foundations of the web, with browser caching and, history. And, and then they add some of the really cool things like, , nested routing and, , Like actual single file, components where you have, here's how I get my data right here.


And this runs on the server. Here's what happens when the user posts some form or does some mutation? That's my action. And then here's what's going to render for the UI. And then they have like Arab boundaries, things for your, each module. You can specify what happens when there's an error. , and then you also even have a pending UI, so they can, this is so crazy, but, but they can, they can render your application.


And if you have a pending UI for a particular, , component, then they'll just say, okay, I'll just render the pending UI. And we'll fill that in on the client when that request finishes. So if you have something that's expensive, you just slap a pending UI in there and it's done. And it, it, it works even.

Even if that pending UI is like a parent, and then it has children that aren't pending. It will just, , you can render the children who aren't pending and then that, that parent can just have the part of its UI. It's outrageously cool. , and the, just the API, , and non API for remix is really cool.


So they give you access to the HTML document. You're the one responding to the request. And so you're the one calling react to render, to, render to stream if you want to, or render to string. Uh, you're the one calling react on hydrate. , and so, because you're responsible for all of these things, you have, an enormous amount of control with zero API, re remix.


Doesn't need to, to give you a special API for overriding the document or, or anything. And because it's nested, , , A nested router. You don't have to worry about rendering your layout component for every single page, which you do with, with Gatsby and next, , which is a point of frustration for people who have experienced this.


, and, yeah, so there, there are a lot of really cool things about remix, but foundationally for me, it is all about giving me a really nice mechanism for using the cool things of the web fundamentals with the really awesome advances that we've had in the innovations in the JavaScript front end side, too.


Matias: [00:54:18]
I have the feeling that they take real ownership about that sentence of, “use the platform.” Yeah. I think that's coming along, but this is actually real. They're all there. The ATD, because the video that Ryan recorded on YouTube, is actually awesome. Yes. I compare it with Belkin because this is the end product that you can deliver an application without any JavaScript at all, because it's just not required as I think it's pretty amazing.


Kent: [00:54:49]
Well, with remix you, because you're responsible for rendering the HTML element. So the root element, , it's very trivial to, , to not render the script tags. Uh, and so you can, , do your whole application and, because of the way that they do mutations. , your whole thing can work without, , without JavaScript.


And, and what's really cool about this actually is, , you can build your, your application to work really nicely. Client side. It shows error messages and stuff, , for all of you mutations and whatever. And then if for some reason, the JavaScript fails to load. This has happened to all of us where the JavaScript fails to load for some reason, , with remix because of the way that they structure their API APIs.


, and, and the way that is the idiomatic way to do this, your application will work exactly the same. Uh, even if there's no JavaScript on the page. So people will be able to submit their forms. They may get a full page refresh, , you know, cause it's a form that's posting, , but error messages will still re render and everything.


Uh, and uh, like if, if there is an error in the form, everything will, will still work. And so. Uh, yeah. If you have a use case where you're like, Ooh, I really don't want to have, any JavaScript on the login page because I want that login page to just load like lightning then, , it's trivial to, to add that there's no API for it.



Matias: [00:56:22]
It's just obvious because of the way that it's built. It feels to me, two things, it feels to me that they kind of reinvent the idea of framework because currently JavaScript frameworks are things that you ship with your obligation. And this is something that is just chip delegation, not the framework itself.


Uh, and the other thing is like remix, , a bit as a tooling, mechanism, spill, kit, and other are kind of opening the door to what can be called the third era of JavaScript. Like we are moving past of the client frameworks to something else. Awesome. 


Kent: [00:56:56]
Yeah. And this, and it comes with builds that take 50 milliseconds.


Well, yeah, it's pretty great. I'm a really big fan of that. 


Matias: [00:57:08]
 Okay. So we are, almost at the end of this amazing conversation on Kent. Thank you for coming by. Uh don't. I'm not sure. Do you want to obviously look at something and recommend something to the audience?

 

Kent: [00:57:22]
Ooh, , yeah, so I, I don't know, like, a recommendation just in general.


, I think that you can be really, really awesome. Solid developer and really good at coding and stuff. , but no matter how good you are at coding, if you aren't nice, you won't find satisfaction in life. , you will always be chasing something, to make you happy. , and I think that finding happiness in life has a great deal to do with the amount of happiness that you work to bring in other people's lives.


And, , and kindness has a lot to do with that. So, yeah, I guess if there was anything I would recommend to the audience it's, , to evaluate how kind you are, , or how kind you were in your last interaction and work on improving that every day. 


Matias: [00:58:16]
I love it because we are humans and we are not just technical skills collection.


We are human and we work with other humans. So be kind, be happy is part of our goal somehow.


Kent: [00:58:29] I don't know what you're doing if you don't want to be happy. 


Matias: [00:58:33]
Yeah. Yeah. , obviously as a plug, I will do it, eh, epic reactor dev go to material react on the web. So all of these things that Ray can mention through his talk will be in the show notes as always, and, hopefully transcriptions also.


So thank you for being here. Uh, can again, I'm not sure. Oh, one last question. Who else should come to this show? 


Kent: [00:59:03]
Ooh, that's a good one. , I, I've got a number of, of people in my discord community that are just awesome. , that I could mention to you and maybe I'll, I'll shoot you an email or something, but, , I.


Anybody that's been on one of my podcasts, would be awesome. So go check out Kent C dodds.com/podcast. We have three seasons, season four is coming soon. , and yeah, like the people that I want to hear on a podcast are, are the ones that I invite to mine. So there's also epic react has a, a kind of a podcast sort of thing in it as well.


So you can go take a look at, at the people that I had on, on that. And they're all like react focused, obviously. , so yeah, it's the epic react to expert interviews. , and they're all fantastic people. I'd love to see you on this podcast.


Matias: [00:59:53]
Really awesome content there too. So yeah. Thank you, Kent. This was awesome.


Kent: [00:59:58]
Thank you. It's been a pleasure 


Matias: [01:00:01]
and we hear us, in the next week.



Testing
React is a state management tool
Composition with React
UI State and Server State
useEffect
Typescript
Remix.run