<SignIn> Component Not Rendering After Signing Out When Component Has Appearance Props Added

[brettabamonte]

Preliminary Checks

• I have reviewed the documentation: https://clerk.com/docs

• I have searched for existing issues: https://github.com/clerkinc/javascript/issues

• I have not already reached out to Clerk support via email or Discord (if you have, no need to open an issue here)

• 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://github.com/brettabamonte/Clerk-Minimal_Reproduction-SignIn_Component/tree/main

Publishable key

pk_test_Y2hpZWYtc2N1bHBpbi0xMi5jbGVyay5hY2NvdW50cy5kZXYk

Description

Steps to reproduce:

See steps and screenshots in linked git repository README.md (https://github.com/brettabamonte/Clerk-Minimal_Reproduction-SignIn_Component).

Expected behavior:
After clicking the the user should be redirected to the sign in page with a component displaying that has appearance props.

Actual behavior:
After clicking the the user is redirected to the sign in page but the component does not render when it has the appearance prop set. If the appearance prop is set the component displays properly.

Environment

System:
    OS: macOS 14.0
    CPU: (8) arm64 Apple M2
    Memory: 238.50 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.18.1 - /usr/local/bin/node
    npm: 9.8.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 118.0.5993.117
    Safari: 17.0
  npmPackages:
    @clerk/nextjs: ^4.26.1 => 4.26.1 
    @types/node: 20.1.4 => 20.1.4 
    @types/react: 18.2.6 => 18.2.6 
    @types/react-dom: 18.2.4 => 18.2.4 
    autoprefixer: 10.4.14 => 10.4.14 
    classnames: ^2.3.2 => 2.3.2 
    next: ^14.0.0 => 14.0.0 
    postcss: 8.4.23 => 8.4.23 
    react: 18.2.0 => 18.2.0 
    react-dom: 18.2.0 => 18.2.0 
    tailwindcss: 3.3.2 => 3.3.2 
    typescript: 5.0.4 => 5.0.4

[tjl-jg]

I have an issue that sounds very similar, but with the <UserButton />. After signing out, and signing back in, it renders at size 0x0.

Not sure if it's related or not, but the browser console is showing a couple of errors related to signin. The stack trace is to a packed vendors file, so the line numbers probably aren't relevant, but the error is "Uncaught TypeError: Cannot read properties of undefined (reading 'imageUrl')" and the line of code sets avatarUrl with l.userData.imageUrl, where l is a minified variable name.

All that to say that it looks like it is somehow trying to set the avatar with the imageUrl of a userData that hasn't been initialized yet.

[IGassmann]

I can confirm this also happens on @clerk/nextjs: 4.27.1/next: 14.0.2. However, it happens for us independently of the use of the appearance prop

[LekoArts]

Hello all!

Just a short update here to show that I/we haven't forgotten this issue 😅 Thanks for the reproduction, I was able to also see the issue. Important bit: This also happens without the appearance prop.
After investigating I'm still not sure exactly what is causing it, might be a race condition or an issue with client side re-hydration.

We'll discuss internally a bit how we want to tackle this but I'd be interested in your opinion on this question (@brettabamonte @tjl-jg @IGassmann):

What is your expected behavior for the <SignOutButton /> as to where it should navigate?
Should it stay on the same page? Navigate to the sign in page? Navigate to a custom page one has to define?

[tjl-jg]

My opinion about redirect options: I prefer full context to be in my code, so I'd probably use a property specifying the redirect destination even if my destination was the default. This way it shows up in searches of the project, and the action is clear later on (or to other developers) without anybody having to read documentation.

[brettabamonte]

@LekoArts I agree with @tjl-jg. I like the context to be within the component using a property. Having a default destination is nice if the property isn't declared on the component. 90% of the time, I like redirecting users to a default page like the sign in page but there are instances where it'd be nice to redirect them to a custom destination.

Thank you and the team for looking into this!