Passing hook values to loaders & actions

[jordanthornquest]

The question

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().

While a feature request like #9324 may cover this issue for passing context values, I'm unclear on how to handle this with values solely derived from hooks. Considering a project structure akin to Auth0's example app with React Router, how could the value from getAccessTokenSilently() be accessed and passed down to loaders and actions?

Related issue

I've made the same request for addressing this in #9324. Double-sharing here, in the context of discussion, in case there are any additional approaches to consider.

Similar questions

This question has been asked in a couple of similar forms, but none quite for the specific use case I'm dealing with.

• Using hooks inside 'createBrowserRouter' 'loader' #9246
• How do I get a value from react context in react-router-dom v6.4's loader? #9286
• Authenticated loaders #9327

[nahumzs]

I'm having the same problem, trying to figure it out how to do this correctly, but sadly I'm not finding a convenient solution. How are you solving it so far? @jordanthornquest.

[brophdawg11]

You cannot access React context from loaders and actions because they are, by design, decoupled from the render cycle.

Instead, you should aim to read from the source of truth for the data in question. Hooks are merely a convenience way to access a source of truth + update when it changes. With loaders/actions - RR will handle the "changes" part, so you just need to find the source of truth. I've been meaning to get a diagram of sorts together for this but basically:

source of truth -> Context.Provider -> useContext -> hook -> component
       |
       |-> loader()

Anything you read client-side in a hook comes from somewhere in the client - find that source and read from it in your loader.

[aaronadamsCA]

There are situations where a hook's source of truth is cross-origin communication with another Window. Shopify App Bridge is an example of this.

Today the only way to get a Shopify session token is on the client side; but we want to use that session token in our loaders and actions.

I think it would be good to document a general solution for this scenario, for cases where an ecosystem component is still designed only for single-page apps.

[ryanflorence]

You can access the session inside loaders with Shopify App Remix.

Here's an example from the Remix Shopify app template

export const loader = async ({ request }) => {
  const { session } = await authenticate.admin(request);

  return json({ shop: session.shop.replace(".myshopify.com", "") });
};

[nahumzs]

Yeah, I think, it needs a little more context, to properly answer this question, the main problem is when the source of true is actually a hook, like in Auth0, where the access token generation happens inside of the hook, therefore is quite inconvenient not be able to have access to the context of the loader.

loaders -> Router -> const  { getAccessTokenSilently } = useAuth0(); const accessToken = getAccessTokenSilently() => `?`

So in this scenario even if the intention is that the flow is unidirectional is quite obvious that you need the access token on the loader.

Agree that this is also an Auth0 API design kind fault maybe, if they would expose an alternative way to get the Access token all this discussion would be meaningless.

So in my case in order to solve this issue I have to go as you mention one level up from the router and create a component that exposes this function and the user, since when you are making a request normally you will need both on the loader context.

So my solution looks something like this:

// AccessToken.jsx
export const AccessToken = () => {
   const { getAccessTokenSilently, user } = useAuth0();
   
   const getUser = () => user
   
   return <>{ props.children(getAccessTokenSilently, getUser ) }</>
}

// router.tsx
export const router = (accessToken) => {
  return createBrowserRouter([
    {
      path: "/some-route",
      loader: someLoader(tokenParameters),
    },
  ])

}

// main.jsx
import { AccessToken } from "./AccessToken"

ReactDOM.createRoot(document.getElementById("root") as HTMLElement).render(
  <React.StrictMode>
      <Auth0Provider
        domain="your-domain"
        clientId="your-client-id"
        authorizationParams={{
          redirect_uri: `${window.location.origin}/your-route`,
        }}
      >
        <AccessToken>
          {(tokenParameters) => {
            return <RouterProvider router={router(tokenParameters)} />
          }}
        </AccessToken>
      </Auth0Provider>
  </React.StrictMode>

loader ->  <AccessToken /> -> router(accessToken) -> <Router /> -> <App />

I don't know if this it is a valid solution but it is one, so I haven't see any other example around here or auth0 documentation, also I didn't want to invest any more time on this.

So let me know if there is any alternative to this scenario to me seems like there is not either Auth0 change its API or React Router provides a way to access hooks on loaders

thanks for all the great work!

[brophdawg11]

The auth0 React hooks that protect via a HOC are based on the assumption of "fetch as you render" which is fundamentally different from the core design decision of "fetch before you render" implemented in RouterProvider. If you are happy with those, then I would suggest sticking with BrowserRouter which follows the "fetch as you render" pattern.

We designed RouteProvider using "fetch before you render" because we think it generally provides a more performant and better UX without spinner waterfalls (and also results in smaller + cleaner app code). You can check out https://remix.run/blog/remixing-react-router and https://www.youtube.com/watch?v=95B8mnhzoCM for some more information on this decision.

couldn't justify that I would end reimplementing react-auth, isn't it

If you want to use RouterProvider with the SPA SDK, then I would bet you don't actually need the vast majority of what their React layer gives you. You would load user data in the root loader, redirect to /login if not logged in, and handle login/logout via action functions. Here's the list of things they show on their docs for the React layer, and what you would likely use instead from React Router if you went the SPA SDK route:

From useAuth0 Hook	React Router Alternative
isLoading	useNavigation().state
user	useRouteLoaderData("root").user
isAuthenticated	useRouteLoaderData("root").user != null
error	ErrorBoundary or useRouteLoaderData("root").error
loginWithRedirect	<Form method="post"> on /login route
logout	<fetcher.Form method="post" action="/logout">

[brophdawg11]

maybe my suggested approach isn't that bad for the time being

The biggest concern with the approach above is that you are creating a new router on each new render via:

<AccessToken>
  {(tokenParameters) => {
    return <RouterProvider router={router(tokenParameters)} />
  }}
</AccessToken>

This is very likely not going to work right and cause really odd behavior and bugs. Are you properly calling router.dispose() on the old router when you create a new one? If not you'll keep stacking up history listeners. What happens to the state of the old router when you create a new one? Does it just get lost?

The router is intended to be a singleton created before you do any rendering via React.

[jgangemi]

i believe i have a working solution for this.

const Application = () => {
    const user = useLoggedIn();
    const children = [];

    routeIterator((config) => {
        if (config.isRoute()) {
            children.push(createRoute(config, user));
        }
    });

    return (
        <RouterProvider router={createBrowserRouter([
            {
                element: <SecurityProvider/>,
                children: [
                    {
                        element: <MainLayout/>,
                        children: children
                    }
                ]
            }
        ])}/>
    );
};

const createRoute = (config, user) => {
    return {
        path: config.getLink(),
        async lazy() {
            const { routeConfig } = await import(`./pages/${config.getComponent()}`);
            return routeConfig(user);
        }
    };
};

export const useLoggedIn = () => {
    return React.useContext(SecurityContext);
};

export const SecurityProvider = () => {
    const navigate = useNavigate();

    const onRedirect = (appState) => {
        navigate((appState && appState.returnTo) || window.location.pathname);
    };

    return (
        <Auth0Provider {...auth0Configuration} onRedirectCallback={onRedirect}>
            <Security/>
        </Auth0Provider>
    );
};

const Security = () => {
    const { isAuthenticated, isLoading, user, loginWithRedirect} = useAuth0();

    // TODO: need to check for an error?

    console.log(`loading: ${isLoading}`);
    if (isLoading) {
        return "loading";
    }

    console.log(`authed: ${isAuthenticated}`);
    if (isAuthenticated) {
        return (
            <SecurityContext.Provider value={UserDelegate.mockUser()}>
                <Outlet />
            </SecurityContext.Provider>
        );
    }

    loginWithRedirect().then();
    return null;
};

the HOC kept taking me to the login page when the loader was invoked. switching to the manual check seems to have resolved that and still lets me use the rest of their ecosystem.

this is still a WIP but i wrap the auth0 user object in a delegate class and pass it around via my own context. then i have my own hook to access it instead of sprinkling around calls to auth0.

the lazy import of those route attributes lets me pass in a user object to my loader so i can get access to it's id, etc when building urls. your implementation would be similar where you'd get the auth token and pass it in.

[brophdawg11]

I finally got around to putting together a basic Auth0 example using RouterProvider: https://github.com/brophdawg11/react-router-auth0-example

[iamafansev]

I found solutions without using closures in functions, as they complicate the code and add manual actions

Using this solution you configure the router context from App. Then this context will be available as the second argument in the loader / action functions.

This involves overriding some types in the @types/router.d.ts file.

iamafansev/vite-spa-template@5bba032