Video Summary and Transcription
El enrutamiento en React 18 ofrece una experiencia de usuario similar a la de una aplicación nativa y permite que las aplicaciones hagan la transición entre diferentes entornos. React Router y Next.js tienen diferentes enfoques para el enrutamiento, con React Router utilizando enrutamiento basado en componentes y Next.js utilizando enrutamiento basado en el sistema de archivos. Los componentes de servidor de React proporcionan los primitivos para abordar las desventajas de las aplicaciones de múltiples páginas mientras se mantiene la misma experiencia de usuario. Mejorar la navegación y el enrutamiento en React implica incluir UI de carga, pre-renderizar partes de la pantalla y usar componentes de servidor para experiencias más eficientes. Next.js y Remix están avanzando hacia una solución convergente al combinar el enrutamiento basado en componentes con el enrutamiento basado en el sistema de archivos.
1. Introducción al enrutamiento en React 18
Hola a todos, soy Delba de Vercell. Hoy, quiero hablar sobre el enrutamiento en React 18 y cómo cambiará la forma en que los desarrolladores ven las aplicaciones. El enrutamiento ha evolucionado de las aplicaciones de varias páginas a las aplicaciones de una sola página. Las aplicaciones de una sola página brindan una experiencia de usuario similar a la de una aplicación nativa. El lado del cliente decide qué contenido buscar y renderizar. Las aplicaciones están haciendo la transición entre diferentes entornos, cliente o servidor.
♪♪ ♪♪ 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.
2. Resumen del enrutamiento en React
Y llamó a este tipo de aplicaciones aplicaciones transicionales. El enfoque de React Router para el enrutamiento es lo que me gusta llamar enrutamiento basado en componentes. Next.js adoptó un enfoque diferente para el enrutamiento utilizando enrutamiento basado en el sistema de archivos. El equipo de React nos dio un regalo de Navidad anticipado que nos permitirá avanzar hacia soluciones más híbridas.
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.
3. Enrutamiento con Componentes de Servidor de React
Eso fueron los componentes de servidor de React. Ahora tenemos las primitivas para abordar las desventajas de las aplicaciones de múltiples páginas manteniendo la misma experiencia de usuario. Propusimos un nuevo enrutador para Next.js que permite el enrutamiento, la renderización y la obtención de datos en el servidor. Con los componentes de servidor de React, podemos entrelazar componentes de cliente y servidor. Dividir las rutas en fragmentos independientes tiene tres beneficios principales: crear diseños, reducir la re-renderización y tener un control más granular sobre la obtención de datos. Al construir una nueva ruta con componentes de servidor de React, reducimos el código enviado al cliente, la carga de trabajo del servidor y el tiempo de carga. Combinar con características concurrentes simplifica los estados de carga y mejora la experiencia de navegación.
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.
4. Mejorando la Navegación y el Enrutamiento en React
Al usar la renderización del lado del servidor, es importante incluir una interfaz de usuario de carga para indicar el trabajo en segundo plano. La pre-renderización de una pequeña parte de la pantalla mejora la navegación al proporcionar retroalimentación inmediata. El almacenamiento de rutas permite restaurar el estado al navegar. Los componentes de servidor de React permiten experiencias más eficientes y fluidas. Crear experiencias compartibles sin romper las URL requiere convenciones simples para patrones de enrutamiento complejos. El equipo de React proporciona las primitivas para construir aplicaciones híbridas.
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í.
5. Next.js y Remix: Soluciones Convergentes
Next.js no está adaptando la visión de Remix, sino que se está moviendo hacia una solución convergente. Remix combina el enrutamiento basado en componentes con el enrutamiento del sistema de archivos para crear rutas anidadas. Este enfoque también se ve fuera del ecosistema de React. La industria se está moviendo hacia la combinación del enrutamiento basado en componentes con el enrutamiento del sistema de archivos, tomando prestadas ideas entre sí para mejoras incrementales.
Entonces, gracias por tu charla. Excelente información, por cierto. Vamos a saltar a la pregunta del público. La primera pregunta es de Martin. ¿Está Next.js adoptando la versión de Remix en el enrutamiento basado en componentes aquí? ¿Es lo mismo? Sí. Esa es una pregunta interesante. Entonces, cuando pienso en Remix y el trabajo que han hecho en React con el enrutamiento, han hecho un trabajo increíble. No hay duda sobre eso. Y si lo piensas, la mayoría de las aplicaciones usan React Router, que son de los creadores de Remix, como su columna vertebral. Ahora, cuando pienso en Remix en sí, no lo veo tanto como adaptando la visión de Remix como moviéndose hacia o convergiendo hacia una mejor solución. Entonces, lo que Remix ha hecho realmente bien es que han combinado la idea del enrutamiento basado en componentes con el enrutamiento del sistema de archivos y han creado rutas anidadas. Lo cual tiene sentido porque el enrutamiento del sistema de archivos es más fácil de implementar, pero luego con el enrutamiento basado en componentes, puedes mapear tus componentes a tu ruta URL. Creo que es un gran enfoque, pero también lo veo fuera del ecosistema de React, como por ejemplo con StealthKit. Entonces, creo que en general como industria, simplemente nos estamos moviendo hacia esa solución de combinar el enrutamiento basado en componentes con el enrutamiento del sistema de archivos. Y estamos tomando prestadas ideas, ¿verdad? ¿Perdón? Todos estamos tomando prestadas ideas entre nosotros e intentando mejorar todo el ecosistema. Mejoras incrementales. Siguiente pregunta de Anónimo. ¿Necesitas un React router conectado en un monorepo o puedes hacer todo con un React router? En realidad, nunca he usado un React router conectado antes, así que pido disculpas. Yo tampoco. No puedo responder tampoco. No, no puedo responder a esta pregunta. Muchas gracias. Si alguien quiere continuar la conversación con Delba, puede ir al stand del orador ahora mismo y ahora es el momento de un gran aplauso para Delba.
Comments