Move data fetching into React Router loaders to avoid render waterfalls

Navigating to a detail page shows the layout first, then a spinner, then content. The parent layout stays mounted but the child fetches again, and a form submit triggers a manual refetch. That timing gap is the problem data routers in React Router v6.4+ are designed to remove.

The useful takeaway: define data requirements on the route with a loader and mutations with an action, and let the router fetch before the element renders. The component receives data via useLoaderData instead of triggering its own effect.

The timing problem with component-level fetching

In the classic component model, a route element mounts and then useEffect starts a fetch. The UI renders once empty, then again with data. With nested layouts, the parent renders while the child is still loading, which creates visible flicker and duplicate requests on back-forward navigation.

Loaders invert that order. A loader is a function attached to a route that the router calls before rendering the route element. It can return data, throw a Response for error handling, or return a redirect. Actions handle mutations for a route, typically form submissions, and can redirect or trigger revalidation of loaders.

Data routers and the supported entry point

Data routers are the router implementation that supports loaders and actions. The supported browser entry point is createBrowserRouter with RouterProvider. Routes are plain objects with path, loader, action, element and children.

Nested routing uses a layout route with an Outlet. Outlet is a placeholder where child routes render inside the parent element. Parent loaders run for the parent and children, and the router can run sibling loaders in parallel before committing a navigation.

Version assumption: loaders and actions are stable in the v6.4+ line. API surface and defaults have changed across v6 minors. Verify availability in your installed version by checking exports for createBrowserRouter, RouterProvider, useLoaderData and Outlet.

Worked example: layout with a loader and an action

The following is a minimal route configuration you can adapt. It shows a root layout that persists across pages, a projects list with a loader, and a project detail with its own loader and a mutation action.

// main.jsx
import {
  createBrowserRouter,
  RouterProvider,
  redirect
} from 'react-router-dom';

const router = createBrowserRouter([
  {
    path: '/',
    element: <RootLayout />,
    loader: async () => {
      // example: fetch user session once for the layout
      return { user: { name: 'Ada' } };
    },
    children: [
      { index: true, element: <Home /> },
      {
        path: 'projects',
        element: <ProjectsLayout />,
        loader: async () => {
          // replace with real fetch
          return { projects: [] };
        },
        children: [
          { index: true, element: <ProjectsList /> },
          {
            path: ':id',
            element: <ProjectDetail />,
            loader: async ({ params }) => {
              // params.id is available here
              return { project: null };
            },
            action: async ({ request, params }) => {
              const formData = await request.formData();
              // perform mutation, e.g., update project
              // redirect triggers loader revalidation
              return redirect(`/projects/${params.id}`);
            }
          }
        ]
      }
    ]
  },
  { path: '*', element: <NotFound /> }
]);

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

In the detail component you consume data without an effect:

import { useLoaderData, Form } from 'react-router-dom';

function ProjectDetail() {
  const { project } = useLoaderData();
  return (
    <div>
      <h1>{project?.name}</h1>
      <Form method='post'>
        <button type='submit'>Save</button>
      </Form>
    </div>
  );
}

Practical check: create a minimal route tree with a parent layout and a child route whose loader returns static data. Observe that the child element does not render until the loader resolves, and useLoaderData provides the value without useEffect.

Trade-off: explicit revalidation and error boundaries

Moving fetching into the router makes data dependencies explicit, but it also makes them explicit to maintain. Loaders run on navigation and on revalidation after an action. That can increase perceived complexity for simple apps that previously used a single useEffect.

Error handling is per route. Throwing a Response in a loader is caught by the nearest errorElement. If you do not provide error boundaries, errors surface as unhandled rejections. Server-side rendering and streaming require additional setup beyond createBrowserRouter and do not behave identically to the browser router.

Do not assume identical behavior across createBrowserRouter, createMemoryRouter and createHashRouter. Test form submission with an action that returns a redirect and verify that loaders re-run as expected after the mutation.

Actionable next step: pick one route with a visible waterfall and move its fetch into a loader. Keep the component rendering logic unchanged except for replacing the effect with useLoaderData. Add an errorElement for that route and observe navigation timing. If the route is simple and rarely changes, component-level fetching may still be appropriate.