Router Context (from hooks)

[jamesopstad]

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.

[brophdawg11]

@jamesopstad Thanks for the request! This is definitely something on our radar and we've got a few APIs in mind that we're discussing internally. I'll update this issue as we have any more concrete information 👍

[filiptammergard]

Hey @brophdawg11! I think this might be a related problem:

What are you supposed to do when you have a provider, say <AuthProvider> that needs to live inside a router? It was simple with <BrowserRouter>:

ReactDOM.createRoot(document.getElementById("root")).render(
  <BrowserRouter>
    <AuthProvider>
      <App />
    </AuthProvider>
  </BrowserRouter>
);

But not sure what the equivalent would be using v6.4 data APIs. This is not possible, since <AuthProvider> needs to live inside of a router:

const router = createBrowserRouter(
  createRoutesFromElements(<Route path="/" element={<Root />} />),
);

ReactDOM.createRoot(document.getElementById("root")).render(
  <AuthProvider>
    <RouterProvider router={router} />
  </AuthProvider>
);

This is not possible, since <AuthProvider> is not a <Route> component:

const router = createBrowserRouter(
  createRoutesFromElements(
    <AuthProvider>
      <Route path="/" element={<Root />} />
    </AuthProvider>,
  ),
);

ReactDOM.createRoot(document.getElementById("root")).render(
  <RouterProvider router={router} />
);

This is possible:

const router = createBrowserRouter(
  createRoutesFromElements(
    <Route
      path="/"
      element={
        <AuthProvider>
          <Root />
        </AuthProvider>
      }
    />,
  ),
);

ReactDOM.createRoot(document.getElementById("root")).render(
  <RouterProvider router={router} />
);

But that would require wrapping <AuthProvider> on all top-level routes...

Any suggestions?

[timdorr]

Just use a pathless Route (with Outlet inside of AuthProvider):

const router = createBrowserRouter(
  createRoutesFromElements(
    <Route element={<AuthProvider />}>
      <Route path="/" element={<Root />} />
      {/* More Routes here... */}
    </Route>
  )
)

[filiptammergard]

Just use a pathless Route (with Outlet inside of AuthProvider):

const router = createBrowserRouter(

  createRoutesFromElements(

    <Route element={<AuthProvider />}>

      <Route path="/" element={<Root />} />

      {/* More Routes here... */}

    </Route>

  )

)

Easy as that! Thanks!

[cjam]

I've been test driving the new data loading apis, and I like the concept but in practice I'm finding it challenging to integrate with. It feels like a feature like this might help. The use case is simple. I've got an api that uses JWT auth. What's the best way to pass the current access token (and dealing with updating it etc) into a loader. The loaders are more or less pure functions it seems. The only example I see around auth, doesn't use the createBrowserRouter api.

Maybe there's a way to do it, but wasn't clear through my investigation this morning. For a bit more context. I'm currently using the msal / msal-react library which uses a context for providing auth type concerns.

My ideal scenario would be to be able to provide/update the access token that can be used by the data loaders for accessing protected data.

Interested to see / hear about what new api's might be in the works for the data loading side.
I wonder if this context would make sense sitting as a prop on the RouterProvider which could re-execute loaders on change. The createBrowserRouter function seems like it sits at a decidedly imperative place in the api, which makes sense since it needs to be able to know about all of the data loaders before the routes have actually been loaded.

[slowWriting]

@timdorr I tried your option, it only works fine, when you click around the site, but when I hit refresh, or enter direct page, the loader always crashes, since msalInstance is not initialised yet.

[jordanthornquest]

While this feature is being considered, I'd like to add that it'd be useful to provide a mechanism for passing values from hooks into loaders and actions.

As it stands, Auth0's React SDK library only allows token values to be accessed via the getAccessTokenSilently() function, which is provided by the useAuth0() hook. Auth0 currently doesn't provide a mechanism for getting a client instance, like with React Query's new QueryClient().

[kevinpruett-prime]

@jordanthornquest I'm running into similar issues. Have you found a nice solution to this issue?

[lukebelliveau]

+1. I'd really like to migrate my app to Remix (or at least react-router 6.4), but I use custom Hooks to fetch all of my data. These Hooks use an apiRequest function from a React context SessionProvider - this is a wrapper around Axios that adds session-specific query params and headers to every request, and updates the session context afterwards. For example:

export const useGetUser = async (id: string) => {
  const { apiRequest } = useSession();
  return await apiRequest({
    path: `identity/user/${id}`,
    method: "GET",
  })
};

I can't call these inside a loader. The best I can do is wrap them in Tanstack Query, and use the workaround mentioned by the OP here. Not ideal.

Because the session is stored inside of React context, the solution proposed in the OP isn't quite right for me either. In a perfect world, I could do something like this:

// App.tsx
const App = () => {
  <SessionProvider>
    {(sessionContext) => (
      <RouterProvider context={{ sessionContext }}/>
    )}
  </SessionProvider>
}

and my loader could look like this:

// User.tsx
export const loader = async ({ params }, context) => {
  const { apiRequest } = context.sessionContext
  return apiRequest({
    path: `identity/user/${id}`,
    method: "GET",
  })
}

Am I missing any workarounds? Would love some pointers if I'm going about this the wrong way.

[j-bullard]

I would like to see some type of official context api added as well. Here is what I'm currently doing to ensure my loaders and actions have access to the firebase services. It would be great to remove the (args) => DashboardLoader({ ...args, context }) line and have context passed in.

import { LoaderFunctionArgs, ActionFunctionArgs } from "react-router-dom"

declare module "react-router-dom" {
  interface LoaderFunctionArgs {
    context: IFirebaseContext
  }

  interface ActionFunctionArgs {
    context: IFirebaseContext
  }
}

import AppShell from "@components/AppShell"
import Loader from "@components/Loader"
import { ROUTES } from "@constants"
import { useFirebase } from "@Firebase"
import DashboardRoute, { DashboardLoader } from "@routes/dashboard"
import { createBrowserRouter, Navigate, RouterProvider } from "react-router-dom"

export const AppRouter = () => {
  const { loading, ...context } = useFirebase()

  // Wait for auth to finish loading
  if (loading) {
    return <Loader />
  }

  return (
    <>
      <RouterProvider
        router={createBrowserRouter([
          {
            element: <AppShell />,
            children: [
              {
                index: true,
                path: ROUTES.Dashboard.slug,
                element: <DashboardRoute />,
                loader: (args) => DashboardLoader({ ...args, context }),
              },
            ],
          },

          {
            path: "*",
            element: <Navigate to={ROUTES.Dashboard.path} />,
          },
        ])}
      />
    </>
  )
}

export default AppRouter

[brophdawg11]

There's a context concept in #9564, but it won't currently suffice for passing data from a react context through. So 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!

Generally speaking though - we don't want React Context to be a dependency for data fetching - since the entire idea of the 6.4 data APIs is to decouple data fetching from rendering. In order to access client side data from a react context, it has to be handed off to a context provider somewhere higher up in the tree and by definition is then accessible from JS somehow. The solution is then to access that data from the source in JS, and not from context. But not all third party APIs currently give you easy access to some of this stuff in a non-context manner.

[titenis]

For example if actions are completely decoupled from rendering, how do you do specific navigation on action success? For example I want to navigate to login route and pass current pathname as a state:

const navigate = useNavigate();
const { pathname } = useLocation();
navigate(LOGIN_ROUTE, { state: { path: pathname } });

With actions I cannot do that unless I pass all this data through FormData, which is imo redundant because it is not sent to API

[Louis-Tian]

My use case is a multi-tenacy application where the subdomain is used to encode the workspace name. But the api endpoint for assets within a workspace requies the workspace's id not name.

A layout component will parse the subdomain from the url and fetch the id and other configuration from the api server. Those information are kept in the layout's state and passed down to descendant components passed down via context. The nested routes will then need access the workspaces id in order to fetch to correct call to the API server.

export default createBrowserRouter([
  {
    element: <AppLayout />, // here we parse the subdomain and query the api for workspace id and config
    children: [
          {
            path: '/page/:id',
            element: <Page />,
            loader: ({ params }, context) => {
                fetch(`/page?id={params.id}&workspace={context.workspace.id}`)
            }
          },
     ],
  }
]);

I think you are quite right if we modify the workspace name in the state then it will be out of sync with the subdomain so they should never mutates. I guess my initally question is ill formulated.

Neverthless I think the need to be able to access context in the loader function is still valid.

Perhaps, a better question I should ask is how to pass information from a higher route to a nested route's loader function?

[Louis-Tian]

For example if actions are completely decoupled from rendering, how do you do specific navigation on action success? For example I want to navigate to login route and pass current pathname as a state:

const navigate = useNavigate();
const { pathname } = useLocation();
navigate(LOGIN_ROUTE, { state: { path: pathname } });

With actions I cannot do that unless I pass all this data through FormData, which is imo redundant because it is not sent to API

@titenis I think the standard approach to your problem, is to encode current pathname as a query parameter to the URL.

For example,

const navigate = useNavigate();
const { pathname } = useLocation();
navigate(`${LOGIN_ROUTE}?redirect=${pathname}`);

[brophdawg11]

Perhaps, a better question I should ask is how to pass information from a higher route to a nested route's loader function?

@Louis-Tian Ah - yeah this is much clearer and this is exactly what the middleware proposal is intended to address via the "Sharing Data" section. Instead of fetching the subdomain config in AppLayout (remember we want to decouple fetching from rendering) - you would instead fetch the config in a middleware and it would be available to child loaders/actions. Then you'd leverage some form of client-side cache to avoid re-fetching on subsequent navigations.

[brophdawg11]

With actions I cannot do that unless I pass all this data through FormData

@titenis I see this as a feature, otherwise the action becomes impure and relies on external global state. It's a very common pattern to render the current location into a hidden input this keeping the action a pure function that only operates on the incoming request.

In a RouterProvider SPA you also own the global singleton router, so you could access router.state.location in your actions to grab the current location if you wanted to avoid passing the location through FormData: https://codesandbox.io/s/zealous-boyd-l2jh6j?file=/src/index.js

[ghost]

hey, is this feature already exist? i see that react-router passing { params, request, context } to loader function. but i dont understand how to set this context.

[juanpmarin]

@1337supercoder did you figure it out?

[drewdeal]

that is exactly what brought me here today!
I don't see any evidence of that being released, but have also seen that prop and I've been trying to light it up!

[brophdawg11]

The context for loaders/actions is only for SSR - see https://reactrouter.com/en/main/routers/create-static-handler#optsrequestcontext. It is primarily a bridge to pass information from your SSR server (I.e., express req.*) to your Remix loaders/actions.

This is not available client-side at the moment since generally a module-scoped singleton can be imported and used directly.

import clientSideSingleton from "./something";

const routes = [{
  path: '/',
  loader() {
    let thing = await clientSideSingleton.getThing();
    ...
  }
}];

Eventually I think the middleware proposal should provide this type of context for both SSR and CSR

[HazyFish]

My use case is Firebase Authentication. auth.currentUser will always be null for initial page load regardless of whether the user has signed in or not, and the recommended way is to use auth.onAuthStateChanged.

In my React app, I created a context so every component using the user will be re-rendered when user is loaded, signed in, or signed out.

I cannot find a way to implement this without context.

const UserContext = createContext<User | null | undefined>(undefined);

export const UserContextProvider: React.FC<{ children: ReactNode }> = props => {
  const [user, setUser] = useState<User | null>();

  useEffect(() => {
    return auth.onAuthStateChanged(setUser);
  }, []);

  return (
    <UserContext.Provider value={user}>{props.children}</UserContext.Provider>
  );
};

/**
 * Get the current Firebase user.
 * @returns a `User` if the user is signed in, `null` if the user it not signed in,
 * or `undefined` if we're working on getting it or if `UserContext` is not provided.
 */
export function useUser(): User | null | undefined {
  return useContext(UserContext);
}

[brophdawg11]

We've recently added an example of how to manage auth in a RouterProvider application: https://github.com/remix-run/react-router/tree/main/examples/auth-router-provider

Here's an example repo I created showing how to use it with auth0: https://github.com/brophdawg11/react-router-auth0-example

[HazyFish]

I think your solution won't log out the user on all tabs reactively when the user triggers the sign out on one tab. Is there a way to trigger a logout action / redirect inside a callback like the auth.onAuthStateChanged outside both React and router?

[buzinas]

Wouldn't useSyncExternalStore be better suited for this?

const subscribe = () => auth.onAuthStateChanged()
const getSnapshot = () => auth.currentUser

export function useUser() {
  return useSyncExternalStore(subscribe, getSnapshot)
}

[HazyFish]

You're right. That's a better solution compared to mine, but it does not eliminate the need for router to access context (here it does not specifically mean React context API but any stateful value returned by a React hook). The value will still be null for initial page load regardless of whether the user has signed in or not.

[HammadAwan424]

@HazyFish This is what worked for me:

async function myLoader() {
    let unsubscribe;
    return new Promise((res, rej) => {
        unsubscribe = onAuthStateChanged(auth, (user) => {
            if (user) {
                res(user)
            } else {
                rej("User is not signed in")
            }
        })
    })
    .catch(err => {
        return "Have to return something lest You will get the error --You defined a loader for route but didn't return--"
    }).finally(unsubscribe)
}

[marbemac]

I don't quite understand what the issue is with the original poster's suggested solution? It unifies the behavior between the static / server router, and the client router, so that we can have isomorphic loaders that don't need to care which environment they're running in. In react-query use case, on the server the client needs to be created per request and passed in (can't do singleton), while in the client entry we can create a singleton pass that in to the browser router's loader context.

I've seen a lot of posts mentioning that we don't want to rely on react context, and want data fetching and rendering to be separated. I agree! ... however, how does the original poster's solution not satisfy these two key concerns? React context is not involved, nor is rendering.

[marbemac]

I opened a PR with an example implementation -> #10895.

[peteruithoven]

Can someone clarify whether #9564 or remix-run/remix#7645 would enable using (the result of) the same hooks we use elsewhere inside our loaders?

I frequently use hooks for retrieving query parameters (with some post processing for defaults etc), but I then need to add a lot of complexity to also make this work inside loaders.

(A big part of this is probably caused by React router not treating query parameters as a first class citizen)

[charliematters]

By "hooks" do you mean react hooks like useState etc...?

[peteruithoven]

Yeah indeed, but usually custom hooks that in turn use things like useSearchParams (to re-use my search param processing logic) or maybe a Zustand store hook.

[charliematters]

I'll leave the answer to people more qualified than me, but I'm confident that you will never be able to run react hooks inside loaders directly. That's not to say you can't extract common logic which applies both in react land and loader land.

Note that the search params returned from useSearchParams is the same as the one returned by doing this in a loader: const { searchParams } = new URL(request.url)

[peteruithoven]

Yes sure, but then I have to create separate searchParams processing functions which I then use in my loaders and my hooks. Which means 2x the amount of files per unique search param. Then again maybe I'm missing something. Maybe the trick is to do all url param processing in the loaders anyway and then pull those in through useLoaderData.

But that still leaves the question how to use state (for example from Zustand) in loaders.