Remix: Simplifying Web Development

Bienvenidos a todos. Estoy muy emocionado de hablar con todos ustedes sobre Remix. Creo que es increíble y creo que todos vamos a pasar un buen rato aprendiendo sobre Remix. Permítanme preparar mi pantalla. Y este es el repositorio de la masterclass, y esta es la masterclass funcionando localmente. Permítanme aumentar un poco aquí, mover eso un poco. Así que aquí está nuestro esquema. Vamos a, no vamos a pasar por todo esto. Solo tenemos tres horas, así que vamos a trabajar en parte de esto. Quiero darles algo de tiempo con sus manos en el teclado, pero debido a que estamos tan limitados de tiempo, tengo la sensación de que ustedes están más interesados en que yo avance con más contenido que en pasar tanto tiempo con sus manos en el teclado. Esa es mi suposición. Esa es la suposición bajo la cual voy a operar. Así que, debido a eso, les daré un poco de tiempo en algunos de estos como ejercicios, pero la mayor parte del tiempo simplemente estarán observando y haciendo preguntas y cosas en el Discord. Y creo que será el mejor uso del tiempo limitado que tenemos.

Así que hoy vamos a hablar sobre enrutamiento anidado, carga de data, parámetros dinámicos, enrutamiento anidado, mutaciones, enriquecimiento progresivo, y luego hay tarea, todo tipo de cosas que podemos hacer para la tarea. Algunas de estas cosas simplemente las pasaremos por alto y cosas así. Así que quiero darles una introducción a lo que es Remix y cuál es su propuesta de valor única y todo eso. Pero me gustaría poner las cosas en marcha más rápido. Y así creo que vamos a hacer el primer ejercicio y luego daremos la vuelta y haremos un poco de ¿Qué es Remix? Esta es en realidad parte de mi estrategia para aprender. Es simplemente lanzarte al agua. Así que vamos a empezar con el Ejercicio 1 y en realidad no vas a CD en este directorio. Así que la forma en que esto funciona es que tenemos un script especial llamado route runner. Así que esto se llama dev, que puedes ejecutar, NodeDev y luego le das la ruta al ejercicio que quieres y ejecutará ese ejercicio y lo que es genial de esto es que lo ejecutará en un puerto que está asociado al ejercicio. Así que podrías ejecutar todos los ejercicios y todas las versiones terminadas de los ejercicios al mismo tiempo y todos funcionarán, lo cual es bastante divertido y elegante. Así que si ejecutas NodeDev ejercicio cero uno routing, y en realidad un consejo rápido, puedes hacer simplemente cero uno y eso también funcionará así que no tienes que escribir todo, pero luego abres Locos 4001 y te presentan esta página que es el Indy Stack. Así que Remix tiene esta característica para la generación de proyectos donde generas nuevos proyectos y llamamos a estos stacks. Tiene un montón de herramientas y cosas que vienen preinstaladas y preconfiguradas para ti. Y el tutorial por el que estamos pasando se basa en el Indy Stack. Así que ahí es donde vamos a empezar es en el ejercicio uno con básicamente un Indy Stack pregenerado y tu trabajo para este ejercicio es simplemente añadir un enlace aquí, justo debajo de la gran imagen aquí, para llevarte a la ruta de publicación. Vamos a añadir un blog a este sitio. Así que eso es lo que vamos a hacer. Ese es tu primer ejercicio. Vas a entrar en el ejercicio 01 routing, ir al README, y esto te dará un punto de partida y un punto de parada en el tutorial del blog. Así que empezarás con tu primera ruta, y te detendrás justo cuando llegues a la carga de data. Así que no continuarás a través de la carga de data, simplemente te detendrás aquí para este ejercicio. Y así vamos a pegar eso en nuestro índice de rutas j.s. Así que esta es nuestra página de inicio. Ahí es donde queremos que vaya. Y simplemente lo vamos a poner ahí. Realmente no importa dónde esté porque no estamos aprendiendo j.s.x. y estructura adecuada o lo que sea. Eso no importa realmente. Así que venimos aquí. Tenemos un enlace a la publicación del blog. Y cuando hago clic en ese enlace, vamos a obtener un cuatro o cuatro porque aunque en realidad estamos yendo a esa URL, en realidad no tenemos nada allí. Y hecho divertido, porque Remix se renderiza en el servidor, en realidad obtienes un 404 del servidor al ir a esa página, todo lo que hemos estado haciendo en el cliente durante los últimos seis a ocho años. Cuando tienes una ruta que no es compatible, obtienes el índice HTML. Así que obtienes un 200. Y el cliente simplemente dice, Oh, no podemos encontrarlo. Pero Remix debido a que se renderiza en el servidor, puede dar un estado code adecuado, lo cual es realmente bueno para el SEO para que el navegador se comporte de la manera correcta y todo eso. Así que eso es agradable. Pero queremos tener algo allí. Y así en el siguiente paso aquí, hacemos una nueva ruta, y eso está controlado por tener una nueva ruta. Y eso está controlado por tener un archivo en las publicaciones. Y queremos tener el índice para nuestras publicaciones. Así que crearemos una ruta de índice de publicaciones en nuestro directorio de rutas. Así que vamos a hacer publicaciones, y luego índice dot TSX. Y, por cierto, yo, yo simplemente asumí que todos estamos haciendo TypeScript. TypeScript es la forma en que se construyen las aplicaciones web hoy en día. Y si no estás familiarizado con TypeScript, te alegrará saber que en realidad no hay mucha rareza de TypeScript que tengas que hacer con Remix. Hay un poco. Pero sí, es tan agradable. Así que si no estás acostumbrado a TypeScript, puedes sentirte libre de simplemente dejar los tipos fuera, todavía funcionará. Solo obtendrás pequeños garabatos rojos en algunos lugares. No es gran cosa. Bueno, así que simplemente vamos a copiar esto porque de nuevo, no creo que te importe pasar tiempo escribiendo jsx pero lo importante aquí es que nuestro módulo exporta por defecto, un componente de función. Supongo que podría ser un componente de clase. No sé por qué distingo con la función pero exportas una función o un componente. Y, y

Sí, eso es exactamente lo que es. Remix utiliza React Router, Remix proviene de los creadores de React Router. Y así es, React Router está obteniendo muchas características geniales de Remix muy pronto. De acuerdo. Gracias. Sí, de hecho, hace un par de meses, tal vez un par de semanas en nuestro blog, escribimos esta publicación llamada remixing React Router, donde estamos tomando muchas de las características realmente geniales de React Router y llevándolas a, solo voy a dejar un enlace a eso en el discord, llevándolas a. o muchas de las características de Remix a React Router. Y en realidad, podríamos titular esta publicación de manera diferente y en lugar de decir remixing React Router, podríamos decir unreacting React Router porque básicamente estamos tomando todas, estamos tomando todas estas características de Remix y poniéndolas en React Router. Simplemente estamos separando las características principales de Remix y React. Y lo que eso nos permitirá hacer es que ahora React Router es un adaptador para el enrutador de Remix, y luego podemos hacer adaptadores para Vue, Angular, Svelte, Preact y todas estas cosas. Entonces, en realidad, todo el web va a poder aprovechar Remix, independientemente de qué biblioteca de UI decidas usar, lo cual es bastante significativo. Entonces, la versión futura, y esto lo tenemos en prelanzamiento en este momento, estamos pensando en lanzarlo esta semana o la próxima semana, donde tendremos el enrutador de Remix, y luego solo adaptadores para ese enrutador, lo cual es genial. Y los miembros de la comunidad ya están construyendo adaptadores para el enrutador de Remix, para Vue, Angular, Svelte y Preact. Y creo que puede haber otro, no recuerdo cuál, pero, sí, tiempos emocionantes, y sí. Así que definitivamente, Remix solo está utilizando React Router aquí.

Tengo una pregunta muy básica, tal vez, como Remix se ejecuta en el backend, no en el frontend, como, si tuvieras una aplicación React normal, se ejecutaría en el frontend como una aplicación de una sola página, pero Remix se ejecuta en el servidor Node o algo así, ¿verdad?

Sí, sí, pero es una SPA, una aplicación de una sola página cuando se hidrata, y así que si vas a tu página de inicio, eso se renderiza en el servidor, miras el código fuente y ves, como, todo el HTML y todo eso, pero cuando navegas a las publicaciones del blog, no obtienes una recarga completa de la página ni nada, simplemente cargamos el JavaScript necesario para esa página, y haremos lo mismo con el CSS y los datos y todo lo demás también. Así que es una transición del lado del cliente que está sucediendo aquí, por lo que obtienes transiciones de página, gestión de enfoque, todas esas cosas.

Ahora que hemos hecho el primer ejercicio, quiero tomar un momento para hablar sobre qué es Remix, y esta cosa con la que acabas de jugar por un segundo, así que Remix se enfoca en los estándares web y en la experiencia de usuario de las aplicaciones web modernas. Podríamos decir que estamos mezclando lo antiguo con lo nuevo, y así que en Discord, voy a decir levanten la mano, levanten la mano aquí, moveré esto para que puedan ver lo que estoy haciendo. Si han estado, o en realidad vamos a hacer cuántos años han estado en desarrollo web. Y así que si han estado durante nueve años, nueve, ahí vamos. Si han estado durante nueve o más, oh, vaya, eso debería haber estado aquí. No dejen de chatear. Solo vamos a hacer reacciones con emojis. Son demasiado rápidos. Si han estado durante nueve o más, entonces pongan nueve, de lo contrario pongan ocho o siete o sí, el número, ya lo entienden. Para mí, empecé en desarrollo web oficialmente en 2014. Así que eso me da ocho. Ahí vamos, genial. De hecho, tenemos bastantes de ustedes que han estado durante nueve o más años. Veamos. Así que para aquellos de ustedes que han estado durante nueve o más años, esto les resultará muy familiar y muy cómodo porque Remix toma las cosas que funcionaron muy bien en la web hace 10 años, y luego mezcla las cosas que funcionan muy bien en la web moderna en estos días. Así que lo que molesta a las personas que han estado involucradas en la web durante mucho tiempo acerca de la web moderna es lo difícil que es construir un sitio web en estos días. Hay tantas cosas que tienes que hacer. Tienes tus herramientas de construcción, tienes tus linters y formateadores, y tienes tu JSX, y tienes tus cosas de JavaScript. Y ahora tienes que administrar el estado en la interfaz de usuario y tantas cosas que tienes que hacer en estos días que no tenías que hacer antes. Y siempre me convencía y decía, bueno, sí, pero nuestras aplicaciones son mucho mejores de lo que solían ser. Podemos hacer mucho más de lo que solíamos poder hacer antes. Y sí, eso es cierto. El navegador es mucho más capaz. Buena suerte construyendo Figma a fines de los 90 o principios de los 2000. Sí, eso es absurdo. Así que eso es en lo que siempre me convencía. Pero lo que Remix logra hacer es, lo que nos gustaba de la forma antigua de construir sitios web es que no tenías que preocuparte por administrar el estado en el navegador. Todo el estado básicamente vivía en la base de datos y tal vez pondrías una caché en algún lugar para que las cosas fueran más rápidas.

Pero en su mayor parte, el estado vivía en la base de datos. Así que cuando un usuario solicitaba una página, simplemente obtenían lo último de la base de datos. Y cuando hacían una publicación, actualizábamos la base de datos y luego les enviábamos un nuevo HTML basado en lo que estuviera en la base de datos en ese momento. Así que era realmente un modelo mental simple porque nunca te preocupabas realmente por el estado. Tal vez ponías algunas cosas en una cookie o algo así para administrar cosas a través de páginas que son locales a un usuario específico. Pero en su mayor parte, la gestión del estado era realmente simple.

Luego introdujimos JavaScript en el lado del cliente y ahora tenemos que gestionar el estado en la interfaz de usuario, que es efectivamente solo una caché en el backend, y las cosas se complican mucho porque tenemos una barrera de E/S de red, que es nuestra red. Las cosas se vuelven realmente complicadas. Lo que Remix ha logrado hacer es brindarnos el modelo mental de lo antiguo donde no pensamos en el estado y las capacidades de lo nuevo donde tenemos, nos gustan las transiciones de página, la gestión del enfoque para la accesibilidad, mensajes de error animados, manejo de errores en el lado del cliente o, a medida que escriben, mostrar un mensaje de error. Todo eso se vuelve realmente, realmente difícil si quieres combinar algo renderizado en el servidor con algunos toques de JavaScript. Remix logra que se sienta como si no fueran solo toques de JavaScript. Es una experiencia completa de SPA, pero también nos brinda el mismo modelo mental de los viejos tiempos.

Como ejemplo rápido de esto, alrededor del momento en que desechamos el mejoramiento progresivo como un mundo del software y dijimos, oh, cuando estás construyendo una aplicación realmente complicada, tienes que poner toda la aplicación en JavaScript, creamos esta cosa llamada TodoMVC. TodoMVC era solo para comparar todas estas diferentes bibliotecas de interfaz de usuario en una sola aplicación para facilitar las cosas. Entonces tienes esta aplicación donde puedo escribir lo que sea, puedo marcar estas cosas y todo eso, y todo se almacena en el almacenamiento local. Recientemente hice una versión remixada de esto, y ahora, en realidad, ¿tengo una contraseña para esto? No puedo recordar, espera un segundo. Sí, intenta adivinar esa contraseña. Es extremadamente larga. Aquí vamos. Genial, así que implementé esto. Ah, y por cierto, tiene autenticación de usuario. Y tiene persistencia real en una base de datos. Y así puedo iniciar sesión en esto en cualquier dispositivo y tener todas las mismas tareas pendientes. No es algo que hiciera TodoMVC. Además, es accesible mediante el teclado. También es algo que TodoMVC no era. Así que sí, implementé esto, y lo realmente genial de esto es que puedo demostrarte que al construir una aplicación web con Remix, no tienes que pensar en un estado de interfaz de usuario. ¿Quieres saber cómo puedo demostrártelo? Sin siquiera mostrarte el código, ni siquiera tengo que mostrarte el código. Así es como lo demuestro. Digo que JavaScript está desactivado. Y así no hay JavaScript en la página. Si estuviera gestionando mi estado en la interfaz de usuario, no podría hacer esto y que siga funcionando, pero sigue funcionando perfectamente. Entonces no hay código en mi aplicación para esta implementación de esta aplicación que gestiona un estado de interfaz de usuario. Así que, imagina en tu mente todo el código que escribes en tu interfaz de usuario que gestiona el estado. Probablemente sea como el 30 al 50% de tu código que escribes es sobre el estado. Tienes tu Redux o tienes tu MobX o tienes cualquier otra biblioteca de estado, si estás usando el contexto tú mismo, lo que sea que estés haciendo. Probablemente alrededor de la mitad del código que escribes se dedica a gestionar el estado. Remix hace que no tengas que hacerlo. Y, por supuesto, los usuarios no desactivan JavaScript en su navegador, pero esto es solo cómo te demuestro que no necesitas gestionar el estado en una aplicación de Remix porque Remix lo gestiona por ti. Así que cuando habilito JavaScript, todo funciona y funciona mejor porque no tenemos que hacer actualizaciones completas de la página. Pero nuevamente, no tuve que cambiar mi código de ninguna manera. Remix se encarga de todas esas cosas por mí y funciona muy bien. De hecho, esta aplicación es realmente increíble porque incluso si estoy en una red muy lenta, puedo marcar estas cosas y parece que se marcan instantáneamente. Hay mucho más en esto y tengo una charla donde profundizo mucho más en esto, pero esto se llama Optimistic UI y es increíblemente impresionante. Es súper, súper genial, donde aunque la solicitud realmente tarda dos segundos porque estoy en una red simulada 3G lenta, la interfaz de usuario se actualiza instantáneamente y Remix hace que hacer ese tipo de cosas sea realmente, realmente fácil. Es extremadamente resistente a las malas condiciones de la red. Esa es una de las partes más geniales de Remix, que simplifica tu modelo mental. Puedes desechar todo el código que tienes para gestionar el estado cuando estás construyendo aplicaciones de Remix. Eso es realmente genial. Además de eso, admitimos enrutamiento anidado de la interfaz de usuario, y así como creo que Ling estaba hablando antes o no, no creo que fuera Ling. Fue alguien más, no puedo recordar. Alguien estaba hablando antes, tenemos React Router V6 y así tenemos estos componentes de salida de los que estábamos hablando y así para cualquier interfaz de usuario dada, tienes esta relación entre padre e hijos que están asociados a diferentes segmentos de la URL. Y así para nosotros, teníamos /publicaciones y así creamos ese directorio /publicaciones y ese módulo y mostré cómo el archivo padre post.tsx podría tener algún envoltorio alrededor y luego renderizaría un outlet. Y así es como funciona esa asociación a través de esa convención y a través del componente outlet. Entonces el padre dice, aquí está toda la interfaz de usuario que quiero y si tengo hijos, aquí es donde van y esto tiene enormes implicaciones en tu experiencia de desarrollo mientras desarrollas tu aplicación, así como en la experiencia del usuario mientras cargamos datos y cosas cuando estás trabajando en esta parte de la interfaz de usuario que es solo un archivo único que dice, aquí está la interfaz de usuario que renderizo y aquí están los datos que necesito para hacer ese renderizado. Y sí, de hecho, sabes qué, he implementado esta aplicación y podemos ver específicamente esa ruta si vamos a ventas, facturas, ID de factura. Y así tiene el cargador para cargar los detalles de la factura. Esto es literalmente todos los datos que ese... En realidad, implementé más porque también tengo como depósitos y cosas así, pero tiene todos estos datos que necesita la interfaz de usuario. Todo está aquí mismo ejecutándose solo en el servidor. Así que puedes hablar directamente con tu base de datos y cosas así. Eso es lo que hace esta función get invoice details. Y luego la interfaz de usuario aquí abajo simplemente dice, ey, obtén mis datos para lo que necesito renderizar y lo renderizará en JSX. Y así no te preocupas por cómo se ven tus estados de carga en esta parte del mundo ahora. Por supuesto, a veces la carga llevará algún tiempo porque tienes una red y a veces es lenta. Y así tenemos API realmente geniales para los estados pendientes. Pero esto simplifica drásticamente esto porque no te preocupas por mantener estos datos actualizados. Remix mantendrá estos datos actualizados automáticamente por ti, manejando todo el abismo de la red por ti. Y no hay nada aquí que diga, oh, bueno, mi ruta principal necesita estos datos, así que también voy a cargar un montón de datos de mi ruta principal. Esto es literalmente lo que esta subruta necesita para renderizar lo que va a renderizar y todo lo demás es gestionado por sus padres.

Entonces, el padre para este será el invoices.tsx y renderiza todas las cosas que quiere más el outlet, vamos a encontrar eso, sí, justo aquí. Ahí está el outlet. Aquí es donde estará la lista de facturas, supongo. Y entonces, el padre es solo responsable de sus data. Aquí está eso justo allí. El padre solo necesita los elementos de la lista de facturas, el monto vencido y el monto que vence pronto. Así que aquí podemos ver eso justo aquí. El monto vencido, el monto que vence pronto y la lista. Y luego, en el lado derecho de la lista, simplemente renderizamos donde está nuestro hijo. Lo mismo con la ruta de ventas. Entonces, si vamos a sales tsx, esta es la ruta padre aquí. Es responsable de renderizar todos estos enlaces y luego renderiza el outlet y eso es todo. Solo renderiza los enlaces y luego el outlet. Y luego la ruta de diseño padre aquí es este apt-tsx y está renderizando todos los NavLinks a la izquierda. De hecho, tenemos nuestro spinner para si alguna vez hay una transición en curso. Noté que Stefan está aquí y Stefan en realidad escribió esta biblioteca, Spindlay. Así que saludos a ti, Stefan, esa biblioteca es increíble. Y renderizamos nuestro outlet justo allí. Así que es la ruta de diseño para nuestra aplicación es responsable de este Nav izquierdo y luego renderiza el outlet y dice, si tengo algún hijo, aquí es donde van. Así que esto es increíble. Así que imagina que estás en una empresa y tienes como tres equipos trabajando en una aplicación o incluso solo como dos ingenieros trabajando en una aplicación como escala para aplicaciones pequeñas a aplicaciones realmente grandes. Y entonces uno de esos equipos diremos que es responsable del diseño general de tu sitio. Hacen el encabezado y hacen el pie de página y luego no les importa nada más. Sin enrutamiento de diseño de UI, esos equipos tienen que comunicarse sobre los data que necesitan renderizar. Porque si cada página en esa aplicación necesita renderizar el encabezado y el pie de página y tienes un equipo que es responsable de eso. Cada vez que ese equipo necesita actualizar el encabezado y el pie de página, necesitan comunicarse con todos los equipos y decir hey, necesitas pasarme estas propiedades adicionales o lo que sea. Y entonces lo que típicamente sucede es que decimos, vamos a administrar como cargar los data que necesitamos en el cliente y de esa manera no tenemos que comunicar esto a nadie. Solo lo cargaremos junto al componente que estamos renderizando y entonces no tienen que pasarnos ninguna propiedad. Esto lleva a una mala experiencia de usuario porque terminas con este tipo de estado de carga rebotante en lugar de, en realidad tengo libros falsos aquí. Y si inicio sesión y vamos a la página de ventas, iremos a facturas. Sí, todos mis clientes están atrasados, están en problemas. Pero si voy a esta página, notarás que se renderiza al instante y eso es exactamente lo que estamos demostrando aquí es que boom, está renderizado. Se ve increíble. En lugar de tener esta experiencia rebotante que tenemos en todas partes. Mira esto, voy a chase.com y tenemos un montón de spinners por todas partes. ¿Qué es esta basura caliente? Sin ofender a chase.com porque casi todos los sitios están haciendo esto. Twitter.com. Tenemos cosas rebotando, oh, en realidad oculto esto porque no me gustan estas imágenes pero a veces tienen cosas realmente estúpidas pasando por aquí. Pero tienes spinners por todas partes, por toda la web. ¿Por qué le estamos haciendo esto a nuestros usuarios? Hay una razón, hay una buena razón y ya no tenemos que hacerlo porque existe Remix. Así que sí, en lugar de tener la experiencia rebotante a la izquierda, podemos tener esta experiencia ágil a la derecha, dar a nuestros usuarios una experiencia de usuario mucho mejor y podemos tener una experiencia de desarrollo increíble porque el equipo que es responsable del encabezado y el pie de página solo puede ser responsable de esas cosas y no les importa el hijo y al hijo no le importa el padre. Esto es, tal vez esa metáfora no es buena porque los padres deberían preocuparse por sus hijos y los hijos deberían preocuparse por sus padres. Pero en el mundo del Enrutamiento Anidado, no tienen que preocuparse y creo que eso es increíble.

Bueno, también nos gusta, hay muchas cosas realmente impresionantes que Remix puede hacer porque es tu bundler y tu compilador y tu biblioteca de obtención de data como prefetching data basado en donde el usuario va a estar y por lo tanto la navegación es realmente, realmente rápida. Y luego las mutaciones de data son realmente buenas y también veremos eso, básicamente es solo este formulario, eso es todo. Tienes un formulario y luego en el servidor tienes esta acción y esas dos cosas están literalmente en el mismo archivo. Así que aquí en el ID de la factura, tenemos esta acción que puede, será llamada cuando queramos crear un depósito en una factura. Y esto solo se ejecuta en el servidor y tu formulario asociado está justo aquí y es increíble, es tan, tan, tan, tan genial. Así que entraremos en eso un poco más tarde pero Remix se encarga de mantener tus data actualizados, gestiona los reenvíos de formularios, gestiona las condiciones de carrera, todas las cosas que normalmente pasamos por alto cuando estamos construyendo esto nosotros mismos porque estamos demasiado ocupados intentando conseguir que las cosas se envíen en primer lugar. Y Remix se ha encargado de todo eso por ti. También se manejan los estados de error y es impresionante pero no tenemos tiempo para profundizar demasiado en eso.

Tengo una pregunta sobre scalability y servidor, me estaba preguntando, mi equipo está haciendo un proyecto con Next.js en este momento y estamos teniendo grandes discusiones sobre cómo renderizamos para evitar costos de servidor y así sucesivamente. ¿Cómo escala Remix en esta situación? ¿Cómo se desempeñan?

Sí, esa es una gran pregunta. Entonces, en un escenario de Next, tus conversaciones probablemente son como, bueno, vamos a hacer SSG en esto para no tener que golpear nuestro servidor. Lo interesante de ese enfoque es que a menos que todo en la página sea totalmente estático, lo cual supongo que no es, como tendrás spinners de carga para tener data, todavía estás golpeando tus servidores. Y entonces para ir a buscar esa data. Ahora, tal vez estás usando un tercero, por lo que no estás golpeando realmente tus servidores, estás golpeando los de alguien más. Y en ese caso, sí, obtienes un beneficio. Pero diré que puedes hacer lo mismo en Remix. No admitimos SSG, pero SSG es solo una implementación personalizada de una CDN con encabezados de caché. Y entonces, si quisieras tener eso, la misma especie de idea que SSG usando Remix, que no, no admite SSG entonces simplemente configurarías una CDN como Cloudflare o Fastly o lo que sea. Configurarías eso, y luego tendrías tu servidor enviando de vuelta directivas S max H en tu encabezado de caché. Y luego la próxima vez que alguien venga la CDN dirá, Oh, eso está en caché, déjame enviar la versión en caché. Así que no va a golpear tu servidor. Así que obtienes las mismas características de performance con SSG sin tener que hacer SSG. El beneficio realmente agradable de esto es que si vas con SSG desde el principio y luego decides más tarde, Oh, necesitamos algo más, como queremos renderizar esto en el servidor en realidad. Tienes que reestructurar completamente tu solución. Si comienzas con la renderización del servidor y solo usas encabezados de caché, y luego te das cuenta, Oh, necesitamos renderizar más en el servidor. No podemos simplemente tenerlo en una caché compartida. Entonces simplemente apagas los encabezados de caché y boom, ahora estás renderizando en el servidor. Pero en cuanto a scalability, si eso es una preocupación, entonces simplemente usa encabezados de caché. Y luego sí, ten en cuenta que no estás resolviendo problemas de scalability si tienes que hacer solicitudes de red para obtener data de usuario, porque como, todavía estás golpeando tu servidor en ese caso. Así que sugeriría encabezados de caché. Y si, como, si no quieres tener un montón de spinners por todas partes, entonces sugeriría cachear en el servidor con algo como Redis. Y sí, lo que es realmente genial acerca de Remix es que en lugar de darte muchos enfoques diferentes a un problema, te damos palancas a un problema, para manejar diferentes casos de uso y necesidades. Y entonces, en lugar de tener que tomar este enfoque para este caso de uso y este enfoque para este caso de uso, en realidad solo tomas un solo enfoque y luego usas la palanca para cambiar en una base por ruta las cosas que necesitas. Y en realidad, una charla realmente genial que Ryan dio recientemente en Reactathon, Reactathon, ver videos. Veamos qué, sí, ahí está. Déjame agarrar esa URL, y simplemente la pegaré en discord y alguien puede ponerla en la cosa de toma de notas si quieren. Pero aquí habla un poco sobre esas palancas y algunas de las cosas realmente, realmente geniales que vendrán muy pronto también.

Tengo una especie de pregunta solo porque también estamos en el tema de Ryan Florence. Creo que vi un tweet de él hace un tiempo donde hablaba de responder a la pregunta ¿cómo maneja Remix los websockets y cómo a menudo esa es solo una especie de pregunta sobre si maneja escenarios de múltiples usuarios en tiempo real? Y la respuesta que propone allí es como eventos de servicio y fuente de eventos, lo cual creo que es muy interesante y convincente cuando la especie de comunicación que quieres tener en tiempo real implica una presentación de formulario, pero como trabajo en un equipo donde estamos construyendo una aplicación que es algo así, supongo, tan en tiempo real como algo como Figma, donde quieres poder ver las posiciones del ratón de los otros usuarios o hacer que tomen acciones que no implican presentaciones de formularios y luego propagar ese estado a través de la aplicación a múltiples clientes. ¿Es eso algo que la especie de capa de red de Remix está considerando tratar de resolver o es eso demasiado profundo y específico de una pregunta para ahora?

No, no, no, esa es una gran pregunta. Primero, diré que Remix admite WebSockets tan bien como cualquier otro framework que podrías usar, por lo que no hay nada que esté mejor adaptado para WebSockets que yo sepa. Así que si esa es la elección de tecnología que quieres hacer, eso está totalmente bien. Pero no creo que los eventos del lado del servidor requieran una presentación de formulario. Así que puedes configurar una solicitud de eventos del lado del servidor sin tener una presentación de formulario en absoluto. Así que podrías hacer totalmente Figma, posición del ratón, todas esas cosas con eventos del lado del servidor. Y el beneficio de usar eventos del lado del servidor es que es solo una solicitud, por lo que hay muchas cosas realmente geniales que vienen con eso. Y es compatible ahora mismo de fábrica con Remix. Puedes tener una ruta de recurso que envía una respuesta que establece esa transmisión de eventos. Y sí, y podrías construir totalmente ese tipo de UI con eventos del lado del servidor. Y creo que es una tecnología subutilizada porque tenemos WebSocket's y pensamos, está bien, esto es increíble. Y realmente es bastante genial. Aunque difícil de scale, por eso tenemos cosas como Pusher. Pero sí, diría que tal vez mires de nuevo los eventos del lado del servidor si quieres, pero si estás contento con WebSockets, eso también es genial. No sé, tal vez eventualmente tendremos algo, algún soporte incorporado para WebSockets, pero estamos más interesados en pensar en casos de uso. Y creo que el caso de uso que describiste está bastante bien respaldado por eventos del lado del servidor. Pero no tengo mucho tiempo para profundizar en eso aunque.

Así que ten en cuenta que tu número de puerto, vaya, esta es la aplicación equivocada. El número de puerto que estás mirando cuando estás mirando la aplicación debe corresponder al ejercicio en el que estamos. Así que estamos en 4001, es el ejercicio uno. Así que ahora quieres empezar en el ejercicio dos, así que ahora el número de puerto debería ser 4002. Así es donde deberías estar. Tenemos el enlace del blog post, obtenemos el post aquí. Y para el ejercicio dos, estamos en data loading. Si vas al read me, te mostrará que comiences con la carga de data y luego te detengas cuando llegues a sacar de una fuente de data, que apareció en mi otro navegador. Sí, así que detente aquí cuando termines con la sección de carga de data aquí. Así que tuve un par de preguntas que simplemente responderé aquí muy rápido y luego podemos meternos en realidad en esta parte del ejercicio. Así que Felix en el chat de Zoom preguntó, ¿cómo compartes data entre rutas? Así que si necesitas tener data compartida entre rutas, tenemos esta cosa llamada use matches que te permite compartir esa data o acceder a data en otras rutas. Cuando hablas de entre rutas, es solo de padre a hijo o de hijo a padre. Así que si el padre necesita acceso a algo que el hijo tiene para un UI de migas de pan o algo así, para eso es use matches. Si el hijo necesita algo que el padre tiene, entonces también usas matches. Y en realidad hacemos eso como parte integrada del Indy stack en nuestros utils aquí para obtener el usuario. Así que tenemos este gancho de data use matches que escribí que básicamente usa los matches, encuentra las rutas por el ID de la ruta. En este caso, el usuario está en la ruta de la ruta y entonces simplemente obtenemos la data de la ruta de la ruta. Y luego obtenemos el usuario de eso. Y entonces, sí, puedes compartir eso arriba y abajo de la cadena y es bastante sencillo. No te encuentras a menudo teniendo que hacer esto más que solo para data de usuario pero a veces sí. Y por eso tenemos soporte para eso en primer lugar. Así que sí, espero que eso responda a esa pregunta.

Y creo que eso fue todo. También hubo una pregunta sobre dónde se almacenan los data. Así que en nuestra aplicación, estamos usando Postgres o SQLite, pero sí, como el almacenamiento de data está fuera del alcance de donde Remix está actualmente. Tal vez un día tengamos como un ORM incorporado y una database incorporada o algo así, pero eso es bastante improbable. Tus data pueden estar en un tercero o pueden estar en tu propia database o donde quieras que estén. Pero sí, Remix simplemente lo hace realmente fácil para obtener data dentro y fuera de tu UI.

¿Es Remix la herramienta adecuada para un widget? No usarías Remix para el propio widget porque Remix se trata de la aplicación completa y de las rutas y cosas así. Un widget realmente no hace nada de eso. Pero sí, puedes totalmente, creo que Nick en realidad respondió a esto. Puedes publicar un componente de React, usar eso en cualquier lugar. Probablemente así es como yo lo haría. Sí, creo que eso es bastante, oh sí, en cuanto a cómo Remix obtiene data del servidor. Así que hay como un esquema de URL especial que es un detalle de implementación que no deberías utilizar tú mismo para hacer estas solicitudes para obtener estos data. Así que tenemos este cargador. Remix hace una solicitud de fetch especial para obtener esos data durante las transiciones del cliente. Pero podrías hacer totalmente lo que llamamos rutas de recursos, que son rutas que no tienen una exportación por defecto. Si no tiene una exportación por defecto entonces es una ruta de recurso, puedes golpear esa URL directamente. Y así podrías tomar tu API REST o lo que sea tu API GraphQL, construirla en Remix como rutas de recursos, y luego tu mobile app podría usar eso. Y en realidad estamos pensando que debería ser posible en el futuro construir una web y una mobile app, como una aplicación React Native, en Remix y tener esta co-ubicación tal como lo hacemos para el lado web. Creo que eso debería ser posible y eso sería bastante legítimo. Así que no estamos trabajando activamente en eso, pero eso es algo en lo que hemos pensado.

Vale. Sí, pregunta sobre por qué console log dentro del cargador solo aparece en la terminal, mientras que en el componente, aparece tanto en la terminal como en la UI o el navegador. Entonces la razón es que tu función de carga y que carga data solo se ejecuta en el servidor. Esto es genial porque significa que puedes usar claves privadas. Puedes hablar con una database. Puedes hacer todas las cosas que son realmente molestas. Puedes usar bibliotecas realmente pesadas y no tener que enviarlas al navegador. Todo tipo de cosas que puedes hacer en este cargador. Y luego remix es solo el que se asegura de que podemos ir entre el cargador y el navegador y obtener esos data a través de ese abismo de red. Y por eso estás viendo los console logs aquí solo aparecen en la terminal porque ese es el único lugar donde se está ejecutando. Para tu componente, estás viendo el console log en la terminal porque se está ejecutando en el servidor para el renderizado del servidor. Y luego lo ves en el navegador porque se está hidratando. Así que eso es lo que está pasando allí.

Genial, estupendo. Así que vamos a trabajar en esto. Tenemos, cerramos todas estas cosas y volvemos aquí a nuestro readme. Así que todos estamos en la misma página. Esa es una ventana de navegador diferente. Ahí vamos.

Bueno, vamos a manejar la carga de data. Necesitamos un cargador para nuestras publicaciones porque vamos a tener un montón de publicaciones aquí. Así que voy a coger esto y llevarlo a nuestro índice de publicaciones para que podamos listar un índice de todas nuestras publicaciones. Déjame deshacerme de esa terminal.

Así que este json es una función especial que vamos a obtener de Remix Run node. Y en realidad no es tan especial. Realmente lo que es es una nueva respuesta y esto es json o json-stringified y luego encabezados de aplicación json. Eso es básicamente todo, oh, y también estado 200. No 2000, solo 200. Esto se está quejando porque, oh, correcto. Esto necesita ser, ah, tipo de contenido. Ahí vamos. Eso es todo lo que es json. Es útil y no quiero tener que escribir eso cada vez, básicamente siempre estás usando json en tu cargador y por eso tenemos la función pero eso es todo lo que está haciendo. Está creando una nueva respuesta. Ahora, como mencioné, esto solo se ejecuta en el lado del servidor y por lo tanto en entornos donde el servidor no soporta solicitud de respuesta, Remix está convirtiendo lo que sea que sea la solicitud para tu cosa serverless o tu cosa Express o lo que sea que estés usando, convierte esa solicitud en una solicitud Web Fetch y la emula en esos entornos donde la solicitud Web Fetch no es soportada y luego la respuesta que envías, convierte esa respuesta Web Fetch en lo que sea que tu serverless o tu Express o lo que sea necesite para su respuesta y así que eso es una cosa realmente genial acerca de Remix es que normalizamos la respuesta de solicitud en cualquier plataforma en la que estés ejecutando a la API Web Fetch. Así que siempre estás trabajando con la plataforma web y no tienes que preocuparte por los detalles específicos de cualquier objetivo de implementación que estés apuntando.

Genial, así que estamos enviando nuestro JSON con esta publicación y para acceder a ese JSON, vamos a decir use loader data, ups, use loader data, ahí vamos. Para obtener nuestras publicaciones, simplemente desestructuramos eso y cl publicaciones. Genial, así que si hago console log de eso y vengo aquí y refresco entonces vamos a ver nuestras publicaciones ahí mismo. Tenemos nuestras publicaciones, déjame aumentar eso un poco. Genial, todo eso vino del servidor. Esto, como se mencionó, si hacemos console log aquí en el servidor y guardamos eso, si miramos aquí, en realidad vemos aquí en el servidor y luego vemos nuestras publicaciones, eso es para el renderizado del servidor. Y luego si venimos aquí, solo vemos las publicaciones. Así que esa es una pequeña característica muy útil de Remix manejando esa transición. Y también esto funciona totalmente para una transición del lado del cliente también. Así que hacemos el renderizado del servidor aquí y hacemos clic en este enlace. Todavía vamos a obtener ese log que muestra las publicaciones, todavía vamos a obtener este log. Pero notarás que no obtenemos... Oh aquí en realidad, hagamos esto. Renderizado del servidor de publicaciones. Hagamos eso. Vale, así que si vengo aquí y ahora borramos todo eso. Así que hago una transición a la publicación del blog. Vemos, oh ja ja renderizado del servidor de publicaciones. Ese no era ese componente, eso está mal. Pero no verás el renderizado del servidor de publicaciones en la terminal porque esta es una transición del cliente. Así que no necesitamos ejecutar la exportación por defecto. Eso ya ha sido hidratado. Todo eso está ahora en el cliente así que no necesitamos volver a renderizar esto en el servidor o algo así. Así que no hay registros cuando estás haciendo esa transición del lado del cliente. Espero que eso tenga sentido.

Bueno, genial, tenemos nuestra publicación. A partir de aquí es solo tonterías de JSX así que no vamos a molestar con eso. Voy a copiar y pegar esto y lo pego justo ahí. Traigamos el enlace desde RemixRunReact. Guardamos eso y ahora tenemos todos nuestros listados de nuestras publicaciones. Y luego hacemos algunas cosas de TypeScript. No creo que te importe aprender cómo escribir todo esto correctamente o al menos no necesitas que yo escriba los tipos. Entonces, lo que hacemos aquí es que JSON es un genérico donde puedes pasar los datos del cargador. ¿Qué?, bueno, esto es un error. Necesito hablar de esto, maldita sea. Si alguien quiere hacer un PR al tutorial por favor hágalo porque esto está mal. No deberías usar el genérico aquí y te explicaré por qué en un segundo. Pero sí, entonces solo estamos definiendo, oye, este es el JSON que debería devolver este cargador. Esta es solo una convención que en realidad no importa si eso, esta es la forma en que lo haces. Podrías ponerlo en línea allí o lo que sea. Podrías llamarlo como quieras. Pero yo lo llamo datos del cargador y es un array de publicaciones que son slug y título. Y luego, en el lado del cliente o en el lado de la UI, tenemos estos datos del cargador. Estamos usando este genérico para usar los datos del cargador. No deberías hacer eso. Y la razón por la que no deberías hacer eso es porque esto es exactamente lo mismo que esto. Porque no hay forma de que use loader data realmente sepa que los datos que estás obteniendo son el genérico que pasaste. Así que esto no es algo específico de Remix. Esto es algo específico de TypeScript. Entonces, aquí tienes un consejo rápido. Entonces, si obtengo algo, y luego aquí está mi genérico, y luego devuelvo i como genérico, nunca hagas esto. Casi nunca hagas esto, a menos que sepas absolutamente que esto es realmente la cosa que crees que es. Porque ahora puedo decir foo es igual a get thing como un número. Y ahora foo es, ¿es eso un número? Oh Dios mío, es un número. Pero en realidad no lo es, y no sé que acabo de mentirme a mí mismo. Porque cuando haces un genérico que dice que aquí está la cosa que debería ser devuelta, piensas que la función está manejando eso de alguna manera. Pero lo que realmente está haciendo es simplemente mentirte. Está diciendo lo que sea, lo que quiera decir. Entonces, por eso decidimos deshacernos del, o depreciamos el genérico, porque te estás mintiendo a ti mismo. Realmente no tenemos forma de saber, con certeza que no hubo algo extraño que sucedió a través de la red para volar tus datos del cargador o agregar propiedades o quién sabe qué hizo. Y entonces, esa es simplemente la naturaleza de una cosa de red. Tenemos el mismo problema con un límite de IO del sistema de archivos. Alguien guarda un archivo, y luego alguien lee el archivo. No puedes asumir que cuando lees el archivo, es la misma cosa que se guardó, porque algo más podría haber cambiado ese archivo entre esas dos cosas. Sí, adelante. Sin embargo, podrías pasar la función en sí, como los datos de carga como un argumento a un tipo, y luego podrías deducir eso del tipo de si tú- Sí, en realidad estamos trabajando en mejorar esto, y eventualmente, podrás hacer esto. Sí, exactamente. Esa será eventualmente la forma en que hagamos esto. Exactamente, esto es lo que yo estaba- No puedes hacer esto hoy porque el cargador devuelve una respuesta, y no puedes deducir eso ahora mismo, pero sí, eventualmente, eso es lo que será, y será mucho mejor, pero por ahora, no te mientas a ti mismo sin saberlo. Deberías mentirte a ti mismo a sabiendas. ¿Tiene sentido? Si vas a mentirte a ti mismo, al menos deberías saberlo. Entonces, de todos modos, desearía haber actualizado el tutorial de la publicación del blog para no tener que pasar los últimos cinco minutos explicando por qué estaba mal. Así que ahí lo tienes. Y si no tenía sentido o si te perdiste en todo eso, no te preocupes porque de todos modos estaba mal. Así que estamos bien. Bueno, eso es todo para cargar datos. ¿Alguna pregunta sobre la carga de datos en Remix? Vamos a hacer una pausa después de esto, así que si tu cerebro está empezando a sentirse frito, no te preocupes, una pausa va a venir a salvarte. Entonces- Solo me pregunto si use loader data está usando automáticamente la función del cargador entonces? Sí, así es como funciona, Remix en realidad no hará la transición a esta página hasta que los datos del cargador para esta ruta hayan sido cargados. Y entonces cuando decimos use loader data, Remix ya tiene los datos. Y entonces simplemente encuentra los datos para la ruta que está pidiendo y te los pasará. Y entonces no hay nada asíncrono sucediendo en este punto. Toda la asincronía ha ocurrido antes de llegar aquí. Y por eso no necesitas preocuparte por un estado de carga aquí. Ahora, tenemos APIs para estados de carga porque a veces la red es lenta, pero no tienes que preocuparte por ello aquí. ¿Alguna otra pregunta? Hola. ¿El cargador es una palabra clave especial que tenemos que usar para que funcione use loader data? Lo siento, no entiendo tu pregunta. ¿Podrías repetirla? Entonces las variables del cargador unifican. ¿Es esa una palabra clave especial que tenemos que usar para que funcione el gancho use loader data? Pero de todos modos no es importante. Así que exportamos el cargador. Y Remix va a, Remix sabrá, oh, hay un cargador para esto. Y entonces cuando el usuario hace la transición, dirá, oh, hay un cargador para esa ruta. Déjame hacer una solicitud de búsqueda. Y entonces cuando se hace esa solicitud de búsqueda, Remix es el que la maneja. Y dice, oh, quieres llamar a este cargador. Así que déjame llamar a ese cargador, obtener la respuesta, enviar la respuesta a la UI.

Y luego, cuando eso esté hecho, Remix toma esa respuesta, la coloca en sus data que tiene. Y luego, cuando esto se renderiza, dice, oh, quieres los data, aquí están. Entonces, si cambio el nombre a algo más, como loader uno, ¿seguirá funcionando? No, no lo hará. Esta es una convención. Tiene que ser loader. Tiene que ser loader. Sí. Básicamente sucede en el backend de alguna manera. ¿Perdón, qué dijiste? Entonces, es como Remix, solo detecta la palabra clave loader, en este caso. No puedes tener un nombre diferente para eso. Correcto. ¿Y puedes tener dos vistas de los data del cargador en un componente o solo puedes tener una? Sí, podrías usarlo dos veces y serían los mismos data. Y la ventaja de eso sería si tengo un subcomponente y necesito los data del cargador, puedes obtenerlo allí y no tener que pasar props por todas partes. Así que sí, hay situaciones en las que haces eso. ¿Puedo tener dos cargadores diferentes o puedo tener un bucle para que pueda, si tengo una solicitud de recursos de dos cosas diferentes, ¿necesito hacerlo en un solo cargador o puedo tener dos cargadores diferentes? Entonces, hay diferentes casos de uso de los que estamos hablando aquí, pero el más obvio sería, aquí está mi primera cosa y la segunda cosa es esperar, promise.all, y luego obtener la primera cosa y obtener la segunda cosa. Y ahora tienes ambas cosas, las envías de vuelta. Pero si una es muy lenta y no quieres hacer que la página espere, preferirías enviar un spinner de carga, tenemos una API realmente impresionante para eso que llegará pronto llamada API Deferred, te va a volar la mente. Pero incluso hoy, si eso es lo que querías, podrías usar un hook llamado useFetcher y cargarlo solo en el cliente. Y sí, eso es posible hoy, pero tenemos algo aún mejor en camino, eso es un poco más profundo que una masterclass de Fundamentos de Remix. Así que eso es todo lo que voy a decir al respecto. Gracias. Sí. Tengo una pequeña pregunta tal vez, si todavía tienes tiempo. Sí, y luego Ling, veo que tienes la mano levantada también. Sí, que vaya Ling primero, yo no levanté la mano. Está bien. Hola, gracias. Así que probablemente solo sea una pequeña pregunta. Así que probablemente hay otras funciones de API además de loader disponibles, ¿verdad? Sí, sí, ¿te refieres a otras exportaciones en este módulo? Sí, las hay. Si vas a convenciones y luego vas a la API del módulo de ruta, tienes todas esas aquí. ¿Puedes- Lo pegaré en el Zoom. Gracias. Y en el discord. Bien. Vale, adelante. ¿Es Gunther? Sí. Sí, digamos que, por ejemplo, tienes una URL con dos ID en ella y tienes el hijo más bajo. ¿Puedes acceder al ID del padre? Sí. ¿Por ejemplo? Sí, entonces obtienes este objeto params y eso dirá, como slug y luego puedes obtener como el ID del padre. Así que si estamos vendiendo coches o algo y dices params.make y params.model. Así que tienes /make/model, podrías acceder a todos ellos. ¿Y puedes acceder a los data del cargador del padre? No, no puedes. Entonces, la razón de eso es, cuando tienes varias rutas, queremos ejecutar todas esas en paralelo. No queremos ejecutar una después de la otra. De lo contrario, sería muy lento. Y entonces, no, no puedes acceder a los data del cargador del padre en el cargador del hijo. Puedes hacerlo en el componente, solo no en el cargador, porque ejecutamos todos esos en paralelo. Y también. Entonces, tienes que volver a buscarlo, básicamente, si necesitas los data del padre? Sí. Vale, perfecto. Ahora, ten en cuenta que esto se ejecuta en el servidor. Así que si tienes que golpear la database para obtener el modelo y los padres, y luego golpeas la database para obtener el modelo en el cargador, o en el hijo, esos se están ejecutando en el servidor. Así que, probablemente esté bien. Pero si no es así, entonces podrías implementar una mini capa de caché en tu servidor para decir, oh, ya estoy solicitando esto, solo espera mientras lo consigo para el otro. Así que eso no es ridículamente complicado. Pero, también vamos a crear eventualmente esta API especial que probablemente se verá algo así como esto antes del cargador. Y entonces esto será algo que simplemente devuelve algunos data que quieres tener. Y esto se ejecutará antes de que se ejecuten los cargadores. Así que realmente no quieres usar esto porque automáticamente hace que todos tus cargadores tarden tanto como esto tarda antes de que incluso empiecen a ejecutarse. Y entonces, esto es solo para esas cosas que son realmente críticas para todos los hijos. Pero sí, probablemente habrá una API como esa en el futuro. Perfecto, ¿y cómo obtienes los data del padre con el use loader data? ¿O eso no es parte de esto? Sí, entonces, si quisieras acceder a los data del padre, dirías use matches, esto te dará todas las rutas coincidentes y tus data del padre estarán en eso. ¿Hay algo con respecto a la gestión del estado que solo funcione usando el enfoque de Redux o Remix lo cubre todo? No hay literalmente nada que puedas hacer con Redux que no puedas hacer con Remix y Remix lo hace más fácil. Así que la única cosa que, una advertencia a eso, es que la gestión del estado de Remix se trata de estado persistido. Así que si tienes un estado de UI que solo aparece en la UI y pulsas actualizar y se va, cosas como si un modal está abierto o un elemento de menú está seleccionado o algo así. Entonces sí, esas cosas no serán gestionadas por Remix pero la mayoría de esas cosas son cosas a nivel de componente por lo que no usarías Redux para esas o no deberías. Es una forma realmente genial de hacer una aplicación de react muy lenta. Pero sí, entonces esas son todas cosas de estado local. A veces hay cosas que estás como, creo que necesito compartir esto a través de la aplicación y no es persistido así que no lo voy a poner en Remix. Sí, no hay muchas situaciones así pero hay algunas, estoy seguro.

Y aún puedes usar Remix para eso porque la última versión de React router admite esto, oye, ¿dónde está mi... Oh, cierto, me deshice de eso. Vamos a las notas. Entonces, la última versión del router de React tiene esta función en el outlet llamada contexto. Y así puedes poner cualquier valor que quieras allí y luego el hijo aquí puede decir, ¿dónde está mi, sí. Puede usar el contexto del outlet para obtener lo que se pasó en el contexto del padre. Y si quisieras hacer algún estado de la UI que se comparte entre las rutas y cosas así, entonces ni siquiera tienes que crear tu propio proveedor de contexto, puedes usar la API de contexto del outlet. Pero si no quieres hacer eso, como si quisieras crear tu propio proveedor de contexto, eso también está bien. No puedo imaginarlo. Así que en realidad hay una situación en la que Redux aún podría ser útil, en mi opinión, y es si estás construyendo una aplicación que es muy personalizable, como si tus usuarios pudieran escribir sus propios complementos para tu aplicación, y necesitan poder conectarse cuando ocurren diferentes cosas. Estoy pensando en cosas como Hyperterm donde puedes tener complementos y cuando se envía una acción, el complemento quiere poder hacer algo o lo que sea. Eso parece ser un caso de uso razonable para algo como Redux, pero eso es como el 0.00001% de los casos de uso. Así que realmente no veo muchas situaciones donde Redux sea muy útil.

pepf, así que el método JSON en el cargador tiene algunas implicaciones, nada nuevo, son todos estándares web, eso es bueno saberlo. Stringifies, sí, convierte en cadena los objetos y objetos de JavaScript como fecha y regex causando que se pierdan los datos. Sí, eso es exactamente correcto. Y eso es en realidad por qué esto no es genial porque si dijera, hey, esta es mi fecha y es un objeto de fecha, entonces mi cargador está bien con eso. Como puedo decir fecha, nueva fecha. Como eso funciona bien. Pero aquí, si intentara decir post date punto a cadena local, lo que sea, eso va a arruinar mi aplicación porque se serializó a través de la red. Así que por eso no queremos que uses el genérico como funciona hoy, no, como que técnicamente te estás engañando a ti mismo porque es porque esto se serializó, sucedió a través de la red. Tendrías el mismo problema en cualquier caso, independientemente de si estás usando Remix, vas a convertir en cadena las fechas y otros objetos como ese. Y por eso, cuando tengamos el soporte para el tipo de cargador, lo que hará es decir que cualquier cosa que esté en el cargador data o en lo que devuelvas de JSON, cualquier cosa que pongas allí se convertirá en una versión JSON en forma de cadena de ese objeto en cuanto a los tipos se refiere. Esto lanzará un error de tipo en el futuro. Y sí, la forma en que resuelvo esto es si volvemos al repositorio de FakeBooks, porque mostramos fechas en varios lugares. Es que, ¿dónde está? En mi cargador. En realidad lo formateo en el servidor y solo envío el valor formateado. También podrías serializarlo o algo así, sí, serializarlo y deserializarlo en el cliente si quisieras, como quieras lograr eso, pero sí, debes tener en cuenta el hecho de que todo lo que pases a JSON se convertirá en una cadena JSON. Así que tenlo en cuenta.

Oh sí, hablando de pruebas de una aplicación de Remix. No necesitas probar una aplicación de Remix porque cuando escribes una aplicación de Remix, escribes un código perfecto. Nunca tienes errores. Esos simplemente no existen. Solo estoy bromeando. Eso es una broma total. Sí, probablemente no tendremos tiempo para hablar de las pruebas. Pero las pilas ya vienen preconfiguradas con herramientas de prueba y cosas así. Entonces sí, si comienzas con una pila, tendrás todas las cosas de prueba configuradas. De acuerdo, sí, Chris, y luego seguiremos adelante. Solo una pregunta rápida, en general. Solo quiero saber si es posible tener el cargador que tienes en todos tus componentes, si es posible replicarlo de una manera general para que puedas aplicar algo como una verificación de estructura o como una validación de esquema, cualquier dato que llegue para poder demostrar que esto es definitivamente válido y puedo confiar en la estructura o mostrar un mensaje de error general. ¿Sería eso posible en absoluto? Sí, lo que estás pidiendo es una forma de decir como validar algo y hacer algo como una función de orden superior. Esto no está permitido porque estamos tomando este archivo, estamos creando dos compilaciones diferentes a partir de él y una para el servidor y otra para el cliente. Y para poder deshacernos del código solo del servidor, no puedes tener efectos secundarios en tu módulo. De lo contrario, no podemos estar seguros de que estamos haciendo lo correcto. Y por eso no se permiten las funciones de orden superior. Podrías crear totalmente tu propio JSON y hacer lo mismo allí. Probablemente eso es lo que haría. De acuerdo, solo me preguntaba porque mencionaste esto antes del cargador, esperaba que hubiera algo como después del cargador, tal vez esto sería bueno. Tenemos en el archivo de entrada del servidor, esto maneja las solicitudes para la página inicial. Y eres responsable de crear el marcado y todas esas cosas, lo cual es realmente agradable. También tenemos una función handle data request. Creo que así se llama. Pero esta es la última parte de tu código que se llama antes de que llegue la respuesta de los datos. Y sí, así puedes hacer ese tipo de cosas allí. Genial, vamos a seguir adelante con el espectáculo. Entonces, si miramos nuestro esquema, tenemos enrutamiento anidado, carga de data. Solo voy a mostrarte rápidamente los parámetros dinámicos. Es bastante sencillo y nos ahorrará un poco de tiempo. Así que si miramos las rutas de las publicaciones, oh, eso es el ejercicio. Veamos la versión final de eso. Rutas de publicaciones, entonces verás, tenemos esta cosa de dólar slug punto TSX. Así es como se hace un parámetro en la URL. Entonces vas a publicación slash cualquier cosa y el dólar slug será simplemente cualquier valor que esté en la URL. Y luego tienes acceso a eso a través de params. Y lo interesante de esto es que, espera, ¿me salté algunas cosas? Sí, hmm, ¿deberíamos? Sí, no tenemos tiempo. Y ya hemos pasado la mitad. Así que eso es todo lo que hay sobre los parámetros dinámicos. Le das un dólar, como quieras llamar al parámetro y luego en tu código, usas los parámetros en el cargador.

Para obtener acceso a él en su componente, utiliza use params de RemixRun React. Que es lo mismo que de React Writer. Entonces, si estás familiarizado con eso, eso es eso.

Eso es todo para los parámetros. Ahora, un par de notas. Para empezar, TypeScript no tiene forma de saber si este slug va a estar definido. Y por eso estamos usando esta cosa invariante. Esta cosa invariante, si no estás familiarizado con ella, es básicamente lo mismo que esto. Y lo que esto hace por nosotros es, en primer lugar, nos da un mensaje de error más agradable que no puede llamar a mayúsculas de indefinido o lo que sea. Así que podemos tener un mensaje de error más específico porque no hay forma de garantizar al 100% que esto va a ser lo que pensamos que es porque podríamos cambiar esto, como escribir mal esto a slugs, y ahora el nombre del parámetro ha cambiado. Entonces, debido a eso, es una buena idea hacer esta verificación. Y cuando haces esta verificación, TypeScript también considerará esto como una cadena, mientras que antes, podría ser una cadena o indefinido. Así que eso es lo que se trata la cosa invariante. Y encontrarás que uso invariante bastante solo para decir, oye, sé que, o creo que es de este tipo. Verifiquemos eso, y si no es así, entonces obtendremos un buen mensaje de error para eso. Así que eso es todo lo que se trataba.

Lo otro que cambió aquí es que saltamos sobre la parte donde estamos conectando nuestras publicaciones a una base de datos real. Y aquí, estamos usando Prisma para acceder a los datos en la base de datos SQLite. Y moví todo a este otro archivo porque cuando estamos hablando con una base de datos, me gusta poner esas cosas en un archivo separado la mayoría de las veces. Y solo así, aquí está mi modelo para comunicarme con la base de datos. Y entonces, movimos esto al directorio de modelos. Y sí, para obtener publicaciones, decimos Prisma post find many, y para obtener una específica, decimos find unique donde el slug es lo que estás buscando. Y en esa página de slug, podemos decir, obtener publicaciones, params.slug. Y si eso no existe, entonces lanzamos un error y decimos, oye, eso no existe. Tenemos un mejor manejo de errores en un 404 management que hablaremos más tarde si tenemos tiempo. Pero por ahora, simplemente vamos a lanzar un error si la publicación no existe. Y, pero si existe, entonces vamos a usar Marked para compilar el Markdown en HTML. Y enviamos eso a través del cable, y luego renderizamos ese HTML para la publicación. Y entonces, para cuando terminamos ese ejercicio, si vamos a node-dev, sí, vinyl03, ¿qué pasó? Oh. Ahí vamos. Ah, dev, vinyl03, ahí vamos. Entonces cuando eso está todo hecho, oh, está en la página equivocada de nuevo, entonces terminamos con una cosa que realmente funciona. Mi primera publicación, esta es mi primera publicación, ¿no es genial? Y aquí está mi mixtape. Y todo eso vino de la base de datos. Eso debería estar sembrado para ti automáticamente a través de nuestro script de semillas, que coloca los datos de la publicación en la base de datos cuando configuramos el proyecto en primer lugar. De todos modos, así es como funciona esa parte. ¿Alguna pregunta sobre los parámetros o cómo funciona la base de datos, podemos hablar brevemente sobre eso. Bueno, genial. Así que los parámetros, hooray. Cada aplicación los necesita. Bastante sencillo. Así que podemos saltarnos eso. El próximo ejercicio es el enrutamiento anidado. Creo que, lo que quiero asegurarme de cubrir es el enrutamiento anidado y las mutaciones. Si llegamos al enriquecimiento progresivo, eso sería bueno, pero estos dos son los más importantes. Así que definitivamente vamos a cubrir estos dos, al menos. Entonces, sí, número cuatro. Asegúrate de estar en el directorio correcto. Así que estás en el enrutamiento anidado. Consulta el README allí para el inicio y el final, y ejecuta node dev exercise 04. Y deberías estar en el puerto 4004. Y ahí es donde vamos a trabajar, ¿de acuerdo? ¿Alguna pregunta antes de dejarte en este? Bueno, genial. Responderé, Katerina acaba de hacer esta pregunta sobre la automatización de la verificación de parámetros en los cargadores. Sí, no tenemos planes para automatizar esa verificación por ti. Sí, la verificación no es realmente, en mi experiencia en la construcción de aplicaciones Remix, no ha sido un problema para mí. Es literalmente solo esto, y creo que vale la pena. Automatizar esa verificación, sería difícil porque implicaría supongo, el problema es que tendríamos que enseñar a TypeScript nuestra convención, y eso no va a suceder. Como, así que podrías automatizar la verificación para el tiempo de ejecución, pero nunca podrías automatizarlo para TypeScript, y TypeScript vale una línea en tu cargador. Así que sí, probablemente nunca lo haremos. ¿No sería una idea si, sí, sabes que el slug tiene que ser el dólar, lo que sea que pongas detrás de él. Si eso no está en los parámetros, entonces es algo inválido, ¿no? Sí, sí, totalmente. Así que podríamos hacer una cosa en tiempo de ejecución. Pero de nuevo, incluso si hacemos eso, vas a obtener un error de tipo aquí mismo porque TypeScript no sabe que hiciste eso. Justo. Sí, entonces, probablemente, probablemente nunca habrá algo así. Varias personas terminaron, así que hagamos esto. Estamos agregando una sección de administración a nuestra aplicación, y vamos a tener un enlace a eso. Creo que, no recuerdo si esta es la sección donde realmente la bloqueamos para los usuarios que han iniciado sesión. Creo que eso está en la tarea. Así que puedes hacer eso más tarde.

Pero sí, solo necesitamos crear la sección de administración. Así que esta primera parte es un poco rutinaria para nosotros. Ya hemos hecho esto. Entonces, si vamos al índice de publicaciones, simplemente pondremos esto justo debajo de las publicaciones. Y vamos a localhost 4004. Ahí están nuestras publicaciones de administración. Y esto dice, publicaciones no encontradas, porque eso no es una publicación. Así que vamos a hacer un admin.tsx. Y ahora tenemos una ruta para manejar eso. Entonces, en lugar de caer en el slug, en realidad irá a la página de administración. Así que vamos por aquí, y cogemos todo el JSX, y otras cosas que ya sabemos cómo hacer por allí. Y si venimos por aquí, y refrescamos, entonces boom, tenemos una lista de nuestras publicaciones. Y luego tenemos un punto, punto, punto aquí en el lado derecho. Así que esta va a ser la ruta principal para todas las rutas de administración y subrutas más allá de eso. Así que tenemos la publicación listada aquí, y notarás que el enlace apunta al post.slug. Así que no hay combinación de rutas aquí. No tenemos que hacer slash lo que sea y combinar esto. Solo queremos que este enlace vaya de slash post slash admin a slash, post, slash admin slash slug. Y aquí es donde entran las rutas relativas. Y eso es una característica de React writer Rev6. Por supuesto que está en Remix también, y eso es genial. Pero para poder manejar eso, esto va a ser una subruta de la ruta de administración en sí, y aquí es donde queremos que vayan las rutas hijas. Así que renderizamos ese outlet ahí. Bueno, así que lo traemos de Remix run React. Y así cuando hago clic en estas diferentes rutas, voy a obtener un 404 no encontrado porque no tengo una ruta para manejar esas. Vaya, acabo de perder eso. A veces cuando deslizo de izquierda a derecha así, mi pantalla se bloquea y no entiendo por qué. Bueno, en fin, eso nos lleva hasta allí. Vamos a hacer nuestra ruta índice para cuando en realidad no estamos en una ruta hija. Así que si estamos solo en admin, ¿qué queremos que aparezca aquí? Y para nosotros, simplemente vamos a decir, crear una nueva publicación. Así que voy a hacer un directorio llamado admin y luego un archivo allí llamado index.tsx. Así que ahora si vengo por aquí, tenemos esto apareciendo allí. Así que esto es como enrutamiento anidado, ¿verdad? Tenemos nuestra ruta de administración. Eso es nuestro diseño para todo. Y luego nuestra ruta anidada dentro de eso, que es el índice de lo que aparece si no tenemos hijos, entonces esto es lo que va a aparecer. Esta crea una nueva publicación. Si hago clic en eso, ahora voy a obtener un 404 porque no tengo un post o un archivo en new.tsx. Así que vamos a crear ese, new.tsx. Y luego viniendo por aquí. Oh, cierto. Ya hice la cosa del outlet. Así que ahora estábamos diciendo que aquí es donde van mis hijos. Ahora para nuestra nueva publicación, esto es todo lo que nos importa poner allí. Así que nuevo post. Hurra. Ahí está. Genial. Así que si voy a admin, voy a ver esto como mi ruta índice. Así que no tengo, no hay segmentos hijos. Así que muestra esto. Y luego cuando hay un segmento hijo, va a añadir slash new, entonces la nueva subruta es lo que se va a mostrar. Vale. Genial. Creo que eso es hasta donde llegamos. ¿Eso es hasta donde llegamos? Sí, no creo que hayamos entrado en eso. ¿O entramos en las acciones? No puedo recordar. ¿Dónde estábamos? Dijimos que paráramos en las acciones. Sí, vale, genial. Sí. ¿Qué preguntas tienen sobre el enrutamiento anidado? ¿Puedo tener un ejemplo de eso? Podría tener uno. Si tienes múltiples rutas anidadas, ¿no se bloquean o sí? Así que sí, y en realidad sí, tenemos múltiples rutas anidadas. Así que tenemos nuestra ruta raíz que en realidad... No lo vimos, pero si miras el root TSX, eso es responsable de renderizar todo desde el HTML abierto hasta el HTML de cierre. Así que como la página entera. Esto es realmente genial, porque en mi sitio controlo un nombre de clase basado en el estado. que es bastante divertido. Normalmente tienes que usar un use effect para controlar cualquier cosa en el HTML, porque nos gusta hidratar solo el cuerpo o lo que sea. Pero sí, así que eres responsable de todas las cosas y esto renderiza un outlet. Y luego cuando estamos en la página de publicaciones, tenemos lo que no tenemos aquí porque simplemente estamos aprovechando el predeterminado, pero eso es solo otro outlet. Y luego en el admin, tenemos nuestro tercer outlet.

Así que tenemos cuatro rutas que se están renderizando en la página. Una para la raíz, una para las publicaciones, una para el administrador y luego una para el nuevo. Y sí, en el renderizado del servidor, cada uno de sus cargadores va a bloquear la carga inicial de la página. Y la mayoría de las veces eso es lo que quieres porque quieres cargar toda la página sin ningún spinner de carga en su lugar. Pero a veces tienes algunos data que son realmente lentos o no son importantes o lo que sea. Y eso es lo que la API diferida nos va a dar en las próximas semanas o puedes simplemente usar la característica actual de UseFetcher y hacer que eso se cargue en el cliente. Creo que puede que haya pasado por alto tu pregunta. ¿Eso responde a la pregunta que tenías? Sí, en su mayoría lo es. Así que si está bloqueando o con lo diferido, si usas los data de Max para buscar los data de tus padres en la UI, tendrías que considerar si se ha buscado o no ¿o estoy equivocado? No, así que para cuando se renderiza tu componente, todos los data están hechos. Vale. La excepción a eso es la API diferida. Así que si estás usando la API diferida, hay un componente especial que usas para lo que debería ser renderizado mientras estamos esperando que esos data estén disponibles. Pero sí, sí, supongo que pasemos al siguiente ejercicio. Así que estamos en 05 mutaciones y vamos a empezar desde acciones y bajar hasta mejora progresiva en nuestro blog de desarrolladores así que simplemente continuaremos desde donde estamos. Te doy toda la ruta del formulario como de nuevo, no estamos aquí para aprender React y JSX, estamos aquí para aprender Remix. Y sí, la única parte de Remix de esto es el componente de formulario y hablaremos de eso cuando volvamos a estar juntos. Y luego tenemos algo de code para ti para las cosas de Prisma. Y sí, luego hacemos algunas cosas elegantes con los scripts de tipo y el manejo de errores y cosas así también. Así que creo que disfrutarás de este y esto realmente destaca muchas de las cosas geniales sobre Remix también. Así que sí, simplemente pásalo bien en eso y dejaré otro mensaje en el discord para que me avises cuando hayas terminado con esto. Quiero asegurarme de que estoy en el lugar correcto. ¿Continuamos con esto, o pasamos a uno de los otros ejercicios? Sí, ve al ejercicio cinco. Lo bueno de los ejercicios es que si te equivocas en algo, pero no lo sabes, simplemente saltas al siguiente y no importa. Así que. Gracias. Sí. Sí, debería estar ejecutando el ejercicio cinco. Debería estar en el puerto 4005. Así que hagamos estas cosas de mutaciones. Primero cogemos estas cosas del formulario y con lo que nos quedamos es con el formulario aquí mismo. Esto es genial porque todo es simplemente como el enrutamiento anidado es increíble. Realmente hace un gran impacto en lo fácil que es construir estas UIs donde no tienes como un componente de diseño o algo así. Así que este formulario simplemente aparece en cada uno de estos. Tenemos los títulos como en Markdown. Veamos qué pasa cuando enviamos esto sin hacer nada más. Si digo nuevo título, esto es genial. Tal vez podríamos generar eso en algún momento y cosas nuevas cuando hago clic en crear publicación, vamos a obtener un 405 método no permitido. Y eso es porque lo que hicimos o lo que hace Remix es que hace esta solicitud post y que postea a la URL especial en la URL actual con este parámetro de consulta que define cuál fue la ruta que envió la solicitud. Así es como Remix puede enrutar eso a la acción que definimos aquí pero no definimos una acción. Así que no hay nada aquí para manejar esa solicitud y por eso obtuvimos un 405 no permitido porque manejamos los gets si queremos aterrizar en esta página pero no manejamos un post. Así que eso es lo que vamos a hacer es que vamos a manejar este post. Así que vamos a, en realidad aquí, asegurémonos de que estoy siguiendo el camino correcto. Así que sí, primero queremos hacer una forma de crear una publicación en la database. Así que vamos a subir a nuestro servidor de publicaciones en los modelos. Solo añade este post de creación, podemos añadir tipografías más tarde. Y luego vamos a añadir esta acción y hablemos de esto aquí. Así que cogemos el post de creación de nuestro servidor de publicaciones y tenemos nuestra acción que acepta una solicitud. Así que vamos a tener un squiggly rojo aquí hasta que añadamos algunas tipografías. Así que voy a añadir esas tipografías ahora mismo porque el squiggly rojo me molesta. Esta es la función de acción y eso viene de remix run node. Y así nuestra solicitud es sólo el objeto de solicitud. Y como recordatorio, esta solicitud es una solicitud de búsqueda web. Así que si nos sumergimos en la definición aquí y vamos a las solicitudes, esto está literalmente viniendo de la interfaz de la API de búsqueda para las solicitudes. Como este es el objeto de solicitud global. Y por lo tanto eso probablemente se llena para nosotros en el nodo a menos que estés usando como la última versión de nodo. De hecho en eso, creo que ni siquiera probablemente o creo que probablemente lo llenamos allí también tal vez porque por razones. Pero en cualquier caso puedes tratar esto como una cosa regular de búsqueda web. Y así que mucha gente que está usando remix se encuentra pasando más tiempo aquí que aquí. Más tiempo en MDN que en los docs de remix. Esto es realmente genial porque significa que a medida que te conviertes o usas remix te conviertes en un mejor desarrollador web y no sólo en un mejor desarrollador de remix. Y esto es lo que me gustó de React. Sentí que me estaba convirtiendo en un mejor desarrollador de JavaScript no sólo en un mejor desarrollador de React en comparación con lo que estaba haciendo con AngularJS y cosas así. Así que sí, así que esto es una cosa de búsqueda web y por lo tanto vamos a usar la API de data de formulario. Así que de nuevo, si vas a mdn.io y escribes y pasas cualquier cosa entonces esto realmente hará una búsqueda rápida y te redirigirá a la página en developer.mozilla.org que coincide con esa cosa, el FACET. Así que voy a mdn.io slash cosas todo el tiempo. Así es como hago las búsquedas para las cosas de la web. Pero de todos modos, request.formdata es una API que te da acceso a los data del formulario para la solicitud, lo cual es perfecto. Así que ahora tenemos el objeto de data del formulario. Podemos obtener el título, SLAG, y el Markdown y crear la publicación con eso. Y luego vamos a redirigir a post slash admin porque eso era lo que tenía más sentido.

También podríamos redirigir potencialmente a post slash, ya sabes, post, o sí, SLAG. Así los llevamos a la página final real, como la publicación que acaban de crear. Pero tal vez quieran escribir otra publicación, no lo sé. Puedes hacer lo que quieras allí para redirigir. Pero eso es lo básico para manejar eso. Y así si venimos aquí y antes de hacer esto, echemos un vistazo de nuevo al índice o lo siento, la ruta de administrador, nuestra ruta principal. Esto está renderizando todas nuestras publicaciones. Ahora, quiero que prestes mucha atención a lo que code no está aquí. No hay code aquí para actualizar la publicación cuando creamos una nueva publicación. No hay nada, está bien. Simplemente estamos como cualquier publicación que tenga, renderízalas. Y luego aquí tenemos algo de code para crear una nueva publicación y luego redirigir a post slash admin. Así que si creo una nueva publicación, vamos a decir, Sandrina es genial, y luego ah, Sandrina, ah, sabe cosas impresionantes, ah, sobre accessibility. Bien, ahora decimos crear publicación. Quiero que mires la lista aquí y veas lo que está haciendo la pestaña de red. Crear publicación, boom, ahí está. Así que hemos redirigido a post admin. Hicimos el post aquí mismo. Ah, y Sandrina es genial, está a la izquierda aquí ahora. Así que no tengo code. Recuerda, no state management. No estás pensando en eso. Todo se actualiza automáticamente. Es increíble. Así que creamos, hacemos el post y luego Remix dice, oh, esto va a redirigir. Así que miramos la respuesta. Bueno, sí, esto es una redirección XRemix. Así que porque Remix está simplemente emulando el navegador, en realidad no vas a obtener una redirección aquí porque no quieres que el navegador vaya a, re-buscar esta página. Y así Remix es como, oh, quieres que ellos vayan a esta página de administración de publicaciones? Bueno, resulta que sé que la página de administración tiene un par de rutas que tienen cargadores en ella. Así que déjame ir y solicitar esos data. Y si miras esto, eso está sucediendo todo al mismo tiempo. Así que voy a solicitar esos data. Así que entonces puedo, en ese punto, enviar al usuario a esa página. Y así esto es realmente impresionante porque significa que nunca tenemos que mantener nuestros data actualizados. Y es por eso que no necesitas preocuparte por la state management. Así que cuando se hace una mutación, Remix es como, bueno, todas las apuestas están fuera en los data que tenemos aquí. Vamos a ir y refrescar todos los data en la página. Ahora, sé que algunos de ustedes están pensando, oh no, no puedo refrescar todos los data en la página cada vez que el usuario le gusta un tweet o algo así. Hay absolutamente APIs para ustedes para poder decir, hey, opta por no hacer esta actualización automática de data. Pero ten en cuenta que la forma en que el navegador siempre se ha comportado es cuando haces una mutación, estás haciendo un refresco completo de la página. Haces la mutación, y luego creas un nuevo HTML basado en lo que está en la database actualmente. Así que siempre estás obteniendo la información más actualizada. Así que parece un valor predeterminado bastante sólido. Y esto es lo que nos permite mantener el modelo mental de finales de los 90, principios de los 2000 de construir web apps es porque Remix revalida automáticamente tus data cuando se hace una mutación. Así que eso son las mutaciones con Remix.

Entonces, lo que me preguntaba cuando trabajaba con foros, cómo hacer algo más, y tengo claro cómo hacer controles simples como una entrada de texto, una casilla de verificación. Pero si quieres algo más sofisticado como un grupo de radio, que no son solo botones de radio simples, pero si tienes algo donde necesitas estado para hacer el estilo. Estoy pensando en algo como voy a poner un enlace en el chat, algo como el grupo de radio headless UI. ¿Cómo lo harías? Porque como veo ahora en los foros, siempre tenemos estos controles simples sin ningún estado local pero requiere estado, porque necesitas estilizar todos los elementos alrededor, ¿verdad?

Sí. Entonces, primero diré que creo que podremos hacer esto sin estado en el futuro porque haz está llegando a CSS. Y sí, eso será genial. Pero sí, ahora mismo eso no es posible. Entonces sí, no hay nada aquí que vea que no funcione bien con remix. Puedes usar totalmente useState y con remix, eso funciona bien. Entonces, sí, no estoy diciendo que nunca usarás useState en remix pero no lo necesitas para que la aplicación funcione. Lo difícil del estado en las aplicaciones de React no es este tipo de estado. Este tipo de estado es fácil. Cualquiera puede hacer esto. La parte difícil es el estado de la aplicación donde es como, bueno, acabo de agregar esta publicación y ahora tengo que actualizar esa lista y todo el estado que se gestiona allí. Así que ahora tenemos que compartir algo de contexto. Y ahora tenemos reducers y dispatches y cosas así. Y oh, bueno, ¿qué pasa si lo actualizo antes de que realmente termine y luego se cancela la solicitud o el usuario... Hay una condición de carrera. Como hay tantas cosas que hacen esto realmente difícil. Remix elimina esas cosas difíciles. Cosas fáciles como esta, sí. Eso todavía puedes usarlo totalmente y funciona igual de bien. Pero sí, en el futuro, tendremos has en CSS e incluso algo como esto, no necesitarías estado para lo cual sería genial. Así que gran pregunta, Felix.

Esa es una buena idea. Todavía no estoy seguro de cómo actualizarías entonces los forms, ¿el valor? Porque si tienes un control simple como botones de radio o casillas de verificación, entonces el navegador mantiene el estado de si está marcado o no. Y si controlas el estado, ¿cómo lo pasas al formulario, por así decirlo? Sí, gran pregunta. Me sorprendería mucho si no tienen un botón de radio real en algún lugar de aquí. Porque si no lo tienen, entonces es muy difícil hacer esto accesible. Así que probablemente hay un botón de radio siendo renderizado en algún lugar. Si no hay, oh sí, tienen un rol de radio. Sí, eso es desafortunado. No sé por qué no renderizan un botón de radio real. Pero aquí está lo que haces. Dirías, aquí está mi use state, o diremos opción. Oh, genial, lo estropeé. Bueno, intentémoslo de nuevo, use state, opción. Entonces, aquí está mi sándwich o mi sándwich, seguro. Y luego dentro de aquí, simplemente dirás input, tipo, oculto, nombre, opción, y luego valor como opción. Y así ahora será serializado junto con todo lo demás. Vale, esa es una gran idea, genial. Sí, algunas de las personas que han estado durante un par de años son como, oh sí, recuerdo cuando solíamos hacer eso. Eso es cierto. Sí, volviendo a eso, genial. Gran pregunta.

Otras preguntas, veo a MightyHake, ¿así es como se dice tu nombre? Sí, muy bien. Sí, no estoy seguro si se respondió antes pero algo así como rutas y plantillas son más o menos lo mismo aquí, ¿no? ¿Y qué pasa si quieres usar una plantilla bajo una ruta diferente? Sí, lo que es genial de esto es que es más poderoso que las plantillas porque es solo JavaScript, es como un lenguaje completo, y así si estás como, ¿sabes qué? Me gusta mucho esta cosa de la etiqueta, entonces simplemente conviertes eso en un componente de función. Y así estás como, oh, quiero hacer esto una función llamada, sí, mi componente de etiqueta y ahora puedes usarlo en cualquier lugar. Muy bien, genial. La magia de React es bastante, bastante dulce. Genial, ¿Chris? Sí. Oye, una pregunta rápida sobre cómo irías acerca de un desplegable anidado. Así que imaginemos un ejemplo. Tienes una lista de países y luego una vez que seleccionas un país, te gustaría tener otro desplegable, cargar data para todas las ciudades. Quiero decir, es un ejemplo inútil, pero ¿cómo irías cargando data adicional al formulario basado en esta selección? Sí, esa es una súper pregunta. Estás entrando en cosas más avanzadas. Pero te mostraré lo que hacemos. Este es el material para la masterclass avanzada, que estoy dando mañana y al día siguiente. Entonces, y probablemente todavía hay entradas tal vez. Así que si quieres inscribirte en eso, podría ser divertido. Pero sí, entonces si vamos a... Oh, ¿dónde estaba? Sí, esta es la ruta. Así que esto, estoy usando... Tengo aquí, te mostraré cómo se ve. Libros falsos. Vamos a ventas. Y si quiero crear una nueva factura, ahora tengo este cuadro combinado. Y está impulsado por data basado en los clientes que tengo. Y así puedes hacer lo mismo, como varios de esos son selects basados en cuál es la opción anterior. Pero todo eso, eso va a tomar un estado de UI que estás manejando, ¿verdad? Entonces cuando seleccionan esto, ahora vamos a actualizar estos. Pero la forma en que esto funciona es que tenemos este componente de cuadro combinado que está usando este hook useFetcher. Esto es de Remix. Y useFetcher será enviado. Así que hará un post a esta Acción, que en realidad es donde está este archivo. Así que donde está este componente. Así que simplemente publicará a esta ruta. Y publicará la consulta. Y entonces la Acción que está aquí se llamará y podemos hablar con la database, hacer lo que queramos, enviar de vuelta la respuesta. Y luego cuando ese Fetcher tiene data, eso es lo que se va a usar para alimentar qué opciones están disponibles. Así que simplemente haces exactamente lo mismo. Esto en realidad no es una convención muy normal o no es una convención documentada porque cuando estaba preparando el material de la masterclass, simplemente tuve esta idea de que, ¿qué pasaría si tomamos la ruta del recurso y ponemos el componente que lo usa en el mismo archivo. Y así, sí, el hecho de que estemos exportando esto, eso no es una convención. Como puedes exportar lo que quieras de un módulo. Y así que simplemente importamos esto a, ¿dónde está? Creo que es, sí, clientes, o no, es facturas nuevas. Sí, si vamos al cuadro combinado de clientes y luego simplemente renderizamos esto y luego podemos enviar un error para, entonces cuando esto se envía, si ese error, o si hay un error al enviar eso enviamos el error al cuadro combinado de clientes para que pueda mostrarlo bien o lo que sea, pero sí, está totalmente aislado del resto de esa página por lo que es todo como, aquí está todo para este componente, incluyendo el code de back-end para este componente, todo en un lugar, es realmente agradable. Así que sí, la respuesta corta es usar Fetcher. Vale, genial, gracias. Genial, ¿alguna otra pregunta? Sí, tenemos una elaboración de la pregunta de antes. Así que llegaré a esa primero. Me preguntaba si podrías hacer un manejo de errores con la función createPost. Todavía estoy confundido, ¿estás diciendo si hubo un error al crear la publicación? Sí, exactamente. Lamento no haber formulado bien la pregunta. Sí, está bien.

Me preguntaba si tienes que manejar, por ejemplo, si Prisma tiene un error, ¿dónde manejas eso y cómo lo transfieres de vuelta al cliente para poder manejarlo y mostrárselo al usuario?

Sí, totalmente. Tienes un par de opciones y en este ejercicio, entramos en la respuesta de datos de acción aquí para los errores de lo que el usuario ingresó. Pero estás hablando de, como, ¿qué pasa si yo soy el culpable? Como, cometí un error. No hablamos de manejo de errores en esta guía, pero el tutorial de JokesApp aborda tanto los errores esperados, como 401, 404, y cosas así, como los errores inesperados. Entonces, algo explotó, metí la pata. Y la solución es, veamos, usar esta cosa llamada límite de error. Entonces exportas este componente de función que es un límite de error. Dice, metí la pata, lo siento, lo que sea. Y esto también se va a anidar en lugar de cualquier cosa que esté envolviendo. Así que, en realidad, en el sitio web de Remix en la parte inferior es donde hablamos de errores. Así que agregas el límite de error y en lugar del componente o esa ruta, se va a renderizar tu límite de error. Así es como funciona. También se propaga hasta el límite de error común más bajo. Así es como manejarías eso. Si quisieras intentar atrapar ese error para que no explote todo y eliminar el formulario y cosas así, porque eso es bastante razonable, entonces simplemente seguirías el mismo patrón aquí. Tal vez harías un try catch alrededor de eso y luego enviarías un mensaje de error que diga, lo siento, metí la pata en algo, lo que sea. Así que sí, si fueras como, sí, mi base de datos es bastante poco confiable o algo así, o en este caso, en realidad no manejamos el caso en el que el slug es único. Así que si intento ahora crear una nueva publicación que tenga el mismo slug que otra, eso también va a explotar algo, y esto es lo que obtengo sin tener un límite de error en su lugar. Sí, eso sería algo para verificar probablemente. Perfecto, sí, eso acaba de trazar una línea perfecta hacia tu curso épico de React, ahora tiene sentido, con el límite de error, sí. Genial, gracias.

Pero me preguntaba si quisieras hacer algo sin un formulario, pero tienes un botón que es una acción, ¿puedes hacerlo sin un formulario? Porque supongo que Remix sigue este modelo web antiguo, como dices, donde el estado se administra a través del formulario en el servidor y cosas así. Solo estaba, sí, preguntándome. Si, para cosas que no necesitan un formulario, pero aún quieres ese mismo tipo de comportamiento. Sí, esa es una gran pregunta. Iba a mostrarte esto, pero creo que lo envié de vuelta a eso. Así que vamos a ejecutarlo localmente para que pueda mostrarte a qué me refiero, o mostrarte un ejemplo de esto. Así que voy a iniciar el servidor de desarrollo y se inicia tan rápido. ¿Alguno de ustedes ha notado lo rápido que se inicia el servidor de desarrollo? ¿No es genial tener un servidor de desarrollo que se inicie realmente rápido? Creo que es genial. De acuerdo, así que si vamos a depósitos, vamos a ver un pequeño ícono de papelera justo ahí. Así que es como el botón. Y luego voy a hacer clic en eso y lo elimina. Eso es una mutación, ¿verdad? ¿Entonces cómo funciona eso? Bueno, resulta que esto es solo un formulario. Así que todavía tenemos un formulario y simplemente envolvemos el botón, o el ícono de papelera en un botón, y ese es el botón de envío. Así que te sorprendería cuántas cosas pueden ser solo un formulario. Y así es como solíamos hacerlo en los primeros años 2000. Así que ten en cuenta, en realidad, que el método sigue siendo POST, aunque en realidad estamos eliminando, porque el navegador solo admite GET y POST. Puedes hacer DELETE aquí, está permitido, pero eso va en contra del mejoramiento progresivo porque el navegador no lo admite. Así que simplemente hacemos POST y luego lo manejamos nosotros mismos. Pero en cualquier caso, eso es cómo lo haces si tienes algo visual. Pero tu pregunta me lleva a otra pregunta común, que es ¿qué pasa si quiero hacer una mutación que no involucre interacción del usuario en absoluto? Así que en mi sitio web personal, en mi blog, cuando oh, parece que Red está liderando. Huh, eso es nuevo, felicitaciones Red. Cuando vas a una de mis publicaciones de blog, si lees todo, si lo lees completo, si lo recorres completo, entonces lo cuento y estás en la página el tiempo suficiente, entonces lo cuento como leído y eso es lo que se tiene en cuenta para las clasificaciones de los diferentes equipos según a qué equipo pertenezcas. Y también hago un seguimiento de cuántas lecturas hay en total, ya sea que estés conectado o no. Y no quiero que tengas que hacer clic en una pequeña casilla para decir que lo leíste. Así que necesitamos hacer una mutación que ocurra sin que hagas nada en realidad. Y así es como lo hago con useFetcher. Y así useFetcher tiene esta capacidad de crear formularios para ese fetcher en particular, que estamos haciendo para este botón de eliminación, pero también la capacidad de decir .submit. Y eso es lo que vimos antes con la cosa del cliente. ¿Dónde está el cliente y los recursos aquí? Así que aquí decimos, oye, fetcher, quiero que envíes para que puedas hacer esa especie de envío sin ninguna interacción del usuario. Así que sí, tu caso de uso está cubierto.

Pregunta rápida, así que en nuestro ejemplo, hacemos una redirección después de terminar de crear la nueva publicación. ¿Es esa la razón por la que se actualiza la lista de publicaciones? Si no, ¿puedes explicar rápidamente qué está sucediendo en el fondo? Sí, la razón por la que redirigimos es simplemente porque cuando un usuario termina con su publicación, simplemente suponemos que no quieren hacer una nueva, pero tal vez sí. No es necesario hacer una redirección para que la interfaz de usuario se actualice. La razón por la que la interfaz de usuario se actualiza es cuando hay una mutación exitosa, Remix vuelve a cargar automáticamente todos los datos en la página, eso es todo. Y así es por eso que nunca tienes que preocuparte por mantener tus datos actualizados. ¿Qué devolverías en lugar de eso?

De acuerdo, esta es en realidad una gran pregunta porque si no haces una redirección, déjame apartar esto. Si no haces una redirección, cuando hay una mutación exitosa, entonces terminas en ese lugar divertido donde el navegador, como el usuario está presionando el botón de retroceso y el navegador muestra esta cosa que dice, ¿quieres volver a enviar esta presentación de publicación? Y eso es súper, súper molesto que lo haga. Esto solo sucede si JavaScript está desactivado. Si hiciste una solicitud fetch, eso no va a suceder. Pero con, así que retrocediendo un par de años, es por eso que tenemos esa cosa súper molesta y la razón de eso es porque no hicieron una redirección. Y eso significa que la solicitud de publicación es parte de la pila de historial. Así que tienes get, get, get, post, get, get, el usuario presiona el botón de retroceso. Hacen un get. El usuario presiona el botón de retroceso nuevamente. Hacen un post. Y así el navegador, durante mucho tiempo, eso es lo que hacían. Y así reservabas dos vuelos o algo así. Y así que luego los proveedores de navegadores dijeron, oh, eso probablemente no es bueno.

Vamos a advertirles. ¿Quieres hacer esta publicación de nuevo? Y ahora la gente solo dice confirmar porque solo quieren que la cosa desaparezca. Y así que de todos modos, vamos a hacer un get, get. Y luego cuando hacen el post, en realidad rediriges. Así que el post no termina en el historial y es solo un get en su lugar. Y así cuando vuelven, luego obtienen el post. O luego obtienen el get en lugar del post. De todos modos, lo haremos... Así que rediriges a la misma página. Sí, exactamente. Pero el problema con eso es que ahora tienes, si estás haciendo un montón de solicitudes, un montón de mutaciones, vas a tener un get para cada una de esas mutaciones. Así que tienes una lista larga de historial que es exactamente la misma página una y otra vez. Así que eso no es genial. Si ese es el tipo de cosa que estás haciendo, si dices, no quiero ir a ningún lado. Solo quiero quedarme aquí, entonces ahí es donde usas usefetcher porque usefetcher no hace una transición. Y nuevamente, eso va más allá de lo que estamos haciendo en esta masterclass. Pero el punto es que sí, hemos manejado este caso de uso y es una cosa de usefetcher. Eso es básicamente lo que es. ¿Eso reemplaza a action? No, todavía usarías una acción. Lo genial de usefetcher es que todo lo demás es igual. Así que si quisiéramos cambiar esto, tendríamos mi fetcher usefetcher y luego diríamos fetcher.form y todo lo demás funciona. Y aquí, puedes hacer una redirección si quieres. Pero normalmente, si estás usando un fetcher, entonces dirías Json para que los datos del fetcher sean lo que pases de vuelta en la cosa Json. Así que sí, el modelo mental sigue siendo el mismo independientemente de si estás haciendo una transición con un formulario regular o si no estás haciendo una transición con un fetcher.

De acuerdo, Marvin? Hola, también tengo una pregunta sobre el manejo de errores, si está bien. Sí, nunca he usado Remix antes, pero leí en el descanso sobre el límite de captura que parece ser como el límite de error pero para respuestas incorrectas. Y me pregunto acerca de nuestra aplicación web donde la navegación y un outlet y un outlet mostramos muchos hijos y en cada uno de los hijos mostramos datos que deben cargarse pero podría haber algo mal y tenemos que mostrar un respaldo. Así que podríamos envolver a todos los hijos y un límite de captura y mostrarles un respaldo si alguno de ellos no puede cargar los datos. Entonces, en caso de que esto sea solo una vez, les mostramos un respaldo y todos los demás hijos siguen mostrando datos, podemos usar la navegación y así sucesivamente, pero ¿qué pasa si todos ellos, todos los datos no se pueden cargar, entonces preferiría mostrar solo un respaldo para todo el outlet y no muchos de ellos. ¿Hay alguna forma de optar por no tomar el respaldo más cercano y luego mostrar solo un outlet para que podamos seguir usando la navegación y así sucesivamente? Bueno, ten en cuenta que cuando tienes una interfaz de usuario anidada, nunca tienes outlets hermanos. Eso no existe en una interfaz de usuario anidada porque tampoco tienes segmentos de URL hermanos. No puedes estar en dos lugares a la vez. Solo se renderizará un respaldo en la página. Y así, si esta parte de la página es la que tenía un límite de captura, como el usuario no tiene acceso a esta factura o algo así. Y tienes un límite de captura justo ahí. Se va a renderizar justo ahí. Si no tienes un límite de captura justo ahí, entonces simplemente subirá por la interfaz de usuario, por las rutas hasta que encuentre una de esas rutas que tenga un respaldo o un límite de captura y lo renderizará. ¿Eso responde a tu pregunta o me estoy perdiendo algo? Sí, pero estoy pensando en si podrías volver a la diapositiva anterior, tienes el límite de captura como se muestra allí, pero también uno sobre la parte izquierda de la lista de facturas y luego tal vez también sobre este gasto de dinero arriba a la derecha. Entonces, la mayor parte de la página mostraría un respaldo. Y en mi ejemplo, solo quiero mostrar un respaldo debajo del encabezado de ventas. Pero si solo falla una carga de datos, todavía quiero mostrar el más cercano. Pero en caso de que la carga de datos para cada solicitud realizada en esta página falle, entonces quiero mostrar el respaldo con un alcance superior que está alto en el árbol de componentes. Entendido. Entonces, lo que sucede es que de la forma en que esta interfaz de usuario está diseñada o la forma en que funciona es que esta sección aquí o esta parte de la interfaz de usuario está controlada por la ruta de facturas. Y luego esta parte de la interfaz de usuario es la ruta de ID de factura. Y luego esta parte de la interfaz de usuario es la ruta de ventas. Entonces, si falla alguna parte de la carga de datos para cualquiera de estos componentes, se va a renderizar todo esto como un límite de captura. Así que no hay como renderizar una parte de eso en el límite de captura y otra parte en otro lugar. Podrías hacer eso, podrías hacer que funcione donde tu límite de captura renderice básicamente lo mismo y renderice tanto como sea posible. Y así que eso es totalmente posible que puedas hacer eso. E incluso podría renderizar el outlet para que el hijo, si funcionara, eso funcionaría. Simplemente nunca se me ocurrió hacerlo de esa manera. Pero sí, lo que estás describiendo, puedo ver que funciona. Simplemente nunca lo intenté de esa manera.

Permíteme verificar rápidamente que cubrí todo lo que quería. Sé que todavía hay más preguntas, pero permíteme verificar rápidamente. Sí, cubrimos las mutaciones. La función de mejora progresiva es genial. Puedes echarle un vistazo tú mismo. Es bastante simple. Es como lo que sucede si el JavaScript tarda demasiado o la solicitud tarda demasiado, y luego muestra alguna interfaz de usuario pendiente y cosas así. Es bastante sencillo. No creo que sea importante que lo cubramos. Así que estaré encantado de quedarme y responder tus preguntas, pero sí, puedes guardar la masterclass porque no vamos a hacer más ejercicios. Así que lo haré, y si necesitas irte y cosas así, está bien, solo antes de hacerlo, si pudieras mirar el archivo leeme en la raíz del repositorio, hay un enlace a un formulario de comentarios de la masterclass, y me encantaría que pudieras proporcionar algunos comentarios. ¿Puedes simplemente enviar JSON arbitrario a un punto final de API para enviar los datos del formulario o debe estar codificado en URL? Sí, puedes enviar JSON arbitrario en lugar de datos codificados en URL, si quieres hacer tu propia solicitud fetch. Entonces puedes crear lo que llamamos una ruta de recurso, que es una ruta que solo tiene una acción o un cargador, no tiene una exportación predeterminada. Y en eso, si estás enviando datos JSON, en lugar de request.formdata, dirías request.json, y ahí lo tienes, ahora tienes el JSON. Así que sí, eso es totalmente posible. Y podrías hacerlo también en esto, solo que Remix por defecto codificará el formulario como el formulario está codificado, así es como funciona el navegador. Y también hacemos transmisiones y todas esas cosas también para subir archivos y cosas así.

Pero eso de nuevo, vuelve a más allá de lo que estamos buscando, o lo que estamos haciendo en una sub-masterclass. Y dos diferentes forms en la misma ruta, esa es una gran pregunta. Te mostraré un ejemplo de eso, veamos, formulario. Solo buscando un ejemplo aquí. Sí, de acuerdo, entonces, no, no, hagamos el ID de la factura. Así que en la página de ID de factura de esta aplicación, si vamos a esta factura, tenemos, oh no, solo tenemos un formulario aquí. Oh, tiene que haber una página donde tengamos múltiples forms. Sí, arbitrariamente, así demuestra la UI pendiente. Dispara, bueno, la solución es, estoy seguro de que tengo un ejemplo, pero simplemente no puedo encontrarlo, pero la solución es básicamente desambiguar basado en un campo del formulario. Y entonces aquí, si miramos la intención aquí mismo, los botones de envío pueden tener un nombre y un valor. Y entonces si tuvieras múltiples botones de envío incluso en un solo formulario, puedes decir intención. Y esto es eliminar depósito. Así que cualquiera que el usuario haga clic en, eso es lo que será el valor de la intención. Y entonces puedes desambiguar en qué botón hicieron clic. Pero estos pueden ser forms totalmente separados también, y solo tienes que enviar el botón sea lo que sea el valor de la intención. Y entonces tu acción puede decir cuál fue la intención? Vale, voy a hacer esto. Oh, hicieron clic en ese formulario. Voy a hacer este otro. Así que sí, todo es solo cosas de la web que no tienen nada que ver con Remix. Eso es solo cómo funciona la web. Vale. Sandrina. Sí, entonces mi pregunta era sobre la migración. Así que imaginemos que tenemos un codeways en Next, GS bastante grande codeways, ¿cómo lo migraríamos a Remix? Sí, esa es una gran pregunta. Así que hay varias personas en el Discord de Remix que están haciendo esto ahora mismo. Y entonces probablemente puedan darte respuestas más perspicaces como respuestas basadas en la experiencia real. Uno de ellos sé que está usando Express y teniendo Remix o teniendo Next servido por ciertas rutas a través de Express se enruta a la aplicación Next. Y luego otras rutas serán manejadas por Remix porque Remix se conecta directamente a Express. Usas el adaptador Express. Y entonces cuando el usuario va de la aplicación Next a la aplicación Remix o viceversa, hacen una actualización completa de la página para pasar entre las dos. Podrías hacer lo mismo con Nginx o algo así. Solo enruta a las diferentes aplicaciones. Y luego con el tiempo solo migras. Eso es probablemente lo mejor porque el challenge es que Next usa un enrutador completamente diferente. Como todo lo demás es muy diferente. Y entonces no hay realmente una migración muy directa allí. No sé si es posible usar React Router con Next.js, pero probablemente no. Si fuera así, entonces migrarías a React Router primero. Y eso haría las cosas un poco más fáciles. Pero creo que probablemente el mejor enfoque allí es solo Nginx server que sirve a las diferentes aplicaciones o simplemente usar Express para servir a las diferentes aplicaciones. Y luego migrar con el tiempo de esa manera. Lo bueno es que ambos son React y por lo tanto no tienes que reescribir todos tus componentos. Pero sí, como tu carga de data y mutaciones, te encontrarás borrando un montón de code. Y yo he hecho esto antes en realidad. Yo fui uno de los que trabajó en el Remix vs Next donde tomamos su aplicación para su demo de E-Commerce y la reescribimos para usar Remix. Así que he hecho una migración de Next a Remix y no es muy divertido pero es totalmente posible. Sí, entonces aquí hay una pregunta. ¿El UseFetcher almacena en caché los data? ¿Todavía habría un caso de uso para algo como React Query por ejemplo, llenando opciones como de APIs? Así que sí almacena en caché los data. Así que aquí está la cosa. Cosas como React Query almacenan en caché los data pero lo almacenan en memoria y así puedes navegar, como ir aquí llenas esto y luego navegas a otra página y vuelves y ya está en caché. Eso es por qué eso es genial, ¿verdad? ¿Qué pasa si cierras la pestaña del navegador? Bueno, ahora se ha ido. Se ha ido para siempre porque estaba en memoria. Y entonces lo que Remix te anima a hacer en su lugar es usar encabezados de caché para que el navegador se aferre a él en su propia caché durante el tiempo que quieras que esté en caché. Y entonces cuando el usuario escribe en su consulta estará en caché en base a la URL de la consulta. Y entonces sí, ese es el mecanismo preferido para el almacenamiento en caché es simplemente usar la plataforma en lugar de implementar tu propia cosa. Así que el caso de uso del que estás hablando está bien cubierto. Solo está cubierto con un enfoque diferente.

¿Hay alguna palabra oficial sobre hacer Remix compatible con React Native, no solo compartiendo componentes sino usando Loader desde React Native? Así que lo mencioné antes. Creo que podría ser posible tener tu View o tus Loaders y Actions en el mismo archivo que tus Views para React Native. Esto no es una prioridad para nosotros pero es algo que creo que sería realmente genial y totalmente posible. Así que si alguien quiere experimentar con eso, sea mi invitado porque básicamente podrías tener una construcción especial como tal vez una convención para en lugar de un directorio de aplicación, tendrías un directorio nativo o algo así. Y luego todo lo demás sería lo mismo excepto que cada ruta sería una ruta de recurso y luego el formulario simplemente enviaría a la URL, como la URL completa para esa ruta o algo así. Creo que es totalmente posible. Me encantaría ver a alguien experimentar con eso.

La demostración que mostraste antes cuando desactivaste JS y la aplicación de tareas pendientes todavía funciona bien con la conexión 3G, bastante impresionante. Creo que deberías ponerlo en la página de inicio. Estoy de acuerdo.

De hecho, creo que esa demostración es impresionante. Y quieres ver, mira esto, el código para todo eso está en un solo archivo y es, en realidad, no, eso es el playground. Vamos a ver la versión final. Esto incluye toda la UI optimista, haciendo que parezca que es increíblemente rápida incluso si estás en una conexión 3G. Son 600 líneas de código. Eso incluye el código frontend y backend. Eso no incluye la gestión de sesiones para la autenticación de usuarios. Son 90 líneas de código, y el modelo, en realidad, no, no tenía un modelo. Hablé directamente con la base de datos en este archivo. Así que sí, es prácticamente como si fueras, si sumaras todas las líneas de código de todo junto, serían menos de 1,000 líneas, lo cual me parece gracioso porque es mucho menos que muchos de los MVC reales donde todo era solo UI, frontend, almacenamiento local, sin autenticación de usuarios, sin manejo de condiciones de carrera, sin persistencia real, nada de eso. Así que podemos hacer más con mucho menos, y además, porque gran parte de esto sucede en el backend, tampoco tenemos que enviar tanto JavaScript al frontend. Y por lo tanto, también se carga mucho más rápido, lo cual es genial. Así que cosas increíbles que puedes hacer cuando tienes un servidor.

Si vamos a Remix Runs stacks, esto es lo que estás viendo. Stacks es una característica realmente genial donde puedes crear tus propios andamios personalizados, pero tenemos tres oficiales que vienen preconfigurados con un montón de herramientas como ESLint, Prettier, BTest, TypeScript, Testing Library, MSW, Cypress, Tailwind, Prisma, todas las cosas que tiene. Autenticación de usuarios incorporada e instrucciones para implementar en fly. Todo está preconfigurado. El stack Grunge se implementará en AWS Lambda. Sí, es realmente impresionante. Así que eso es lo que recomendaría, investigar los Stacks. Y lo que es realmente genial es que la comunidad ha aparecido y si miras la etiqueta Remix Stack en GitHub, encontrarás un montón de ellos. Hay 54, creo, stacks diferentes que la gente ha creado. Así que es más grande que solo nosotros. Esperamos que la mayoría de las personas realmente construyan uno de estos para su empresa. Y luego tu empresa simplemente puede, como cualquier proyecto que necesites, crear un nuevo proyecto que ya tenga tu biblioteca de componentes instalada y configurada y todas esas cosas también. Así que echa un vistazo a los Stacks.

Oh, la aplicación de tareas pendientes. Permíteme mostrarte dónde está esa aplicación de TODO MVC, es Remix TODO MVC. Sí, aquí está el código para eso. ¿Remix tiene una API para invalidar o borrar la caché del navegador para un punto final? Entonces no hay una API. El navegador no proporciona una API para borrar la caché del navegador para nada. Pero puedes, si es necesario, en primer lugar, diré que si eso es una preocupación para ti en algún momento o durante un período determinado, entonces no uses encabezados de caché para eso en su mayor parte. Sin embargo, puedes hacerlo. Simplemente agrega un parámetro de cadena de consulta adicional y ahora obtienes una nueva entrada en la caché. Es posible, pero generalmente no es el mejor enfoque para hacerlo. He descubierto que el almacenamiento en caché depende del caso de uso. Por lo tanto, no queremos hablar tanto sobre el enfoque porque dependerá mucho del caso de uso. Entonces, sí, no hay una API para eso. No he encontrado una situación en la que necesitara tener cosas en caché en el cliente, pero puedes hacerlo si quieres, y también puedes usar completamente React Query con Remix si quieres. Simplemente no he encontrado una situación en la que sienta que eso sea útil. Y parece que Jonathan tenía una pregunta anteriormente. Lo siento, ¿tiene el equipo de Remix planes para expandirse más en un framework de pila completa como Rails? ¿Qué, quiero decir, hay más soporte incorporado para modelos de bases de datos y todas esas cosas? Sí, posiblemente. Creo que Remix ha resuelto la parte más difícil del desarrollo web, y esa es el centro de la pila. El puente entre el cliente y el servidor. Eso siempre ha sido lo más difícil. Rails está aquí tratando de lanzar ganchos de agarre con su hotwire o sus antiguos TurboLinks, todas las cosas que han estado intentando hacer. Y si alguien ha usado hey.com para su cliente de correo electrónico, saben que eso simplemente no funciona muy bien. Y luego Laravel tiene muchos de los mismos problemas. Pierdo la cuenta, y Phoenix con su vista en vivo. Y Laravel tiene su algo más en vivo. Todos ellos, live wire, creo que es lo que es. Así que todos están lanzando ganchos de agarre desde el servidor. Y luego Next está aquí en el otro lado y Gatsby y todos estos otros lanzando ganchos de agarre a funciones sin servidor o lo que sea, rutas de API y cosas así al servidor. Y así, eso es como este abismo de red es la parte más difícil de todo. Y Remix simplemente ha solidificado eso, simplemente lo ha clavado. Es como un puente sólido a través de ese abismo. En realidad, ni siquiera se siente como un puente. Es más como un dispositivo de teletransportación porque simplemente estás allí instantáneamente. Y no tienes que pensarlo. Así que eso, creo que es la parte más difícil. Y en cuanto a absorber los otros lados de la pila, como ir más allá del centro. Creo que es totalmente posible. La cosa es que en el ecosistema de JavaScript, ya tenemos algunas herramientas excelentes para acceder a la base de datos. Como Prisma es increíble. No estoy seguro de cuán valioso sería para nosotros construir nuestro propio ORM. Creo que probablemente solo envolveríamos Prisma si acaso. Y en el lado del cliente, como absorber el otro extremo de la pila, ya tenemos Reach UI, que también es parte de Remix. Y probablemente construiremos más sobre eso en el futuro y crearemos un Reach UI que tenga conocimiento sobre el backend. Por lo tanto, tenga algún conocimiento sobre el backend también. Y sí, podríamos construir un sistema de correo y un sistema de encolamiento o algo así, no sé.

Entonces, los stacks son lo que hemos armado porque aún no tenemos esas cosas. Y eventualmente, las cosas que están incorporadas en estos pueden ser incorporadas en Remix en el futuro. Pero sí, por ahora los stacks son un buen punto de partida. Genial.

Y había otra pregunta que me perdí acerca de Remix siendo de código abierto. ¿Cómo gana dinero? Así que tenemos muchas ideas sobre cómo ganar dinero con Remix o con servicios alrededor de Remix, algo parecido a lo que hace Laravel, o podríamos construir un producto, algo parecido a lo que hace Rails con Basecamp, o podríamos ser adquiridos. Siempre está esa opción. Así que si trabajas en una empresa gigante como Microsoft o algo así, avísame. Porque eso sería genial. Entonces no tendríamos que preocuparnos por ganar dinero. Simplemente alguien más pagaría las facturas. Pero sí, tenemos al menos un año, tal vez dos, de pista, solo de nuestra ronda de financiación inicial. Y así cuando vayamos a nuestra Serie A, obtendremos aún más. Así que no estoy muy preocupado por eso. Nuestros VCs en este momento nos están diciendo que, no te preocupes por ganar dinero ahora mismo. Solo preocúpate por conseguir usuarios. Así que eso es en lo que estamos enfocados. Pero sí, eso es.

Bien, ¿qué otras opciones y estrategias de carga de CSS para una ruta de página y componente específicos? Así que para una ruta, no entramos en esto para esta masterclass, pero sí, en realidad la aplicación TodoMVC que hago, tengo este todos.css. Así que es solo un archivo CSS regular, pero te darás cuenta si vas al Remix TodoMVC, en realidad te lleva a la página de inicio de sesión. Esto no tiene ninguno de este CSS aquí. Porque aquí tenemos ese cuerpo HTML de margen cero y todos los botones se supone que deben verse así. Básicamente copié y pegué esto y luego lo modifiqué ligeramente del TodoMVC original. Pero no quería que el CSS impactara las otras páginas. Como la página de inicio de sesión. Quería que esto tuviera tailwind en él porque no quería tener que escribir ningún CSS. Y así es como podemos manejar eso es que en el todo.tsx aquí, importamos ese archivo CSS y obtenemos una URL para la hoja de estilo. Y luego exportamos los enlaces. Así que estos son los enlaces que deberían estar en la página cuando esta ruta está activa y va a tener esa hoja de estilo de tareas pendientes. Bueno, cuando no estoy en esta página, esos enlaces no estarán allí. Y por eso no tenemos ninguno de esos estilos en esta página porque no estoy en esa ruta. Así que si miramos el HTML, no vamos a ver ese margen o relleno de cero, lo que sea. Así que esto es porque Remix nos da esa API para determinar qué enlaces deberían estar en la página. Así que cuando estoy en la página de inicio de sesión, veo este Tailwind.CSS, y eso es porque si voy al inicio de sesión, tengo este archivo CSS de Tailwind aquí, pero no quiero Tailwind en la página para el TodoMVC porque eso interferirá con los estilos para TodoMVC. ¿Tengo eso hasta hacer, ver Remix TodoMVC? Así que cuando estoy en esta página, Tailwind estropea esos estilos. Y así verás que tengo el enlace rel hoja de estilo para el CSS de tareas pendientes, pero no para el Tailwind. Así que todo eso para decir que Remix hace que la Cascada sea impresionante. Hemos traído de vuelta la Cascada y no tiene ninguna de las enormes desventajas que siempre tuvimos con la Cascada. La forma en que construirías CSS a escala en cualquier gran empresa en la que trabajé era que tendrías todos tus archivos CSS y luego Sass los juntaría todos en uno gigante que pondrías en todas las páginas. Esa era la forma más fácil de hacerlo. De lo contrario, tenías que añadirlo a cada página y eso era super molesto. Pero entonces tienes problemas de Cascada porque haces un cambio aquí y cambia todas las cosas. Así que Remix lo hace realmente agradable porque puedes asociar archivos CSS individuales a rutas individuales y son completamente independientes entre sí. Así que, esa es una forma de estilizar aplicaciones con Remix. La otra es simplemente usar Tailwind. Así que, eso es lo que hago y es increíble. Me encanta Tailwind pero sé que no a todo el mundo le gusta o tal vez tienes una aplicación que estás migrando o algo así. Así que, actualmente no soportamos CSS módulos o Vanilla Extract, pero tenemos unos planes realmente geniales para añadir el mejor tipo de soporte para esas cosas que puedas imaginar. Así que eso sucederá eventualmente. Pero sí, eso aún no sucede. Y luego, sí, en cuanto a CSS y JS, deberías dejar de usar eso. Es malo para tus usuarios. Es lento. Sí, quiero decir, no es terrible, pero porque ahora tenemos estas otras opciones, estas cosas son mejores. Solo usa Tailwind. Eso es lo que digo. Así que, eventualmente tendremos una mejor solución o un mejor soporte para otras soluciones que no son malas. Como, los CSS módulos son bastante buenos. Me gustan bastante los CSS módulos. Y Vanilla Extract también es muy interesante. Y esas cosas no son malas para tus usuarios. Esas están bien.

Bien, ¿qué pasa con los tipos TS que están obsoletos, solo los genéricos no utilizados? Sí, ese es el único. Es esa cosa de genérico no utilizado. No uses el genérico useLoaderData. El genérico JSON está bien. Es solo el de useLoaderData. Siempre tendremos algo mejor a lo que pasar, y siempre te daremos tiempo para hacerlo. Así que, no te preocupes por eso.

Bien, ¿cuál es el mayor challenge, el problema más difícil de resolver al construir Remix con el framework en sí? No lo sé. Para ser honesto, participo en sesiones de design con Ryan y Michael y nuestros otros ingenieros cuando hablamos de nuevas APIs y cosas así. Así que, estoy involucrado en esa fase. Pero en cuanto al desarrollo real, he hecho muy poco en la construcción de Remix. Así que, no sé si soy la mejor persona para responder a esa pregunta.

En realidad, sabes qué, probablemente el gestor de transiciones. Ryan y yo pasamos mucho tiempo hablando de eso. Y el gestor de transiciones es el que hace que pueda hacer esto, 3G lento. Y luego puedo venir aquí y hacer como, eliminar y boom, boom, boom, boom, boom, boom, boom. Ves todas esas solicitudes de cancelación y cosas así. Y si alguna de estas tiene, si hay un reenvío o hay algún tipo de, envío múltiple mientras todos están en marcha o algo así. Toda la lógica en torno a cuál de estas solicitudes cancelar, cuál de ellas, cuándo revalidar, todo eso, la lógica para eso es bastante complicada. Y funciona realmente bien. Está muy bien probado. Yo estuve involucrado en eso. Así que ahí lo tienes. Todo se ha ido, como por arte de magia. Ah, es tan genial. Sí, ves, y cancelamos todos esos porque no los necesitamos. Obtuvimos todos los data que necesitábamos de este. ¡Ta-da! Aquí está la respuesta. No, no quedan to-dos. Entonces, ¿por qué necesitamos esos? No los necesitamos. Muy genial. Bueno, parece que hemos terminado.