Remix Flat Routes – Una Evolución en el Enrutamiento

Hola, soy Michael Porter. Puedes conocerme en línea como Killamon, que es una abreviatura de Killamonjaro. He sido un gran fan de los volcanos durante mucho tiempo. Estoy emocionado de hablarles hoy en RemixConf Europe. Mi presentación será sobre Remix Flat Routes y la Evolución en el Enrutamiento.

Primero, comenzaré dando una breve introducción sobre la convención de enrutamiento actual tal como la conocemos hoy. Aquí está una estructura de enrutamiento típica. Consiste en un diseño sin ruta para páginas públicas, como la página acerca de, una sección de usuario con su propio diseño que tiene una vista de lista, una vista detallada del usuario, así como una página de edición. Remix utiliza carpetas para determinar el diseño principal. Se espera que el diseño principal incluya una salida para renderizar sus hijos. En este ejemplo, no hay una carpeta de ID de usuario porque queremos que la página de edición utilice el mismo diseño de usuario que las otras rutas. Dado que la página de edición no está anidada, utilizamos el punto para el diseño plano en lugar del diseño anidado. Cuando creas un diseño anidado, Remix te exige que crees una carpeta para sus hijos, más un archivo para el diseño en sí. Desafortunadamente, uno de los inconvenientes de esta convención es que la carpeta en un archivo de diseño termina separada en tu editor, ya que las carpetas suelen mostrarse primero. Esto puede ser molesto, especialmente en aplicaciones grandes con muchas rutas.

Como sabes, Next.js recientemente introdujo su propia versión de diseños anidados. Comparemos su convención con Remix. Aquí está la misma estructura de enrutamiento que el ejemplo anterior. Next.js utiliza paréntesis para diseños sin ruta, similar al prefijo de doble subrayado de Remix. Lo primero que notarás es que Next.js requiere una carpeta para cada segmento de la ruta. La ruta hoja es un archivo llamado página. Si un segmento de ruta añade un diseño, creas un archivo de diseño. Con Next., los diseños y las páginas son cosas separadas, mientras que Remix no diferencia. De nuevo, mirando nuestra ruta de edición de usuario, Next.js busca el diseño más cercano, que es usuario / diseño. Otra gran diferencia con Remix es que Remix utiliza exportaciones nombradas para cosas como meta, enlaces, encabezados, límites de error, etcétera. Y Next.js utiliza archivos separados para cada uno. Esto puede resultar en un gran número de archivos, dependiendo de las necesidades de tu aplicación. Llevó a una persona en Twitter a publicar esta captura de pantalla. Concedido, este es un ejemplo extremo. Uno de los beneficios de una carpeta para cada ruta, sin embargo, es que Next.js te permite co-ubicar archivos de soporte en la carpeta de la ruta.

Cosas como CSS, componentes, imágenes, etcétera. Esto es una de las principales cosas que los desarrolladores de Remix han estado pidiendo. Discutiremos cómo Remix FlatRoutes apoya esto en breve.

Ahora que hemos aclarado eso, hablemos de la nueva convención Remix FlatRoutes. Actualmente es un paquete MPM separado, pero se incluirá en una futura versión de Remix como funcionalidad central.

Entonces, ¿cuáles son los objetivos de Remix FlatRoutes? Hacer más fácil ver la ruta que tu aplicación está diseñada. Simplemente abre la carpeta de Rutas, y todas están ahí. Dado que el sistema de archivos generalmente ordena las carpetas primero, cuando tienes docenas de rutas, es difícil ver qué carpetas tienen diseños y cuáles no hoy en día. Ahora todas las rutas relacionadas están ordenadas juntas. Permitir la co-ubicación de archivos de soporte con rutas. Verás cómo puedes mantener tus estilos, componentes y otros archivos de soporte con tus rutas. Disminuir la fricción de refactorización y rediseño. Aunque los editores de code son bastante buenos corrigiendo las importaciones cuando mueves archivos, y Remix tiene el alias de importación tilde, es generalmente más fácil refactorizar una base de code que no tiene un montón de carpetas anidadas. Remix ya no requerirá esto. Además, al rediseñar la user interface, es más sencillo ajustar los nombres de los archivos en lugar de crear y eliminar carpetas y mover rutas para cambiar la forma en que se anidan. Y finalmente, ayudar a las aplicaciones a migrar a Remix. Las aplicaciones existentes generalmente no tienen una estructura de carpetas de rutas anidadas como las convenciones de hoy. Migrar a Remix es arduo porque tienes que lidiar con todas las importaciones. Además, como vimos con los nuevos diseños anidados de Next, FlatRoutes facilita la migración de otros frameworks a Remix.

Entonces, Remix FlatRoutes fue introducido por primera vez como un gist por Brian Florence el 7 de abril de este año. Publicó el enlace en el tablero de Remix, y yo casualmente lo vi. Y me intrigó porque yo también estaba buscando simplificar mi estructura de enrutamiento. Menos de dos semanas después, hice el primer commit implementando la especificación FlatRoutes. La parte más complicada fue tratar de averiguar cómo determinar el diseño padre cuando no había carpetas. Simplemente un nombre de archivo separado por un punto. Discutiremos cómo se implementó eso en un rato. Un punto interesante es que no fue hasta un mes después que Next.js publicó el primer RFC de diseños, describiendo su nueva convención de diseños anidados, que ahora está disponible como una característica experimental en Next.js 13. Como mencioné antes, Remix FlatRoutes está actualmente implementado como un paquete separado. Para agregarlo a tu aplicación, simplemente npm install dash d RemixFlatRoutes. Dado que las rutas se determinan en tiempo de construcción, esto es una dependencia de desarrollo y no se necesita en tiempo de ejecución.

Una de las cosas sobre Remix es que, aunque tiene opiniones fuertes, tiene algunas escotillas de escape que te permiten añadir tus propias personalizaciones. En este caso, es la configuración de rutas donde puedes añadir tus propias rutas además de la convención por defecto.

Dado que Remix asume que los archivos en la carpeta de rutas utilizan la convención por defecto, necesitarás decirle a Remix que ignore todos los archivos en la carpeta de rutas. Finalmente, llama a la función FlatRoutes para escanear la carpeta utilizando la nueva convención FlatRoutes. En el futuro, podrás especificar qué convención quieres utilizar directamente a través del archivo de configuración de Remix.

RemixFlatRoutes cambia algunas de las convenciones de nombres de archivos a las que estamos acostumbrados. Por ejemplo, para los diseños sin ruta, utiliza un solo guion bajo en lugar de un prefijo de doble guion bajo. El prefijo de parámetros sigue siendo el mismo, el signo del dólar, pero te mostraré cómo podemos cambiar eso más adelante. En lugar de usar carpetas para las rutas, el nombre del archivo incluye toda la ruta, así que utiliza el punto en lugar de la barra para separar los segmentos de la URL. Y finalmente, para manejar escenarios como nuestra ruta de edición de usuario, el sufijo de guion bajo especifica que el segmento no es un diseño porque no tiene una salida. Lo demostraré más adelante.

Remix FlatRoute admite dos configuraciones, archivos planos y carpetas planas. Los archivos planos se utilizarán normalmente para aplicaciones más sencillas ya que todo está en el nombre del archivo y no hay carpetas. Aquí está el mismo ejemplo que utilizamos antes, pero utilizando la convención de archivos planos. Observa que no hay carpetas. Toda la estructura de la URL es visible de un vistazo sin tener que profundizar en carpetas separadas. Todavía tenemos que identificar la ruta de índice, en este caso, usuarios barra índice. Observa cómo nombramos el archivo usuarios punto índice. El guion bajo inicial aquí es simplemente para ordenar la ruta de índice antes que las otras rutas hijas.

Como mencioné, estamos utilizando puntos en lugar de carpetas para separar las rutas. Pero sin carpetas, ¿cómo sabe Remix cuál es el diseño padre? Para determinar el diseño padre, Remix Flat Routes encuentra el prefijo que coincide más largo, y eso determina el diseño padre. Aquí vemos que el prefijo público de público punto acerca coincide con el diseño TSX público. Lo mismo con usuarios. ¿Recuerdas en el ejemplo anterior, donde no queríamos que la ruta de edición se anidara bajo el ID de usuario? Allí, utilizamos puntos en el nombre del archivo para lidiar con ello. Pero, ¿cómo lidias con eso cuando todo utiliza puntos? Remix Flat Route te permite usar un guion bajo final en una ruta padre para especificar que esto no es un diseño. Como puedes ver en la ruta de edición, el ID de usuario no debe ser tratado como un diseño padre, de ahí el guion bajo. Esto asegura que los usuarios que el prefijo de ID de usuario no coincida con esa ruta. Y Remix buscará entonces en el siguiente segmento un diseño que coincida, que es el diseño de usuarios.

Aunque Flat File simplifica considerablemente la convención de enrutamiento, lo hace con algunas desventajas.

Remix no diferencia entre rutas y diseños. De nuevo, los diseños son simplemente rutas con salidas. Entonces, index.tsx o layout.tsx significan lo mismo. Son simplemente alias y se utilizan principalmente para ser más descriptivos al mirar tus rutas. Remix admite múltiples alias para el archivo de ruta. Puedes usar index, route, layout, o page, así como agregar el prefijo de guion bajo. Esto ayuda a ordenar los archivos de ruta y diseño en la parte superior de la lista de archivos al co-localizar archivos.

Como mencionamos antes, uno de los principales beneficios de la convención de Carpetas Planas es apoyar la co-localización. Aquí estamos co-localizando archivos de soporte como CSS, componentes, archivos de servidor, imágenes, etc. Tu archivo de ruta ahora te permitirá importar estos activos como una importación relativa. He estado experimentando con la división de mi archivo de ruta en un archivo de ruta y un archivo de servidor de ruta. La principal razón es que uso Zod para la validación, y el paquete es algo pesado. Al definir y usar solo el esquema Zod en el archivo del servidor, garantizo que Zod no termine en el paquete del cliente.

Entonces, ahora que hemos visto los beneficios de las Rutas Planas, ¿cómo migramos nuestra aplicación existente? El paquete Remix Flat Routes incluye una herramienta de migración. Simplemente ejecuta el comando mpx migrate-flat-routes y especifica las carpetas de origen y destino. Las carpetas deben ser diferentes para evitar que la herramienta sobrescriba tus rutas originales. Puedes especificar si quieres archivos planos o carpetas planas. Aquí hay una captura de pantalla de las rutas de la aplicación de muestra Fakebooks antes y después de la migración. Puedes ver que te permite ver rápidamente cómo están estructuradas tus rutas sin tener que expandir las carpetas. Una forma de verificar que la migración se realizó sin problemas es ejecutar el comando mpx-remix-rutas en las rutas originales y en las rutas migradas. Dado que remix-flat-routes crea la misma configuración de ruta que se generó con la convención predeterminada, las rutas deberían ser idénticas tanto en jerarquía como en rutas. Las únicas diferencias son los nombres de los archivos, y tal vez algún ordenamiento. Durante los últimos seis meses, a medida que la gente ha probado remix-flat-routes, han ofrecido suggestions para mejoras y otras mejoras más allá de la especificación original escrita por Ryan. Ya he comenzado el proceso de PR para incorporar remix-flat-routes en el núcleo del framework. Si estas mejoras terminan en el núcleo aún está por determinarse. Y al menos, continuaré apoyando estos como complementos que podrás incluir en tu configuración. Uno de los puntos de dolor de la convención de enrutamiento de remix, tanto la actual como las rutas planas, es que el uso del signo $ puede ser problemático al trabajar con archivos en la shell. Dado que la mayoría de las shells tratan el signo $ como un prefijo de variable, esto te obliga a escapar del nombre del archivo al usar comandos. Considerando que esto es RemixConf Europe, sugiero usar el Euro, o si tienes un teclado típico de EE. UU., quizás el carat. Algunos desarrolladores quieren poder montar la aplicación Remix en una ruta distinta a la raíz, tal vez estaban agregando Remix a un sitio web existente. Aquí puedes configurar Remix para usar una ruta diferente, como myRemix app. Esto actualizará la ruta raíz y no tendrás que agregar una carpeta separada en la carpeta de rutas. Jacob Ebey, un miembro del equipo de Remix, recientemente creó una aplicación de muestra que tenía rutas procesadas por diferentes tecnologías de backend, lo cual es bastante impresionante. Tenía rutas para Node, trabajadores de CloudFlare, así como trabajadores de servicios, además de un conjunto común de diseños. Utilizó rutas planas de Remix, pero para soportar sus necesidades, tuvo que combinar manualmente las rutas en un solo espacio de nombres para asegurar que las rutas padre estuvieran correctamente definidas. En Remix Config, ahora puedes no solo especificar una sola ruta a tu carpeta de rutas, sino pasarle un array de rutas. Las rutas planas construirán la estructura de la ruta a través de múltiples carpetas de rutas, y las fusionarán en un solo espacio de nombres automáticamente. No necesitas hacer eso manualmente. Y como puedes ver en la salida de MPX Remix routes, las rutas se generaron correctamente. Entonces, en conclusión, he sido un seguidor de Remix desde el día 1, cuando era un producto de pago. Valió la pena, y definitivamente ha mejorado la forma en que construyo web apps hoy en día. No puedo creer que hace casi un año que Michael Jackson anunció por primera vez Remix Versión 1, al mundo, haciéndolo disponible como código abierto. En ese corto tiempo, ha habido dos conferencias de Remix. Una en mayo a la que tuve la suerte de asistir, donde pude conocer en persona por primera vez a personas como Michael, Ryan, y Ken, y muchos otros que solo conocía en Twitter o Discord. Así como esta conferencia aquí hoy, donde estoy agradecido de poder dar una presentación y hablar sobre algo que he construido y me apasiona. Y ahora con la reciente noticia de que Shopify ha adquirido Remix, todos podemos descansar tranquilos sabiendo que este increíble framework continuará prosperando. No puedo ni empezar a imaginar la increíble aventura que han tenido Michael y Ryan en estos últimos 12 meses y estoy emocionado de ver lo que traerán los próximos 12 meses. Gracias por tomarte el tiempo para ver mi presentación.