Enrutamiento en React 18 y más allá

♪♪ ♪♪ Hola a todos, soy Delba y trabajo para Vercell. Como algunos de ustedes pueden saber, somos los creadores de Next.js, y tengo curiosidad por saber cuántos de ustedes aquí usan Next.js? Vaya, así que son muchos de ustedes. Eso es asombroso. Entonces, aunque creamos Next.js, también tenemos una plataforma, Vercell. Y curiosamente, Vercell soporta más de, creo, algo así como 35 frameworks de front-end. Así que incluso si no usas Next.js, todavía podrías usar Vercell.

Y hoy, quiero hablarles sobre algunas cosas emocionantes en las que hemos estado trabajando, que es el enrutamiento. Y el enrutamiento en React 18. Ahora, como sabrán, hace unos meses, React 18 fue lanzado con nuevas características concurrent. Y en el blog de React, el equipo mencionó que esperan que las características concurrent tengan un gran impacto en la forma en que los desarrolladores ven las aplicaciones. Así que hoy, quiero discutir con ustedes qué podría significar este impacto y cómo cambiaremos la forma en que los desarrolladores ven las aplicaciones, especialmente con los React Server components, también. Y esto puede no solo cambiar las cosas para Next.js sino también para otros frameworks y mantenedores de bibliotecas. Y voy a mirar específicamente el enrutamiento, pero también mencionaré la obtención de data y la renderización, o como me gusta llamar a ellos, los tres pilares de la web, porque esos términos son muy interconectados.

Ahora, para darle a todos aquí un poco de contexto y también a las personas que podrían estar viendo en línea, creo que es importante simplemente dar un paso atrás y ver cómo ha evolucionado el enrutamiento en las aplicaciones de frontend. Ahora, por favor noten, voy a condensar años de historia de enrutamiento en unos cinco minutos, así que hay mucho más matices. Y una forma en que podemos ver el enrutamiento es a través del tipo de aplicaciones que podemos construir, aplicaciones de varias páginas, aplicaciones de una sola página y, más recientemente, aplicaciones híbridas. Así que en la web muy temprana, el enrutamiento era muy sencillo porque si lo piensas, cada URL se mapeaba a un archivo específico en un servidor. Y luego, usando lenguajes dinámicos del lado del servidor, pudimos generar una respuesta del servidor para una ruta específica. En una aplicación de varias páginas tradicional, el enrutamiento se hace en el servidor, y navegar entre páginas causa la recarga completa de la página a la que estamos muy acostumbrados. Ahora, cuando llegaron las mobile apps nativas, trajeron transiciones más suaves y nuevos UI patterns. Y las aplicaciones de una sola página, podrías decir, fueron la respuesta de la web a las aplicaciones nativas. Queríamos que nuestros sitios web se sintieran como aplicaciones nativas. Es decir, queríamos que tuvieran la misma user experience que las aplicaciones nativas. En una aplicación de una sola página tradicional, el enrutamiento se hace en el lado del cliente. Así que en la carga inicial, puedes ver una pantalla en blanco mientras el cliente busca y renderiza el contenido. Ahora, cuando navegas en una aplicación de una sola página, el cliente reescribirá dinámicamente nuevo contenido. Y para una ruta dada, el cliente está decidiendo qué contenido buscar y renderizar. Y el año pasado, Rich Harris, el creador de Svelte, dio una charla increíble sobre todo el debate MPA versus SPA, donde discutió algunos de los pros y contras de cada uno. Es una charla realmente genial, y recomiendo verla si no has tenido la oportunidad de hacerlo ya. Pero una conclusión de esa charla que quiero que recuerden es que reconoció que hay un patrón emergente en nuestra industria, donde las aplicaciones están haciendo la transición entre diferentes entornos, cliente o servidor.

Y llamó a este tipo de aplicaciones aplicaciones transicionales. Y las aplicaciones transicionales, intentan combinar los beneficios de ambos el cliente y el servidor, porque si lo piensas, ¿por qué no ambos? Así que esa es una visión general del enrutamiento en la web. Ahora vamos a profundizar en React.

Aunque React no inventó las aplicaciones de una sola página, podrías argumentar que contribuyeron a su popularidad. El hecho de que React se preocupara y todavía se preocupa principalmente por la UI y la renderización significa que la comunidad ha propuesto algunas soluciones diferentes para el enrutamiento. Y una solución del lado del cliente que rápidamente ganó popularidad fue React Router. Ahora, ¿cuántos de ustedes han usado React Router antes? Sí.

Así que el enfoque de React Router para el enrutamiento es lo que me gusta llamar enrutamiento basado en componentes donde usas código para mapear componentes específicos de tu aplicación a tu ruta URL. Y si lo combinas con una cadena de herramientas como create React app, entonces puedes crear fácilmente aplicaciones de una sola página. Y esto lleva a lo que creo que no es solo la adopción de React en sí, sino también aplicaciones que fueron completamente renderizadas en el lado del cliente.

Ahora, en 2016, unos años más tarde, Vessel introdujo Next.js. Y Next.js fue creado como un framework para ayudar a los desarrolladores a construir aplicaciones renderizadas en el servidor. Y Next.js adoptó un enfoque diferente para el enrutamiento. Utilizó lo que me gusta llamar enrutamiento basado en el sistema de archivos, donde los archivos de tu aplicación se mapean a tu URL. Y aunque Next.js se sentía muy similar a una aplicación de varias páginas en realidad utilizaba prefetching y navegación del lado del cliente para dar a las aplicaciones una sensación similar a la de una SPA, si se puede decir.

Ahora, otro paso incremental hacia las aplicaciones híbridas fue el los métodos de obtención de datos de Next.js, como getInitialProps. Y lo que estos métodos de obtención de datos hicieron fue mover la obtención de datos fuera de tu código de renderización o fuera de tu componente para que pudieras obtener datos tanto desde el cliente como desde el servidor. Ahora, me estoy centrando en Next.js hoy. Pero sería negligente de mi parte no reconocer algunos proyectos que también están trabajando en soluciones de enrutamiento para React, incluyendo Hydrogen de Shopify, Remix, y también Redwood. Así que avancemos unos años hasta principios de 2020, y los miembros de el equipo de React estaban discutiendo públicamente mover más trabajo de renderización al servidor.

La idea era que si estamos obteniendo datos en el servidor de todos modos, ¿podríamos mover algo de trabajo de renderización al servidor y, por lo tanto, reducir la cantidad de código que se envía al cliente? Ahora, probablemente puedes imaginar las opiniones que siguieron a ese tweet. Creo que se puede resumir mejor como, esto se parece mucho al enrutamiento del lado del servidor. ¿Estamos volviendo a las MPAs? Pero para citar un meme no tan serio de una de mis personas favoritas en Twitter, esto es menos un péndulo y más una espiral de mejora incremental. Así que cambios de dirección. No puramente SPA, no puramente MPA, sino una especie de pico en convergencia hacia lo híbrido. Que se beneficia tanto del servidor como del cliente. Y cada vez que se planteaba esta conversación, la reacción fue cuidadosa al enfatizar que estaban buscando una solución híbrida. Y una cosa importante a tener en cuenta aquí es que esta solución híbrida no estaría creando solicitudes adicionales al servidor. Aprovecharía una solicitud que tiene que existir de todos modos. Entonces, en diciembre de 2020, el equipo de React nos dio un regalo de Navidad anticipado que nos permitirá avanzar hacia soluciones más híbridas.

Eso fueron los componentes de servidor de React. Cuando combinas los componentes de servidor de React con suspense y la transmisión, ahora tenemos las primitivas o los bloques de construcción para abordar algunas desventajas de las aplicaciones de múltiples páginas o las aplicaciones renderizadas en el servidor mientras mantenemos la misma experiencia de usuario que amamos de las aplicaciones de una sola página o las aplicaciones del lado del cliente.

Pero hay una última pieza para el rompecabezas. Y en los últimos meses, el equipo de Next.js ha estado considerando esto. Si necesitamos ir al servidor para hacer un viaje para la obtención de datos y ahora vamos al servidor para hacer la renderización con los componentes de servidor de React, ¿podríamos también hacer el enrutamiento en el servidor? ¿Podríamos permitir a los desarrolladores construir aplicaciones donde el enrutamiento, la renderización y la obtención de datos suceden donde tiene más sentido? ¿Y podríamos darles convenciones que son fáciles de entender pero también les permiten mover partes de su aplicación ya sea al cliente o al servidor?

Así que hace unas semanas, compartimos un RFC. Y en este RFC, propusimos un nuevo enrutador para Next.js. Y este nuevo enrutador se basa en los componentes de React y las características de React 18. Hay muchos más detalles en el RFC y no entraré demasiado en los detalles de implementación. Si tienes curiosidad por saber más al respecto, te recomiendo que lo leas. Pero por ahora, permíteme compartir contigo algo que me emociona mucho y en lo que hemos estado trabajando.

Así que, si lo piensas, con los componentes de servidor de React, podemos entrelazar componentes de cliente y de servidor en un árbol. Esto significa que en una página o una ruta, podrías potencialmente tener tanto componentes de cliente como de servidor. Así que, con este nuevo modelo, se vuelve cada vez más importante dividir nuestras rutas en fragmentos independientes a los que llamamos segmentos de ruta. Estos segmentos de ruta, se mapean a un término ya existente, los segmentos de URL. Aunque estamos dividiendo las rutas, queremos mantener el enrutamiento del sistema de archivos porque generalmente tiende a ser una forma más intuitiva para los desarrolladores de definir sus rutas. Y dividir las rutas de esta manera, o como lo llamamos, hacer enrutamiento anidado, tiene tres beneficios principales.

El primero es que somos capaces de crear diseños, y los diseños han sido una petición muy antigua de la comunidad. Y la forma en que queremos definir los diseños es que un diseño es una interfaz de usuario que se comparte entre rutas, y estos diseños, no deberían re-renderizarse o perder estado en la navegación. También significa que los componentes que no cambian dentro de una ruta, como un diseño, también queremos asegurarnos de que sigan siendo interactivos a medida que el usuario navega entre rutas. En segundo lugar, si lo combinamos con componentes de servidor, eso significa que en la navegación, el servidor solo tiene que buscar y renderizar los segmentos que han cambiado, y no tenemos que re-renderizar todo el subárbol para esa ruta. Y en tercer lugar, podemos tener un control más granular sobre la obtención de datos. Así que en Next.js, como quizás sepas, actualmente obtenemos datos en el nivel de página, y con este nuevo modelo podemos obtener datos en el nivel de segmento. Y dado que ya hemos movido la obtención de datos fuera del código de renderización o fuera de los componentes, lo que podemos hacer ahora es iniciar ansiosamente esas solicitudes en paralelo. Y esto reduce lo que algunos de ustedes pueden conocer, que son las cascadas. Y en general, la cantidad de tiempo que se necesita para cargar el contenido de una ruta también se reduce.

Así que al construir una nueva ruta con los componentes de servidor de React, somos capaces de lograr tres cosas. Reducir la cantidad de código que enviamos al cliente, reducir la cantidad de trabajo que tiene que hacer el servidor, y también reducir la cantidad de tiempo que se necesita para hacer ese trabajo. Ahora, si lo combinamos con características concurrentes, como la transición, el suspense, y la característica del componente fuera de pantalla, podemos simplificar la creación de estados de carga y mejorar la experiencia de navegación. Por ejemplo, si quieres usar el enrutamiento del lado del cliente y estás obteniendo datos mientras renderizas, puedes tener demasiados estados de carga escalonados o spinners. Así que, realmente, lo que quieres hacer como desarrollador es consolidar ellos en indicadores de carga más significativos.

Por otro lado, si estás utilizando la renderización del lado del servidor, tienes que buscar y renderizar el contenido antes de que comience la navegación. Por lo tanto, tu aplicación parecerá no responder ya que el trabajo se está realizando en el servidor. Entonces, en ese caso, sí quieres incluir una interfaz de usuario de carga para indicar que se está realizando trabajo en segundo plano.

En otro caso, creemos que el framework debería proporcionar una convención fácil que permita a los desarrolladores crear estados de carga. Ahora, también podemos mejorar aún más la experiencia de navegación pre-renderizando una parte muy pequeña pero mínima de tu pantalla. Entonces, esto significa que cuando navegas entre pantallas, la navegación será inmediata, y el usuario podría ver algo como una foto de portada o un título antes de que se cargue el resto del contenido.

Y de manera similar, y este es uno de mis favoritos, es que podremos almacenar rutas. Y lo que eso significa es que podemos detener las rutas anteriores y luego pre-renderizar rutas futuras para que cuando el usuario navegue entre las rutas, restauremos el estado. Ahora, me estoy quedando un poco sin tiempo, así que voy a saltar estas dos diapositivas, pero... Si quieres saber más, tenemos más información en el IRC. Lo que quería destacar aquí hoy es que hay muchas formas de pensar en el enrutamiento en React, y hemos estado pensando mucho en cómo hacemos el enrutamiento en XJS. No se trata del enrutamiento en sí, sino de lo que nos permitirá hacer el enrutamiento. Entonces, podremos crear experiencias más eficientes con los componentes de servidor de React y también experiencias más fluidas mejorando la navegación. También queremos asegurarnos de que creamos experiencias que son compartibles, que no rompen la URL. Y para hacer eso, necesitamos crear convenciones simples que permitan a los desarrolladores implementar patrones de enrutamiento más complejos. Entonces, por último, pero no menos importante, antes de que se acabe mi tiempo, quiero tomar un momento para agradecer al equipo de React, porque son ellos los que nos dan las primitivas y los bloques de construcción para que podamos construir la próxima generación de aplicaciones híbridas. Muchas gracias. APLAUSOS Gracias. ¿Quieres ir? Sí. APLAUSOS Estuvo genial. No sé exactamente qué nueva característica de React fue, pero hubo un cierto punto, hubo una nueva característica que fue lanzada, y actualizamos nuestra aplicación, y se sintió tan rápida que no confié en ella. Parece que cada aplicación va a ser así ahora, ¿verdad? Y de vez en cuando obtenemos una nueva característica en React que es simplemente... Sí. Sí. Es demasiado rápido. No crees lo rápido que es. Eso se convierte en la nueva normalidad, y estás como, maldita sea, esto lleva mucho tiempo. Sí.