React 18: lazy-loading / useTransition

[NawarA]

What is the new or updated feature that you are suggesting?

Lazy loading routes is a common pattern.

Today, if users lazy load routes, they're forced to use a Suspense with a fallback, which causes a flash in their applications.

React 18 comes with useTransition which keeps the former UI static while a new UI is being prepared.

I'd like to request react-router adopt useTransition internally, so developers dont have to manually mark navigation events as transitions. Instead, react-router can automatically manage this internally, benefiting DX and UX.

Why should this feature be included?

Lazy loaded routes will no longer experience a "flash" or "glimmer" effect when they first mount. Meanwhile, apps that use lazy loading can still keep the benefits of code splitting.

[locchuong]

Currently trying to implement Lazy Loading myself... and running into this flickering issue. I've tried using useTransition myself, but having a hard time wrapping my head around it. Could you show me a code-snippet of what you mean by "manually mark navigation events as transitions"? It would help in the interim :)

[Nickman87]

The documentation for upgrading to v6 (https://reactrouter.com/docs/en/v6/upgrading/v5) specifies that react-router is now using useTransition, but it is nowhere to be found in the entire codebase? Is this just completely forgotten? I'm trying to implement lazy loading and data prefetching before showing the next page, but the only thing that seems to be working is the general lazy loading of react for components, falling back to the Suspense fallback component which makes the screen flicker.

I though by reading the documentation that react-router v6 already had full support for suspense and transitions, but it seems it does not?

[kiliman]

I believe that hook is going to be renamed to useNavigation to prevent confusion with React's useTransition.

https://beta.reactrouter.com/en/dev/hooks/use-navigation

[cxOrz]

Is there any code-snippets show how to implement lazy load without flickering? I'm a noob and facing the same problem using lazy load with react-router.

[bearsworth]

Is there any code-snippets show how to implement lazy load without flickering? I'm a noob and facing the same problem using lazy load with react-router.

I'm not sure if you are doing something similar to me, but for me the flicker is caused because the lazy load's fallback is a blank page. Because of this, there is a small time in which this page is loaded.

I need to work on something internally for this, but sorry I wish I had code for avoiding flicker.

It would be nice to make it so instead of falling back to a random react component of our choosing from suspense, we should instead stay on the currently rendered page until React.lazy is finished. Then once that has been lazy loaded, move to that route. In other words if 'null' is specified for the suspense fallback, stay on the currently rendered page until loading is finished, then move.

This feature really is needed.

[HanMoeHtet]

I have created a demo repo for solving this issue specifically - Route level code splitting in React without screen flickering.

1. I think it will be easier if there is a way to tell react-router-dom to use transition for a specific Route or Routes. In my demo, I just overrode Link component, but I think startTransition should be called before navigation happens that is inside the useLinkClickHandler function.

2. And with this concurrent mode, Events like onNavigationStart, onNavigationEnd should be re-added. Because we cannot handle them just by using component life cycles now. That is explained in README.md.

[Nickman87]

I've used your implementation @HanMoeHtet with some modification in my application and got good results from it.

I've gone a bit deeper and injected the transition code into the navigator as such:

  const { navigator } = React.useContext(UNSAFE_NavigationContext);

  useEffect(() => {
    // Overwrite the default navigator methods to support suspense
    const originalGo = navigator.go;
    const originalPush = navigator.push;
    const originalReplace = navigator.replace;

    const checkStartLoading = (to: number | To) => {
      if (typeof to === "number") {
        if (to !== 0) {
          startLoading();
        }
      } else {
        if (createPath(resolvePath(to)) !== createPath(window.location)) {
          startLoading();
        }
      }
    };

    navigator.go = (delta: number) => {
      checkStartLoading(delta);
      React.startTransition(() => {
        originalGo(delta);
      });
    };
    navigator.push = (to: To, state?: any) => {
      checkStartLoading(to);
      React.startTransition(() => {
        originalPush(to, state);
      });
    };
    navigator.replace = (to: To, state?: any) => {
      checkStartLoading(to);
      React.startTransition(() => {
        originalReplace(to, state);
      });
    };

    return () => {
      // Reset original methods
      navigator.go = originalGo;
      navigator.push = originalPush;
      navigator.replace = originalReplace;
    };
  }, [navigator]);

The startLoading method will trigger a loading animation after 200ms, somewhat the same as the progress component you are using. I'm using toprogress2 instead.

This startTransition call should be included by default in my opinion, or activatable by config for those that want to use it, wih possibly a callback before to trigger animations as we are doing now.

[SukkaW]

@Nickman87 @HanMoeHtet Thanks for your demonstration!

Here I am sharing some thoughts about the nested routes.

E.g.:

export const App = () => {
  return (
    <StrictMode>
      <BrowserRouter>
        <Routes>
          <Route path="/" element={<Layout />}>
            <Route index element={
              <Suspense fallback={<div>Loading...</div>}>
                <Home />
              </Suspense>
            } />
            <Route path="about" element={
              <Suspense fallback={<div>Loading...</div>}>
                <About />
              </Suspense>
            } />
            <Route path="*" element={
              <Suspense fallback={<div>Loading...</div>}>
                <NotFound />
              </Suspense>
            } />
          </Route>
        </Routes>
      </BrowserRouter>
    </StrictMode >
  );
};

The component <Home />, <About /> and <NotFound /> are nested inside <Layout />. And <Layout /> is included in the initial page load and shouldn't be included in the Suspense boundary. I only want a Suspense boundary for sub-routes components <Home />, <About /> and <NotFound /> only.

Currently, it is impossible for react-router to include <Suspense /> inside <Routes />. I am currently experimenting with wrapping Suspense outside of <Outlet />. I will update my post after I figure out something.

Update

You should wrap your <Suspense /> outside of <Outlet /> instead of <Route element /> when you are using nested layout/routes. Now all your sub-routes share the same Suspense boundary, and you could apply the approach mentioned by @Nickman87

[Asrover]

Here's temporary solution, which works great for me:

const useConcurrentLocation = (): Location & { isPending: boolean } => {
    const originalLocation = useLocation()
    const [location, setLocation] = useState(originalLocation)
    const [isPending, startTransition] = useTransition()

    useEffect(() => {
        if (location.pathname !== originalLocation.pathname || location.search !== originalLocation.search) {
            startTransition(() => {
                setLocation(originalLocation)
            })
        }
    }, [originalLocation.pathname, originalLocation.search])

    return {
        ...location,
        isPending,
    }
}

-------------

const location = useConcurrentLocation()

<App>
    {location.isPending && <LoadingBar />}
    <Routes location={location}>
        {/* Here're your routes  */}
    </Routes>
</App>

[NawarA]

Here's temporary solution, which works great for me:

const useConcurrentLocation = (): Location & { isPending: boolean } => {
    const originalLocation = useLocation()
    const [location, setLocation] = useState(originalLocation)
    const [isPending, startTransition] = useTransition()

    useEffect(() => {
        if (location.pathname !== originalLocation.pathname || location.search !== originalLocation.search) {
            startTransition(() => {
                setLocation(originalLocation)
            })
        }
    }, [originalLocation.pathname, originalLocation.search])

    return {
        ...location,
        isPending,
    }
}

-------------

const location = useConcurrentLocation()

<App>
    {location.isPending && <LoadingBar />}
    <Routes location={location}>
        {/* Here're your routes  */}
    </Routes>
</App>

This caused an infinite loop of remounting in my app :/ But it worked sometimes :)

[NawarA]

This modified version doesnt cause a stackoverflow and does the job for me...

function useConcurrentTransition() {
  const location = useLocation();
  const [oldLocation, setOldLocation] = useState(location);
  const [, startTransition] = useTransition();

  useEffect(() => {
    // if the path or search params change, mark this is a navigational transition
    setOldLocation(oldLocation =>
      oldLocation.pathname !== location.pathname ||
      oldLocation.search !== location.search
        ? location
        : oldLocation
    );
  }, [location]);

  useEffect(() => {
    // tell concurrent mode to pause UI rendering for a moment
    startTransition(() => {});
  }, [oldLocation]);

  return oldLocation;
}

const location = useConcurrentTransition()

<App>
    <Routes location={location}>
        {/* routes  */}
    </Routes>
</App>

Though this should be built into React-Router

[NawarA]

This modified version doesnt cause a stackoverflow and does the job for me...

function useConcurrentTransition() {
  const location = useLocation();
  const [oldLocation, setOldLocation] = useState(location);
  const [, startTransition] = useTransition();

  useEffect(() => {
    // if the path or search params change, mark this is a navigational transition
    setOldLocation(oldLocation =>
      oldLocation.pathname !== location.pathname ||
      oldLocation.search !== location.search
        ? location
        : oldLocation
    );
  }, [location]);

  useEffect(() => {
    // tell concurrent mode to pause UI rendering for a moment
    startTransition(() => {});
  }, [oldLocation]);

  return oldLocation;
}

const location = useConcurrentTransition()

<App>
    <Routes location={location}>
        {/* routes  */}
    </Routes>
</App>

Though this should be built into React-Router

This no longer works with 6.4.0, if you use createBrowserRouter lol

An official solution would be lovely :)

[bigfarts]

https://gist.github.com/bigfarts/b8c4f850444e8be84924d68f01d7949a here's an implementation of a createBrowserRouter-compatible RouterProvider that uses useTransition (but a lot of unsafe internals).

[mnlfischer]

Would be great if we can use a promise as the route element and get the loading state via useNavigation hook when the promise is resolved. Feel free to improve the idea.
element: () => import('./routes/superroute').then((res) => <res.superroute />)

[Yama-Tomo]

I think we need to have a custom router and execute useTransition in the callback of history.listen

I have created a sample repository

[brophdawg11]

I'm going to convert this to a discussion so it can go through our new Open Development process. Please upvote the new Proposal if you'd like to see this considered!

[Haraldson]

So there are no official React Router patterns or built-ins for such a common use case?

[brophdawg11]

The work for #9826 (PR #10045) is about to land which will provide first-class support for lazy-loading non-path-matching portions of the route definition (loader, action, element, errorElement, shouldRevalidate, handle):

// app.jsx
const routes = [{
  path: '/',
  lazy: () => import("./route"),
}];

export default function App() {
  return <RouterProvider router={router} />
}

// route.jsx
export async function loader() { .. }

function Component() { .. }

export const element = <Component />;

That will cover about half of this proposal, but it'll still remain open for addition of startTransition internally

[ivyrze]

If anyone is still looking for this, it's available with a future flag:

<BrowserRouter future={{ v7_startTransition: true }}>
  <Routes>{/*...*/}</Routes>
</BrowserRouter>

[C5H8NNaO4]

I enabled this but my Route still suspends when React hydrates the page and fetches the route. How can I keep my server side rendered html until the page has been hydrated? At the moment this causes the Suspense fallback to show once hydration completed.

[brophdawg11]

I think this section might be what you're looking for. In order for your app to hydrate client side you need to have access to the SSR'd routes so you have the Components required to render them: https://reactrouter.com/en/main/guides/ssr#lazy-routes. In Remix, we don't use route.lazy for the critical path (SSR'd routes) since we include them in <script> tags so they are already available ready and we can create the route directly without route.lazy - but that approach takes a bit more compiler/SSR work.

[C5H8NNaO4]

Thanks a lot for taking the time to provide insights. I figured that's one optimization I might use to circumvent this issue but it takes effort to implement. As I see it, you don't need to include the code for the route in the SSR html. By leaving it out you are decreasing TTFB, and maybe FCP and LCP in a tradeoff for a slightly delayed TTI. In my mind it should work fine if the route suspends during lazy loading but simply keeps the server rendered html until it loaded the route. This should be possible in React 18 using startTransition. I think a solution in this direction would be a bit simpler and doesn't involve complicated injection of components during SSR and logic to switch between lazy loaded routes for client side navigation and hard imported components for critical paths.

I see how this is a viable solution but I'd actually prefer to take the TTI hit and have the component lazy load while keeping SSR html by using startTransition within react router. This would allow me to dodge all sorts of implementation around this logic and kind of makes sense from a data flow and lifecycle perspective when you use renderToPipeable stream and partial hydration,

[brophdawg11]

By leaving it out you are decreasing TTFB

Including a <script> tag for the critical routes shouldn't have any impact on TTFB/FCP/LCP. It should have a positive impact on TTI since it allows you to start downloading the script sooner versus waiting for all of the other JS to download, parse, execute, and then find the route.lazy definitions and issue an HTTP request for them.

As I see it, you don't need to include the code for the route in the SSR html

I agree - the linked approach to load the lazy matches is the way to load those routes prior to hydration if you don't want to put them in <script> tags.

In my mind it should work fine if the route suspends during lazy loading but simply keeps the server rendered html until it loaded the route

I agree there is probably a way to make this initial route.lazy work by throwing to a startTransition wrapper - but at the moment it's not super high on the roadmap given everything else we have in the works. If you'd be interested in looking into a POC I'd be happy to take a look - but the linked ~10 LOC is a fine workaround for now IMO.

[C5H8NNaO4]

I agree. I'm not sure what I meant when I wrote that. Including the bundled route in the server html should not increase the server response time by much.

Thanks a lot. I will follow the guide you linked. Maybe react-router v7 will have this baked in, but for now this seems like a good solution.