Closed kylegwalsh closed 6 months ago
@kylegwalsh , Having seen the video and checked the behaviour myself to double check, getToken
is returning a Promise, and thus it will have to be called after isSignedIn
has returned true. As seen below, getToken()
returned null before the log for isSignedIn
is printed and so, it makes sense that it might returnnull
, if isSignedIn
is not checked beforehand.
I should also mention here, that one should not look at the sign-ins request in the network tab, but the touch request right after, as that is what is actually setting the session as the active one.
Since you mentioned that you actually check the value of isSignedIn
before you actually call getToken()
(although the logs in the console seem to be reversed), could you provide a snippet of the code ?
Hi @desiprisg, my code uses @trpc/react
to control queries to the backend. My query should not be enabled until isSignedIn
becomes true (see below):
useUser() hook
// Get the user data from our DB
const { data } = trpc.user.get.useQuery(undefined, {
// Don't enable the query until the clerk user is defined
enabled: !!isSignedIn,
});
QueryProvider
component
import { useAuth } from '@clerk/clerk-expo';
import { config } from '@hlp/config';
import { trpc } from '@hlp/core/client';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { httpBatchLink } from '@trpc/client/links/httpBatchLink';
import React, { useState } from 'react';
import superjson from 'superjson';
/** Adds TRPC and react-query functionality to the app */
export const QueryProvider = ({ children }: any) => {
const { getToken } = useAuth();
// Initialize query client and trpc client
const [queryClient] = useState(() => new QueryClient());
const [trpcClient] = useState(() =>
trpc.createClient({
links: [
httpBatchLink({
url: `${config.api.url}/trpc/`,
async headers() {
/** Retrieve auth token from storage */
const token = await getToken({
template: 'default',
});
console.log('CLERK TOKEN', token);
return {
// Attach auth header if we have a token
...(token && {
Authorization: `Bearer ${token}`,
}),
};
},
}),
],
transformer: superjson,
})
);
return (
<trpc.Provider client={trpcClient} queryClient={queryClient}>
<QueryClientProvider client={queryClient}>{children}</QueryClientProvider>
</trpc.Provider>
);
};
So, the useUser()
query is being enabled by isSignedIn
first, and then it is invoking getToken()
during the request. This is why I thought that there may be some kind of race condition between the two actions.
I just attempted to upgrade to the latest clerk version to see if the issues still persist, but I'm seeing a CORS error due to an expo header (I never saw this before, so I'm not sure what introduced it). I'll have to dig into this more before I can determine if I'm still seeing the issue.
Access to fetch at 'https://CLERK_DOMAIN/v1/client?_clerk_js_version=4.70.5&_is_native=1&__dev_session=SESSION' from origin 'http://localhost:8081' has been blocked by CORS policy: Request header field x-expo-native-application-version is not allowed by Access-Control-Allow-Headers in preflight response.
We also have pages protected by
[!NOTE] Those header(s) are coming from the Expo SDK. https://github.com/clerk/javascript/blob/69df1ab81b95ca2af82bf17bee9d3fa1a9fdbfa2/packages/expo/src/singleton.ts#L47-L53
We can remove these, and publish a new version.
Additionally, the CORS suggests that you're using Clerk-expo from a browser, is that right @kylegwalsh? Can you help us understand your development flow a bit? Clerk-expo via the browser is not exactly a supported use case yet, though we do have Support for Expo Web on our roadmap.
@thiskevinwang That would make sense. We've actually been using clerk-expo
since the beginning for mobile / web and never encountered any issues (until we tried to upgrade). The error definitely makes sense if the latest version of clerk-expo
doesn't support web.
Happy to expand on our development flow as well. We actually created a single expo codebase that works on every platform (ios, android, and web). Most of the libraries that we're using support that setup, however we do have to occasionally create two separate files (index.web.ts vs. index.native.ts) to import separate packages based on platform. I can definitely modify the setup to import clerk-react
on web if that should work.
@kylegwalsh I've opened a PR to remove these headers - #3326
While that is in-review, you can also try clerk.__unstable__onBeforeRequest
as a workaround to remove the headers before the request
Hey @kylegwalsh this should be fixed in @clerk/clerk-expo@1.1.0
!
Give that a shot, and feel free to reopen this issue if the error persists!
npm install @clerk/clerk-expo@latest
Preliminary Checks
[X] I have reviewed the documentation: https://clerk.com/docs
[X] I have searched for existing issues: https://github.com/clerk/javascript/issues
[X] I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)
[X] This issue is not a question, general help request, or anything other than a bug report directly related to Clerk. Please ask questions in our Discord community: https://clerk.com/discord.
Reproduction / Replay Link
https://jam.dev/c/3bce6734-c313-4b82-a638-4022254bfb7a
Publishable key
pk_test_Y2xlcmsuY3Jpc3Auc2Vhc25haWwtOTEubGNsLmRldiQ
Description
Steps to reproduce:
useSignIn()
hookgetToken()
from theuseAuth()
hook once the user logs in (key off of theisSignedIn
boolean)Expected behavior:
I would expect
getToken()
to return the token the moment clerk indicates thatisSignedIn
is true. This is how the library behaved in version0.10.6
of clerk-expo (and it's related clerk-react version).Actual behavior:
getToken()
returnsnull
right after the user is signed in (a race condition). This causes a cascade of undesired behaviors in my particular app because I expect token to exist right after clerk informs me that the userisSignedIn
.Environment