search

stack-auth / stack

Open-source Clerk/Auth0 alternative
https://stack-auth.com
Other
2.97k stars 189 forks source link

useUser() and loading.tsx are braking next.js' revalidatePath() #136

Open Chenalejandro opened 1 month ago

Chenalejandro commented 1 month ago

When using useUser() and loading.tsx, the next.js revalidatePath() will not work correctly.

Steps to reproduce:

  1. clone https://github.com/Chenalejandro/stack-auth-bug
  2. fill env variables
  3. pnpm install && pnpm dev
  4. login and go to the root page
  5. then, there is an input to change the displayName. Fill a new name and click the button "Change user name".

Expected: the input field will be showing the new displayName. Actual: the input field will show the previous displayName.

This bug only happens in the first server action invocation after page refresh. Subsequent server action invocation will revalidate the path correctly.

This issue happens in both dev and production, local or deployed.

The example udpates the displayName, but it can be anything that changes some data and uses revalidatePath() to refresh the page.

I'm not sure if this is a bug caused by next.js itself or by stack-auth. I checked the issues from next.js and the only one that might be related is https://github.com/vercel/next.js/issues/66431

The workaround is to not use useUser() and remove loading.tsx. Just pass the user data from a parent RSC to the child client component. Update: this doesn't work since the /handler/[...stack] still needs the loading.tsx file Second update: just move everything related to the stack-auth to a route group and use the loading.tsx there image

Please feel free to contact me if you need any further information.

N2D4 commented 1 month ago

Also not sure yet if this is our mistake or Next.js (suspicion is on the latter), but definitely something that should be fixed. Maybe we should also stop depending on loading.tsx in the Handler component for the moment, that would lessen the impact of this.

Thanks for the report!