Cómo React Router se convirtió en un Framework

Muy bien, gracias. Como escucharon, mi nombre es Mark Dalglish, vengo desde Melbourne, Australia. Y como también escucharon, estoy aquí para hablar sobre cómo ReactRouter se convirtió en un framework. Obviamente es un tema muy grande, así que voy a tocar la superficie, pero espero darles una buena idea de dónde vino este movimiento.

Ahora, como también escucharon, he estado trabajando en el espacio de React durante mucho tiempo. De hecho, he estado trabajando con él durante unos 10 años en este punto. Y ese trabajo me ha llevado a mi posición actual, trabajando a tiempo completo con el equipo de Remix en Shopify, algo muy privilegiado para mí poder hacer en este punto de mi carrera. Realmente lo estoy disfrutando.

Y cuando vuelvo al inicio de mi carrera trabajando con React, para mí realmente comenzó con ReactRouter, porque lo que me interesó en React fue el hecho de que podía hacer renderizado en el servidor, mejora progresiva, y hacerlo con código compartido entre el cliente y el servidor. Y la primera vez que vi esto hecho de verdad, de una manera que podía llevar a producción, fue en este mega demo de ReactRouter que Ryan Florence armó hace unos 10 años. Y lo que fue realmente genial de esta demo es que mostró cómo podías hacer que el renderizado en el servidor y la obtención de datos funcionaran juntos. Y la forma en que se hizo por convención en este boilerplate fue que cada componente de ruta podía tener este método estático fetch data en él que describiría cómo obtengo los datos para esta ruta. Y podías averiguar después de hacer el emparejamiento de rutas en el servidor, podías averiguar cuáles de tus componentes de ruta tenían estas funciones en ellos. Podías llamarlos en paralelo, tomar los datos y pasarlos, y también ejecutar esto en el cliente mientras navegabas. Así que esto es exactamente lo que utilicé para llevar React a producción. Me he quedado sin luz, ahí vamos. Para llevar React a producción en los primeros días de React.

Así que fue un proyecto realmente genial. Ahora sé que de lejos no fui la única persona construyendo sobre ReactRouter, porque incluso hasta el día de hoy, aproximadamente la mitad de todas las descargas de React DOM se emparejan con ReactRouter. Así que hay una gran adopción todavía en la comunidad de React hoy. Ahora hoy lo que quiero hacer es profundizar en esta distinción entre bibliotecas versus frameworks. Porque si estamos hablando de ReactRouter convirtiéndose en un framework, es importante describir cuál es la diferencia entre dónde está hoy y hacia dónde se dirige. Porque ReactRouter es una biblioteca, eso no es algo controvertido de decir. Por supuesto, siempre ha sido una biblioteca desde su primer lanzamiento. Como dice aquí mismo en su readme, ReactRouter es una biblioteca de enrutamiento ligera y completamente equipada. Pero si vas a la documentación de React sobre cómo comenzar un nuevo proyecto de React, abordan esta pregunta directamente sobre si puedes usar React sin un framework. Y dicen que, por supuesto, aunque puedes usar React sin un framework, estamos en el punto ahora donde hay tantos grandes problemas desafiantes por resolver si intentas hacerlo solo que es mucho mejor, el desarrollador promedio está mucho mejor usando un framework. Y van más allá y hacen una distinción con lo que llaman frameworks de React de grado de producción. Y afortunadamente, en términos de mi trabajo, afortunadamente, Remix está en esa lista.

Así que, Remix se presenta como un framework de grado de producción. Aquí, se describe a sí mismo como un framework web de pila completa. Pero lo importante para el tema de hoy es que Remix está construido sobre ReactRouter y bastante fuertemente. Hasta el punto de que si vas a mirar uno de los paquetes que usas bastante en tu proyecto de Remix, Remix run slash React, vas a mirar el código fuente de ese paquete, y lo que vas a ver justo al principio es una gran pared de reexportaciones de ReactRouter DOM. Si estás familiarizado con ReactRouter y vienes a Remix, te sentirás como en casa. Muchas de esas APIs son completamente idénticas. Y por supuesto, Remix añade un montón de cosas encima. Pero significa que el ADN central de Remix es realmente ReactRouter. Así que, puedes pensar en ReactRouter, perdón, Remix como ReactRouter, el framework. Lo interesante de esta relación es que significaba que mejorar Remix a menudo significaba mejorar ReactRouter. Porque si necesitábamos añadir una gran nueva característica a Remix, usualmente requeriría cambios en ReactRouter. Si queríamos limpiar el código en Remix, a menudo requeriría que lo elimináramos de Remix y lo moviéramos a un nivel inferior dentro de ReactRouter. Así que, había esta relación continua mientras trabajábamos más en Remix y mejorábamos Remix en sí mismo. Esto fue especialmente notable con esta publicación de Ryan Florence hace un par de años en 2022 sobre remixing ReactRouter. Y esto anunciaba el hecho de que muchas de las mejores características de Remix realmente iban a comenzar a llegar para los consumidores de ReactRouter. En la práctica, lo que parecía es algo como esto donde podrías describir tu árbol de rutas como podrías haber hecho anteriormente. Pero ahora también podrías adjuntar cosas como loaders y acciones a tu ruta a tus acciones a tus rutas. Así que ahora estás comenzando a obtener muchos de los beneficios que obtienes de una aplicación Remix dentro de tu aplicación regular de ReactRouter. Esto se extendió aún más con la carga diferida de rutas. Así que, ya no necesitabas cargar todo el árbol de rutas al frente cuando lo describías de esta manera. Podrías en su lugar hacer que solo cargaras el código para esa ruta si y cuando lo necesitaras mientras navegabas. Así que, en este caso, esta es tu implementación estándar donde la ruta diferida es una importación dinámica aquí de nuestra ruta del dashboard. Y si vas a mirar el código fuente de eso, lo que puedes imaginar es que va a tener que devolver la API de lo que típicamente se describiría como una ruta en línea. Así que, ese componente del dashboard podría verse así aquí donde está exportando un loader, está exportando una acción, está exportando su componente. Y si entrecierras los ojos, si has visto Remix antes, esto básicamente se ve como lo mismo. Así que, estás usando ReactRouter pero estás obteniendo muchos de esos beneficios y decisiones de API que obtienes de Remix aquí mismo en ReactRouter. Así que, como consumidor de ReactRouter, lo que estás obteniendo ahora con esta configuración es enrutamiento anidado. Estás obteniendo división de código junto con eso y el modelo de gestión de estado simple que hace que Remix sea un placer para trabajar mientras sigues estando en el mundo de una biblioteca. Esto fue notablemente recogido por mucha gente. Ken C Dodds dio una gran charla en VConf el año pasado destacando que para él, ReactRouter, una vez que ha seguido este camino, ReactRouter unido con algo como Vite realmente comienza a sentirse como un framework y estoy completamente de acuerdo con esa posición.

Entonces, nuevamente, volviendo a esta distinción entre bibliotecas versus frameworks y si queremos profundizar más ahora en el lado de Remix, vale la pena explorar qué hace que Remix se sienta como un framework. Para mí, lo más notable al principio es el hecho de que tiene un CLI y posee el inicio de todo tu ciclo de vida de desarrollo y construcción. Entonces, si quieres iniciar un servidor de desarrollo, estás llamando al CLI de Remix y diciendo Remix dev si quieres construir para producción. Del mismo modo, estás ejecutando Remix build. Junto con esto, por supuesto, también tenías otro archivo de configuración en la raíz de tu proyecto, Remix.config.js y esto describe cómo tu servidor de desarrollo, cómo tu proceso de construcción y ese tipo de cosas deberían operar.

Remix también tenía opiniones muy fuertes sobre la forma de tu sistema de archivos. Entonces, había ciertos archivos que necesitaban existir aquí como tu ruta raíz, luego tu directorio de rutas. Por defecto, había un enrutamiento del sistema de archivos conectado que todo esto se recogería basado en el sistema de archivos, la convención de nombres de tus archivos. Podrías desactivar esto e introducir alternativas o ir puramente basado en configuración, pero esta era la configuración predeterminada con Remix. Y junto con esto, por supuesto, la gente espera un montón de características de un framework como Remix donde necesitábamos soportar TypeScript desde el principio, importaciones de activos estáticos, un montón de características de CSS como importaciones de efectos secundarios, módulos CSS que, por supuesto, en los que trabajé, soporte para post-CSS, tipos de archivos alternativos como MDX, y luego entras en el mundo de la recarga de módulos en caliente y polyfills para APIs de node en el navegador, particularmente para soportar paquetes de terceros en NPM. Así que, todas estas cosas necesitan ser gestionadas por el empaquetador, y esto está siendo gestionado por Remix en este caso.

Con Remix, fue construido sobre ESbuild, particularmente por sus beneficios de rendimiento sobre las alternativas en ese momento, por lo que ESbuild resultó ser un gran proyecto sobre el cual construir. Pero lo que nos dimos cuenta, por supuesto, trabajando en esto durante varios años y gran parte de mi trabajo yendo a este espacio en particular, poseer el empaquetador es realmente difícil. Es mucha responsabilidad asumir, y esa lista de cosas que la gente quiere del empaquetador simplemente sigue creciendo. Y particularmente cuando comenzamos a entrar en algunas de estas características más difíciles alrededor de la recarga de módulos en caliente, que no estaba incorporada en ESbuild, tuvimos que añadir eso encima, polyfills configurables de node, y cuando comenzamos a prototipar la optimización de dependencias para acelerar las construcciones especialmente para paquetes grandes de NPM, nos dimos cuenta de que efectivamente lo que estábamos haciendo es reinventar lentamente una versión, admitidamente peor, de Vite.

Así que la pregunta natural para nosotros que nos hicimos en este punto fue, ¿por qué no usamos simplemente Vite? Y esto es algo que la comunidad, la comunidad de Remix ya estaba impulsando. Había una discusión al respecto, muchos votos a favor, mucha gente por otras razones queriendo que siguiéramos el camino de estar construidos sobre Vite. Así que para nosotros se sentía como si esto fuera cada vez más el siguiente paso natural para nosotros en el lado del empaquetador.

Y así, en octubre del año pasado, anunciamos que estábamos cambiando a Vite. Estábamos lanzando una versión inicial inestable para obtener algunos comentarios tempranos, pero el objetivo era que nos moviéramos a Vite como nuestra forma estándar de construir aplicaciones Remix. Ahora estoy seguro de que no tengo que decirles a muchos de ustedes que Remix, perdón Vite, es una herramienta realmente genial para desarrolladores de JavaScript, pero quiero darle la vuelta hoy y resaltar el otro lado de esto, que es que como mantenedor de frameworks, es una plataforma realmente genial para frameworks. Y es por eso que estamos viendo tantos frameworks hoy en día construidos sobre Vite.

Así que cuando comenzamos a ir por este camino, realmente queríamos inclinarnos hacia esta filosofía de decir que Remix es solo un plugin de Vite. Queríamos ver hasta dónde podíamos llevar esto. Y así, en nuestra versión inicial inestable, esto es lo que parecía. Tendrías tu configuración de Vite escrita en TypeScript, lo cual es genial, no algo que pudieras hacer en Remix hasta ese momento. Y traerías el plugin de Remix y lo añadirías al array de plugins en tu configuración de Vite. Eso significaba que ya no había otro archivo de configuración dedicado en tu proyecto. Simplemente te conectarías a la configuración existente de Vite que podrías ya estar usando, especialmente si estás usando herramientas como Vitest y ese tipo de cosas.

Así que tienes tu Viteconfig.ts ahí. Eso significaba que como consumidor ahora, no estás hablando con Remix como tu punto de partida, estás hablando con Vite. Ejecutas Vite dev para iniciar tu servidor de desarrollo. Y de manera similar, un poco más complicado, pero aquí cuando estás ejecutando la construcción, hay un par de pasos. Ejecutarías Vite build, que ejecuta tu construcción de cliente, y eso sería seguido por Vite build con la bandera SSR para construir tu servidor. Así que uno tras otro.

Pero hay una gran limitación con este modelo con la que nos encontramos, y es que los consumidores habían codificado el proceso de construcción en sus scripts de construcción. Así que eso significaba que si mirabas un proyecto construido sobre Remix Vite, verías su script de construcción y verías ese comando que te mostré antes, justo ahí en el package JSON, Vite build y Vite build SSR. Pero el problema con esto es que los frameworks necesitan más control. No es algo que realmente los consumidores deberían poseer. Y eso es porque los frameworks necesitan tener control sobre el número de construcciones, el orden de ellas, como si es la construcción de cliente primero antes de la construcción de servidor o al revés. La comunicación entre esas construcciones es importante, y una vez que la construcción ha terminado, puede haber lógica adicional que necesites ejecutar, tal vez para adaptarlo a una plataforma diferente, ese tipo de cosas.

Así que cuando juntas todo esto, hay este requisito general de orquestación de construcción que no estaba siendo gestionado por Vite, y si poníamos Vite en tus manos como el punto de contacto principal, ahora era tu trabajo gestionar la orquestación de construcción. Así que esto se convirtió en un problema para nosotros, y desafortunadamente tuvimos que dar un paso atrás un poco de esa filosofía de ser solo un plugin de Vite. Así que cuando lanzamos la versión estable de Remix Vite y la hicimos la forma estándar de construir aplicaciones Remix en adelante en febrero de este año, 2024, tuvimos que cambiar un poco esa filosofía y decir que Remix es principalmente solo un plugin de Vite.

Así que si vas a mirar el código fuente, la mayoría del código está en el plugin de Vite, pero todavía existe esa capa de orquestación de construcción en nuestro CLI. Así que eso significaba que todavía necesitabas llamar a Remix para configurar tu servidor de desarrollo de Vite o ejecutar una construcción de Vite, pero esa pieza de orquestación de construcción era ese envoltorio mínimo encima. Ahora, como una pequeña nota al margen, afortunadamente Vite es un objetivo en movimiento de una buena manera. Siempre están agregando nuevas características que lo hacen una plataforma aún mejor para frameworks, y así en abril de este año, Patak aquí en GitHub anunció la próxima API de entorno para Vite. Ahora esto agrega un montón de nueva funcionalidad a Vite, pero notablemente para los propósitos de esta charla, agrega el concepto de un constructor de Vite que permite a los frameworks orquestar todas las construcciones de entorno que necesitan para obtener un solo comando de construcción de Vite para construir toda la aplicación. Y continuaron diciendo que esto significa que están cambiando su postura sobre el framework como patrón de plugin, haciéndolo de primera clase a partir de Vite 6 en adelante.

Así que como mantenedor de frameworks, esto es enorme. Esto es Vite diciendo que vamos a asumir aún más responsabilidad de lo que es construir un framework sobre Vite. Con esta nueva API, significaba que ya no codificarías que estás ejecutando una construcción de cliente seguida de una construcción de servidor. En su lugar, simplemente ejecutas Vite build con la bandera de aplicación, y esto luego se delegaría al constructor de Vite que describieron anteriormente. Efectivamente, lo que esto significa es que en tu configuración de Vite, puedes configurar un constructor, pero en la práctica, esto sería configurado por uno de los plugins que estás usando. Y en eso, hay un gancho de construcción de aplicación, que tiene la instancia del constructor pasada a él, y esto tiene acceso a los entornos que estás construyendo. Ahora, estos entornos son configurables.

Los frameworks pueden configurar qué entornos necesitan. En nuestro caso, eso podría ser simplemente un conjunto de entornos de cliente y servidor. Ahora, ingenuamente, podrías simplemente ejecutar esos en paralelo. Si hay alguna dependencia, esto se puede gestionar aquí. Puedes ejecutar la construcción del cliente primero, en nuestro caso, seguido por la construcción del servidor. Así que el plugin puede tomar plena posesión de cómo exactamente debería funcionar el proceso de construcción. Así que cuando juntas todo esto, Vite realmente está haciendo mucho desde la perspectiva de un mantenedor de frameworks. Vite nos está dando un gran empaquetador con configuraciones predeterminadas sensatas. Así que muchas de esas características que enumeré antes, tuvimos que agregar sobre esbuild. Estas simplemente vienen de serie con Vite. Pero todo el asunto es configurable y enchufable, y esos plugins son composables. Así que es trivial agregar un montón de ellos juntos. Obtienes ese gran entorno de desarrollo con recarga de módulos, servidor de vista previa si lo necesitas, y canalización de construcción. Y ahora con la API de entorno, estamos obteniendo este framework como un patrón de plugin. Así que dadas todas estas características que Vite nos está dando, es una buena pregunta preguntar qué queda para un framework.

La forma en que lo pienso es que hay casi una toma más mínima de un framework que está surgiendo de todo este poder que nos da Vite, que es este patrón de convenciones como un plugin en lugar de ser necesariamente pensado como un framework. Y eso es porque todo lo demás es el código de biblioteca habitual, si realmente te inclinas hacia este modelo. Nos encontramos desde una perspectiva de Remix mirando código como este y diciendo, si estoy importando componentes u otras APIs de un paquete como Remix run React, ¿qué es incluso Remix en este punto? Si la gran mayoría de las cosas específicas del empaquetador están siendo hechas por el plugin de Vite, y esa línea entre o esa brecha entre lo que es Remix y lo que es React Router continúa reduciéndose, ¿por qué no simplemente deshacerse de la indirecta y hacer que los consumidores importen estas cosas de React Router, la biblioteca subyacente, directamente? Parece un modelo mental mucho más simple, una forma mucho más simple de pensar en las cosas, y el código llega a vivir en un solo lugar, lo cual es genial para nosotros como mantenedores también. Y es por eso que en mayo de este año en React Conf, anunciamos que íbamos a fusionar Remix tal como existe hoy en React Router. Así que todas estas grandes características del framework en tiempo de construcción que esperas de Remix estarán disponibles para el consumidor promedio de React Router. Y esto estará disponible en el próximo React Router v7. Hay una pre-lanzamiento disponible ahora si quieres unirte temprano y darnos tu opinión, pero está llegando muy, muy pronto.

Así que lo que esto parece es muy similar a lo que vimos antes con Remix. En tu configuración de Vite, puedes incluir el plugin de React Router desde React Router slash dev slash Vite, y agregas el plugin de React Router a tu array de plugins de Vite. Como dije antes, porque esa capa de orquestación de construcción todavía es necesaria, porque aún no tenemos la API de entorno disponible, necesitas ejecutar React Router Dev para iniciar tu servidor de desarrollo y React Router build para iniciar tu proceso de construcción, pero esto puede cambiar en el futuro. Así que ahora que React Router nos está dando muchas de estas características adicionales, ahora tiene su propio CLI. Está gestionando los puntos de entrada de tu aplicación e incluyendo los comandos que tienes que ejecutar. Te da una versión oficial ahora de la API de módulo de ruta que obtuvimos con Remix. Obtienes enrutamiento del sistema de archivos, convenciones de renderizado del servidor y cliente, y ahora con características añadidas más recientemente también con modo spar y pre-renderizado. Es un conjunto bastante completo aquí y por lo tanto es justo mirar esto ahora y decir que React Router ahora es un framework. Pero lo que es interesante creo es que sigue siendo una biblioteca, así que todas las APIs existentes que has llegado a conocer y amar de React Router 6 hoy todavía están ahí, por lo que puedes continuar enviando como lo haces hoy con o sin el plugin de Vite, con o sin Vite, puedes usar empaquetadores alternativos.

Todas esas APIs de biblioteca de nivel inferior todavía están ahí. Así que un punto medio interesante, creo, otra forma de pensarlo, es que React Router es una biblioteca que también tiene un plugin de Vite, nuevamente siguiendo ese patrón de convenciones como un plugin, donde te enviamos un plugin que te ayuda a usar mejor la biblioteca si lo deseas, pero es completamente opcional. Esto ya ha comenzado a impactar nuestro diseño de API, especialmente a medida que estamos moviendo características de Remix de vuelta a React Router.

Un gran ejemplo de esto es cómo ahora en React Router v7, el enrutamiento del sistema de archivos no es el predeterminado como lo es en Remix. Así que en su lugar configuras tus rutas que se descubren en tiempo de construcción a través de este archivo de configuración routes.ts y se ve algo así donde puedes exportar un array de objetos de configuración de rutas. Aquí estamos definiendo una ruta, una ruta de about, tenemos un layout con algunos hijos. Ahora, en la práctica, realmente no queremos que estés definiendo estos objetos, en su lugar te hemos dado estas funciones auxiliares limpias para generarlos de una manera agradable y segura en tipos y también tienes ese tipo de configuración de ruta para asegurarte de que todo el árbol de rutas sea válido. Pero todo esto se evalúa en tiempo de construcción y todo está apuntando a módulos de ruta separables en disco. Lo que es genial de este modelo es que porque está escrito en código, es trivial para ti optar por el enrutamiento del sistema de archivos si eso es algo que prefieres.

Así que lo que parece con el paquete oficial FS routes que es parte de la nueva API de React router v7, tienes disponible la función flat routes que es básicamente tus convenciones de enrutamiento del sistema de archivos de Remix v2 disponibles. Y puedes simplemente llamar a esta función en tu archivo routes.ts y esto golpeará el sistema de archivos y averiguará el árbol de rutas basado en los archivos en disco, cómo se llaman y demás. Así que si quieres, puedes simplemente hacer un console log del resultado de esas rutas flat allí y verás cómo debería verse el archivo resultante, cómo debería verse el árbol de rutas resultante. Así que nuevamente, si entramos en la separación entre bibliotecas versus frameworks, creo que lo interesante ahora es con este patrón de ser un vplugin sobre una biblioteca es que tú puedes elegir cuán opinado quieres que sea React router.

Así que React router es una biblioteca como siempre lo ha sido. Pero si vas a comenzar un nuevo proyecto de React, nuevamente siguiendo la documentación y te dicen que, ya sabes, recomiendan que uses un framework, entonces es justo decir ahora que oficialmente React router es un framework también. O usando las palabras de la documentación de React, un framework de React de grado de producción. Y eso es realmente una gran noticia si estás en esa línea azul, esa mitad de proyectos de React que están en el mundo hoy en día ya construidos sobre React router. Es una gran noticia para ti porque significa que todas esas características de nivel de framework probadas en batalla que obtienes de Remix estarán disponibles para ti en la próxima versión de React router. Así que si estás en esa línea azul o si quieres unirte a nosotros en esa línea azul, realmente te animo a que actualices a React router v7 y luego pruebes el vplugin de React router ya sea en tu proyecto existente o en un nuevo proyecto para tener una idea de ello. Y realmente ver cómo puede ayudar a tu experiencia de desarrollo y cómo puede ayudar con la calidad del producto final que entregas a los usuarios, que en última instancia es lo más importante. Y por supuesto, nos encantaría que nos dijeras qué piensas. Así que únete a nosotros en el discord, danos cualquier opinión, especialmente mientras estamos en pre-lanzamiento, así que únete temprano y sí. Me encantaría saber qué piensas sobre el nuevo vplugin. Así que eso es todo por hoy, muchas gracias por escuchar.

Bien, entonces tenemos muchas preguntas y tenemos, ya sabes, fue como un nivel alto, ya sabes, hablar sobre mucha de la filosofía que, ya sabes, tienes alrededor, ya sabes, este tipo de cambio. Y creo que muchas de las preguntas reflejan eso también, muchas preguntas de nivel realmente alto que creo que es bueno.

Así que déjame comenzar con la pregunta más votada por lejos, que es si hay algo más que ya puedas decir sobre la marca Remix en el futuro ahora que Remix, tal como existe hoy, es absorbido por React Router? Sí, entonces hay otro aspecto de por qué queríamos hacer este movimiento. No lo incluí en la charla porque lo que me gusta es que no necesitas tener este contexto para que este movimiento tenga sentido. Pero esto, uno de los grandes impulsores fue que ya estábamos explorando cuál es la próxima generación de Remix. Y algunas de estas primeras exploraciones que están realmente bastante avanzadas, es efectivamente un framework diferente.

Es un cambio tan grande. Pero todavía estábamos trayendo ese espíritu de compatibilidad hacia atrás que siempre ha estado allí con Remix y React Router. Así que estábamos hablando de permitirte montar una aplicación Remix v2 en lugar de Remix v3. Y ahí es cuando comencé a ponerme un poco nervioso porque no quiero que estemos hablando de números de inversión. Y entonces ya se había hablado de hacer esto, pero yo fui quien realmente sugirió que tal vez la forma más limpia de hacer este tipo de movimiento es decir tomemos Remix tal como existe hoy y lo movamos a React Router. Y luego eso libera la marca Remix para vivir lado a lado incluso en el futuro.

Así que entonces podemos hablar de montar una aplicación React Router dentro de esta versión futura de Remix. Así que se trata, realmente se trata de desacoplar las dos filosofías.

Y eso tenía perfecto sentido porque, como dije, si Remix es efectivamente React Router, el framework, es como si estuviera volviendo a casa a donde realmente pertenece a largo plazo. Genial. Y tú como que, no sé si intencionalmente o accidentalmente, como que esquivaste la pregunta, pero afortunadamente hay una pregunta más específica aquí. Es como, ¿qué pasará con Remix después del lanzamiento de React Router v7, hay una especie de visión o simplemente no estás listo para hablar de ello todavía?

Sí. Así que Michael y Ryan han sido los que han estado trabajando más de cerca en ello mientras hacemos gran parte del trabajo en Remix tal como es hoy y React Router. Pero el objetivo es una vez que el polvo se haya asentado en el lanzamiento de React Router v7 para que nosotros, como equipo, comencemos a poner un poco más de enfoque en esa versión de próxima generación de Remix. Pero por ahora, no es algo a lo que esté muy cercano. Genial.

Sí. Quiero decir, cuando estaba escuchando la presentación, creo que fue realmente encantador escuchar el razonamiento que parecía venir de una perspectiva puramente de lo que tiene sentido, ¿verdad? Como muchos, ya sabes, frameworks hoy en día son, ya sabes, también empresas, ya sabes, como, y tienen una necesidad de también hacer cosas para una especie de marca y empaquetado y moldeado y, ya sabes, todas esas cosas. Pero esto parece un movimiento hacia un tipo de código abierto más puro, como aquí, aquí está toda la funcionalidad y no tenemos ninguna reclamación sobre el tipo de propiedad intelectual de ello de alguna manera. ¿Es también tu tipo de lectura sobre esto o?

Quiero decir, lo que me gusta del equipo de Remix trabajando en ello es que siempre ha habido un enfoque en la simplicidad y en eliminar cosas y eso siempre me sucedió cuando presenté mi propio trabajo, como el trabajo de Routes TS que mostré antes. Eso es algo en lo que trabajé donde gran parte de mi trabajo inicial fue, ya sabes, agregar estas capas de abstracción e indirecta, porque pensé, podríamos querer soportar esto en el futuro y soportar aquello. Y Michael y Ryan están mucho más en el campo de como, si no lo necesitamos aún, no lo agreguemos. Centrémonos en mantener las cosas lo más simples posible.

Y creo que este movimiento de pasar de Remix a React Router es otro ejemplo de eso de decir, simplemente eliminemos capas de indirecta de, ya sabes, tienes que tener un framework encima de una biblioteca y todas estas diferentes APIs. No lo mencioné en mi charla, pero con React Router V7, estamos eliminando también la capa de React Native, porque no muchas personas la estaban usando y eso añadía complejidad a la API. Así que ya no hay un React Router DOM. Es todo solo React Router. Así que la mayoría de ustedes, estoy seguro de que prácticamente todos los que están usando React Router están usando React Router DOM. Ahora es solo React Router en V7. Así que es como una simplificación adicional, en todos los lugares donde podamos hacerlo. Sí. Sí.

Quiero decir, esa es una gran respuesta. Y creo que una cosa que se puede decir de Michael y Ryan es que no han tenido miedo de hacer cambios importantes en el pasado. Así que, ya sabes, son muy, muy valientes en ese sentido. Hay una especie de pregunta, que creo que ya respondiste en el, en el, en el tipo de negativo ya, pero ¿hay una preocupación de que React Router esté creciendo demasiado para su alcance? Como, ¿hay cosas allí que como la mayoría de los consumidores simplemente van a decir, bueno, eso no es para mí? Sí. Quiero decir, es una pregunta justa. Creo. No lo creo porque creo que es, es una muy buena separación. Como dije, el ángulo de las convenciones como un plugin es, es uno muy bueno para mí porque está diciendo que la biblioteca subyacente todavía está allí. Si quieres omitir el plugin de Vite y simplemente usar como una biblioteca, nada ha cambiado efectivamente para ti. Pero el desafío para nosotros, ya sabes, mantener una biblioteca como React Router y React en sí mismo teniendo el mismo desafío que lo está llevando hacia componentes de servidor es algunos de estos problemas que las personas tienen al construir una aplicación, como problemas arquitectónicos, comienzan a tocar el empaquetador y, ya sabes, porque estás respondiendo preguntas como, ¿cómo hago la división de código? Y ¿cómo sé, como, cómo se comunica mi servidor con el cliente, las dos diferentes construcciones y asegurar que haya una buena transferencia y ese tipo de cosas. Hay todos estos problemas que si eres solo una biblioteca, realmente no hay una buena manera de simplemente dar a las personas una solución lista para usar. Todo lo que puedes hacer es darles plantillas y decir, aquí, ya sabes, aquí hay un montón de código para que copies y pegues para hacer una buena arquitectura renderizada en el servidor sobre React Router. Y así para mí, es solo agregar esa capa extra de conveniencia para decir, si quieres, de nuevo, es opcional. Si quieres, aquí hay un plugin de Vite que es nuestra opinión de cómo crear la mejor arquitectura sobre React Router, pero está en su propio lugar separado en la pila que, de nuevo, puedes ignorarlo si quieres. Así que creo que, para mí, es un buen ejemplo de cómo tener lo mejor de ambos mundos. Genial.

Tenemos algunas preguntas aquí que son sobre Vite. Así que en el tema de Vite, voy a agrupar todas juntas en una, y luego puedes como que averiguar cómo responder también. Así que las preguntas realmente son, ya sabes, una, ¿cómo podría la reciente financiación de riesgo de Vite afectar a Remix? Entonces, ¿cuáles son tus pensamientos sobre los diferentes modelos de financiación de OSS? Y luego, en general, ¿hay planes para hacer de Remix un plugin compatible con otros empaquetadores? ¿O es Vite algo así como, ya sabes, es esto como un matrimonio? Sí.

Sobre el tema de la financiación de Vite, ni siquiera es algo en lo que realmente haya pensado. Como, no me pareció una preocupación en absoluto, así que realmente no tengo mucho que decir. Tal vez quien me hizo la pregunta, tal vez venga a hablar conmigo, puede haber más en ello de lo que me estoy perdiendo. Pero sí, si acaso, me ayuda a sentirme más seguro al apostar por Vite a largo plazo. En cuanto a, ¿cuál era la otra pregunta? Sí. ¿Planeas agregar algunos de los otros empaquetadores? Sí. Esa es una muy buena pregunta. Es una pregunta obvia una vez que comenzamos a decir, ya sabes, estamos apoyando Vite como un plugin de Vite. Es una pregunta realmente obvia de, como, ¿qué pasa con otros empaquetadores? Y es realmente complicado, porque creo que como con cualquier cosa de esta naturaleza, siempre hay un poco de riesgo en términos de extenderse demasiado. Porque incluso solo apoyar Vite requiere mucho trabajo cuando consideras cosas como, tenemos que apoyar la recarga de módulos en caliente, y hay un montón de integraciones que tenemos que hacer allí. No es algo trivial apoyar Vite. Así que creo que si hubiera suficiente demanda, definitivamente tendríamos que considerarlo. Pero creo que estamos en esa etapa temprana donde, porque estamos todavía probándolo como un modelo, como en el sentido de que ahora lo estamos moviendo a React Router, probablemente no estaríamos apresurados en extendernos demasiado al apoyar diferentes empaquetadores. Vite es el líder claro en este punto, lo que hace que sea más fácil para nosotros invertir allí. Dicho esto, otro aspecto de tener esa clara separación del plugin de Vite frente a la biblioteca, significa que si eso es algo que realmente te importa, es de código abierto, puedes ir a ver el código fuente del plugin de Vite, y obtendrás una buena idea de lo que podría llevarte hacer una implementación similar sobre RSPack o lo que sea que sea. Así que si quieres hacer eso, sería genial, y probablemente ayudaría a acelerar las cosas, quien haya hecho la pregunta. Oh sí, PR es bienvenido, como dice el viejo dicho. Ponlo en su propio repositorio, no tienes que pedir permiso, solo hazlo, y si también obtienes algo de adopción, eso también ayudará. Genial.

Bien, tenemos tiempo para una pregunta más, así que solo voy a ir con la que tiene más votos aquí. ¿React Router va a apoyar los componentes de servidor de React? ¿Es esto algo que estás planeando? Definitivamente es el plan. Cuando hemos demostrado públicamente prototipos de que funciona, hay un poco de desafío en términos de tiempo, porque depende de la API del entorno de la que hablé antes que aún no es estable, y depende de los componentes de servidor, que obviamente ellos mismos no son estables aún, así que hay un poco de trabajo involucrado allí. Pero lo que es genial de esto es que, ya sabes, la demostración que hemos mostrado, lo que me gusta es que se integra muy bien en el paradigma actual de React Router donde, ya sabes, tus cargadores pueden devolver todo tipo de datos tipos ahora. Eso es algo que hemos agregado recientemente, mucho más soporte para diferentes tipos de datos que puedes devolver de un cargador, y nuestra visión de RSC es básicamente decir que puedes devolver elementos de React de tus cargadores y eso es todo. Así que ese es el objetivo, pero como dije, dependemos un poco de otras APIs que se estabilicen primero. Genial, y esa sería una muy buena manera de cerrar, pero había una última pregunta que me sentí mal por no responder porque ha estado allí por un tiempo, que era ¿hay planes para definir mejor el orden de ejecución de los cargadores de rutas anidadas? Esta es una pregunta muy necesaria. Esa es una pregunta profunda.

Trabajo más en el lado del bundler de Remix, así que esto podría incluso estar fuera del alcance de, ya sabes, probar mi conocimiento. Creo que hay una API que te permite hacer esto, pero puede que incluso sepas, algunos de ustedes pueden incluso saber mejor que yo. Estoy profundamente en el lado del bundler.

Sí, bueno, la persona que hizo esta pregunta fue lo suficientemente amable como para poner su nombre allí, así que Dennis Nemetov. Si no obtuviste respuesta a tu pregunta, tal vez puedas contactar a Mark y Mark puede dirigirte a la persona correcta en el equipo. Sí, sí, sí.

Bueno, gracias, Mark. Ese fue todo el tiempo y todas las preguntas que teníamos, así que muchas gracias. Demos un gran agradecimiento a Mark. Gracias. Eres libre.