Video details

Routing in React 18 and Beyond – Delba de Oliveira, React Summit 2022


React Summit 2022 #ReactSummit #GitNation Website –
Follow the link to watch the full version of all the conference talks, QnA’s with speakers and hands-on workshop recordings →
Talk: Routing in React 18 and Beyond In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
This event would not take place without the support of sponsors:
🏆 Platinum Sponsors Ag Grid → Toptal → →
WPEngine → Vodafone →
🥇 Gold Sponsors StackHawk → Bitvavo → Ionic → JetBrains → Kontent by Kentico → Decentology → Xata → Docker → Shopify → Wix Engineering → NearForm → Focus Reactive → Sanity → Snyk → Contentful → Nx →
🥈 Silver Sponsors Firebase → Callstack → Mercari → vpTech/ → NativeBase → Stream → SiteGround → Yoast → Novermber Five → Twilio → BCGDV → Fullscript → Utopia Music → SISU →


Hey everyone. I'm Delva and I work for Versailles. As some of you may know, we're the creators of next year. And I'm curious to know how many of you here use or have used is Next JS? Wow. So that's a lot of you. That's amazing. So although we create Next JS, we also have a platform for sale. And funnily enough, Versailles supports over, I think, something like 35 plus front end frameworks. So even if you don't use an XJS, you could still use Versailles. And today I want to talk to you about some exciting stuff we have been working on, which is routing and routing in React 18. Now, as you may know, a few months ago, Reacting team was released with new concurrent features. And on the React blog, the team mentions that they expect concurrent features to have a big impact on the way that developers viewed applications. So today I want to discuss with you what this impact could mean and how we will change how developers viewed applications, especially with React several components as well. And this may not also change things for Next JS, but also for those frameworks and library maintainers. And I'm going to specifically look at routing, but I will also mention data fetching and rendering, or as I like to call them, the three pillars of the web, because those terms are very much interconnected. Now, to give everyone here some context, and also the people who might be watching online, I think it's important to just take a step back and look how routing has evolved in front end applications. Now, please note, I'm going to be condensing years of routing history in like five minutes. So there's a lot more nuance. And one way we can look at routing is through the type of applications we can build multi page applications, single page applications, and more recently, hybrid apps. So in the very early web browser was very straightforward because if you think about it, each URL mapped to a specific file on a server. And then later on, using dynamic server side languages, we were able to generate a response from the server for specific routes. In a traditional multi page application, routing is done on the server, and navigating between pages causes the full page reload that we're all very used to. Now, when native mobile apps came along, they bought smoother transitions and new UI patterns and single page applications. You could say whether the web response to native apps, we wanted our website to feel like native apps. That is to say, we wanted them to have the same user experience as native apps. And in a traditional single page application, routing is done on the client side. So on the initial load, you may see a white blank screen while the client side fetches and renders the content. Now, when you navigate on a single page application, the client will dynamically rewrite new content and for a given route, the client is deciding what content to fetch and render. Last year, Rich Harris, the creator of Self, gave an amazing talk on the whole NPA versus SBA debate, where he discussed some of the pros and cons of each. It's a really great talk and I recommend watching it if you haven't had a chance to do already. But one takeaway from that talk that I want you to remember is that he recognized that there's an emerging pattern in our industry where applications are transitioning between different environments, client or server. And he called those type of applications Transitional Apps and Transitional Apps. They try to combine the benefits of both the client and the server. Because if you think about it, why not both? So that's kind of like a broad overview of routing on the web. Now let's zoom in to React. While React didn't invent single page applications, you could argue that it contributed to their popularity. The fact that React was and still is mainly concerned with UI and rendering means that the community has come up with a few different solutions for routing. And one client side solution that quickly rose to popularity was React router. Now, how many of you have used React router before? Yes. So React Router's approach to routing is what I like to call component based routing, where you use code to map specific components in your application to your URL path. And if you combine it with a tool chain like Create React app sorry, Create React app, then you can easily create single page applications. And this led to, I think, not just the adoption of React itself, but also applications that were fully client side rendered. Now in 2016, a few years later, this now introduced NextJS. And Next JS was created as a framework to help developers build server side rendered applications. And actually as took a different approach to routing. He used what I like to call file system based routing, where files in your application mapped to your URL. And although next year felt very similar to a motivated application, it actually used free fetching and client side application to give applications a spa like feel, if you could say. Now, another incremental step towards hybrid apps was the next year as data fetching methods like Get initial props. And what these fetching methods did was move the fetching outside of your rendering code or outside of your component so that you could fetch data both from the client and the server. Now, I'm focusing on XS today, but it would be remiss of me not to acknowledge some projects that are also working on routing solutions for React, including Shopify, Hydrogen, Remix, and also Redwood. So fast forward a few years in early 2020, and the members of the React team were publicly discussing moving more rendering work to the server. The idea was that if we are doing data fetching on the server anyway, could we move some rendering work to the server and therefore reduce the amount of code that gets sent to the client. Now, you can probably imagine the hot takes that follow that tweet. I think it can be best summarized as this looks a lot like service added routing. Are we going back to MPAs? But to quote a not so serious meme from one of my favorite people on Twitter, this is less of a pendulum swing and more a spiral of incremental improvement. So switchbacks not purely spa, not purely MPA, but a convergence towards hybrids that benefit from both the server and the client. And each time this conversation was brought up, the reaction was careful to emphasize that they were looking for a hybrid solution. And one important thing to note here is that this hybrid solution wouldn't be creating additional requests to the server. It would take advantage of a request that has to exist anyways. So in December 2020, the React team gave us an early Christmas present that will allow us to move towards more hybrid solutions. That was React Server Components. When you combine React Server components with Suspense and the streaming, we now have the primitive or the building blocks to address some disadvantages of multi page applications or service side rendered applications, while maintaining the same user experience we love about single page applications or client side applications. But there is one last piece to the puzzle, and in the last few months, the Next JS team has been considering this if we need to go to the server to do a trip for data fetching, and now we're going to the server to do rendering with React Server component, could we possibly also do routing on the server? Could we enable developers to build applications where routing, rendering and data fetching happens, where it makes more sense? And could we give them conventions that are easy to understand, but also allow them to move parts of their application either to the client or to the server? So a few weeks ago, we shared an RSC, and in this RSC we proposed a new router for NextJS. And this new router built on top of React server components and Reactivating features. There's a lot more detail in the RSC, and I won't go too much into the implementation details. If you're curious to know more about it, I do recommend reading it. But for now, let me just share with you something that I'm most excited about and that we've been working on. So if you think about it, with React Server Components, we can interweave client components and server components in a tree. This means that in a page or a route, you could potentially have both clients and server components. So with this new model, it becomes increasingly important to break up our routes into independent fragments, which we call route segments. In this route segments, they map to an already existing term, URL segments. And although we are breaking up the routes we want to maintain file system routing because generally it tends to be a more intuitive way for developers to define their routes. And breaking up the routes like this, or as we call it, doing nested routing has three main benefits. The first one is that we are able to create layouts. And layouts has been a very long going back community ask. And the way that we want to define layouts is that a layout is UI that is shared across routes. And these layouts, they shouldn't rerender or lose state on navigation. It also means that for components that don't change within a route so a layout, we also want to make sure that they're still interactive as the user navigate between routes. Secondly, if we combine it with several components, that means that on navigation, the server only has to fetch and render the segments that have changed and we don't have to rerender the whole subtree for that route. And thirdly, we can have more granular control over data fetching. So in XCS, as you may know, currently we fetch data on the page level and with this new model, we can fetch data in the segment level. And since we already moved data fetching outside of the rendering code or outside of the components, what we can do now is we can easily initiate those requests in parallel. And this reduces what some of you may be familiar with, which is waterfalls. And overall, the amount of time that it takes to load the content of a route is also reduced. So by building a new router with react several components, we're able to achieve three things reduce the amount of code that we send to the client, reduce the amount of work the server has to do, and also reduce the amount of time that it takes to do that work. Now, if we were to combine it with concurrent features such as transition, suspends and the future offscreen component, we can simplify the creation of loading state and improve the navigation experience. For example, if you want to use client side routing and you are fetching as you render, you may have too many targets, loading dates or spinners. So really what you want to do as a developer is consolidate them into fewer, more meaningful loading indicators. On the other hand, if you are using server side rendering, you have to fetch and render the content before navigation starts. So your application will appear on responses as the work is being done on the server. So in that case, you do want to include loading UI to indicate that work is being done in the background. In either case, we believe the framework should provide an easy convention that will allow developers to create loading states. Now, we can also improve the navigation experience further by pre rendering a very small but minimal part of your screen. So this means that when you navigate between screens, the navigation will be immediate and the user might see something like a cover photo or title before or the rest of the content loads and in a similar fashion. And this one is one of my favorites, is that we will be able to stash routes. And what that means is that we can stop the previous route and then pre render future routes so that when the user navigates between the routes, we restore the state. Now I'm running a little bit out of time so I'm just going to skip these two slides. But if you do want to find out more, we do have more information in the IRC. What I wanted to highlight here today is that there are many ways you can think about routing in react and we have been thinking a lot about how we do routing in actually it's not about routing itself, but it's what routing will enable us to do. So we'll be able to create more performance experiences with react server components and also smoother experiences by improving navigation. We also want to make sure that we create experiences that are shareable, they don't break the URL. And to do that, we need to create simple conventions that will allow developers to implement more complex browsing passes. So last but not least, before my time is up, I want to take a moment to solution. Give a shout out to the React team because they're the ones giving us the primitives and the building blocks for us to be able to build the next generation of hybrid applications. Thank you so much.