🗺️ Client side router context

[brophdawg11]

Discussed in #9856

^{Originally posted by jamesopstad September 22, 2022}

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

It would be useful to be able to set a context value when initialising the router that can then be accessed in loaders and actions.

Example

// main.jsx
const queryClient = new QueryClient();

const router = createBrowserRouter(
  [
    {
      path: '/',
      element: <Root />,
      loader: rootLoader
    }
  ],
  {
    context: {
      queryClient
    }
  }
);

// root.jsx
export async function loader({ params }, context) {
  return await context.queryClient.fetchQuery(query);
}

Why should this feature be included?

As loaders and actions cannot use React hooks, there is currently no way to access contextual data within them. A workaround suggested in this article (https://tkdodo.eu/blog/react-query-meets-react-router) is to create an additional function wrapper for each loader and action. Providing a context value directly when initialising the router would be a more elegant solution.

[koen-dev]

I’d really love to see this feature happen. We’re currently using the workaround described by Dominik in his blog post, which works but has some downsides. Specifically, we need to export a function that returns an async function in order to inject the queryClient, like this:

// pages/overview.tsx

export const customLoader = (queryClient: QueryClient) => async () => ({
    borderFilterPrediction: queryClient.ensureQueryData(
        borderFilterPredictionQuery,
    ),
    filterArrivalFlights: queryClient.ensureQueryData(
        filterArrivalFlightsQuery,
    ),
});

And then we call it like this when defining the routes:

// Routes.tsx
children: [
    {
        lazy: () => import('./pages/overview'),
        loader: async () =>
            overviewLoader(
                hostQueryClient ?? isolatedQueryClient,
            ),
        path: 'overview',
    },
],

This pattern works well for us, especially in our micro-frontend setup where we sometimes run the MFE standalone during development. In those cases, we fall back to using a "local" queryClient. But when running inside the host, we inject the host’s queryClient and share it via this pattern.

It would be significantly simpler and cleaner if we could access the queryClient via context. That way, we could just check if it’s present in the context and only create our own if it isn’t, making both host and standalone usage smoother.

I’m curious how this would align with the existing context and middleware model in React Router. Perhaps slightly different naming would help clarify intent, but overall, this would be a very welcome addition. Thanks for considering it!

[brophdawg11]

This is actually already shipped in an unstable format as it was a prerequisite for client-side middleware, but it's not really documented anywhere yet. I created this issue yesterday just for better visibility on our end of things that are currently in progress/unstable. We effectively have a client-side version of getLoadContext now.

We'd love some beta testers if you're interested! You should be able to do something like the following:

let myContext = unstable_createContext<MyType>();

function getContext() {
  let myValue: MyType = getValue();
  return new Map([[myContext, myValue]]);    
}

<RouterProvider unstable_getContext={getContext} />

// then in your loaders
function loader({ request, context }) {
  console.log(context.get(myContext));
}

As a note, this API is likely to change slightly in the near future based on this discussion so pretty soon you will probably just return a RouterContextProvider instance directly from the client side getContext method, so it'll change to this:

function getContext() {
  let myValue: MyType = getValue();
  return new unstable_RouterContextProvider(
    new Map([[myContext, myValue]])
  );    
}

[koen-dev]

@brophdawg11 I’ve been testing this feature and it works great overall. However, I’ve run into one issue that is blocking me from using it in production once it is stable. When using patchRoutesOnNavigation, the context is not available in the patched routes. Specifically, whenever I try to access it with context.get(myContext), the new routes fail to patch without any errors explaining why this happens.

Edit:

It looks like this is related to the combination of Module Federation and React Router Context.