javascript icon indicating copy to clipboard operation
javascript copied to clipboard

UserButton.Action should appear when conditionally rendered

Open aldenquimby opened this issue 5 months ago • 3 comments

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

https://github.com/aldenquimby/clerk-bug-conditional-menu-action

Publishable key

pk_test_aW1tdW5lLXRlYWwtMjEuY2xlcmsuYWNjb3VudHMuZGV2JA

Description

Steps to reproduce:

  • Use UserButton with UserButton.MenuItems and conditionally hide a UserButton.Action (or UserButton.Link, they both have the bug)
  • While the UserButton menu is open, change the conditional value of the action/link to be shown

Expected:

  • Menu re-renders and shows the new action/link

Actual behavior:

  • Menu does not re-render. Action/link remains hidden

From repro github

  • Open menu and notice no Custom action is shown
  • Click "Toggle action in 5 seconds"
  • Re-open menu
  • After 5 seconds, I'd expect the action to appear
  • Instead, you need to close and re-open the menu for it to appear

Image

Background

  • In our production app, I would like to render an option only if the user has access to it. The access check is expensive, so I want to defer it until the UserButton is clicked

Environment

System:
    OS: macOS 15.4.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 334.59 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.14.0 - ~/.local/state/fnm_multishells/42049_1753880159299/bin/node
    Yarn: 1.22.22 - ~/.local/state/fnm_multishells/42049_1753880159299/bin/yarn
    npm: 10.9.2 - ~/.local/state/fnm_multishells/42049_1753880159299/bin/npm
    pnpm: 10.13.1 - node_modules/.bin/pnpm
  Browsers:
    Brave Browser: 138.1.80.122
    Chrome: 138.0.7204.169
    Safari: 18.4
  npmPackages:
    @clerk/nextjs: 6.31.4 => 6.31.4
    @tailwindcss/postcss: ^4.1.11 => 4.1.11 
    @types/node: ^24.0.3 => 24.0.3 
    @types/react: ^19.1.8 => 19.1.8 
    @types/react-dom: ^19.1.6 => 19.1.6 
    @types/react-syntax-highlighter: ^15.5.13 => 15.5.13 
    clsx: ^2.1.1 => 2.1.1 
    lucide-react: ^0.534.0 => 0.534.0 
    next: 15.3.4 => 15.3.4 
    pnpm: ^10.13.1 => 10.13.1 
    postcss: ^8.5.6 => 8.5.6 
    prism-react-renderer: ^2.4.1 => 2.4.1 
    react: ^19.1.0 => 19.1.0 
    react-dom: ^19.1.0 => 19.1.0 
    react-syntax-highlighter: ^15.6.1 => 15.6.1 
    tailwindcss: ^4.1.11 => 4.1.11 
    typescript: ^5.9.2 => 5.9.2

aldenquimby avatar Aug 28 '25 17:08 aldenquimby

Thanks for reporting and providing a repro. I can confirm the issue 👍🏼

That said, typically users don't keep dropdown menus open while waiting for content to load or change. They usually open it, quickly scan the available options, select an item, and close it.

wobsoriano avatar Sep 03 '25 15:09 wobsoriano

@wobsoriano yes agreed. Ideally we'd show a loading spinner in the menu for the ~300ms it takes to load, but because of the various "child must be of type" checks, this is not possible today. Open to other suggestions

aldenquimby avatar Sep 03 '25 15:09 aldenquimby

@wobsoriano instead of re-rendering the menu if any child changes, could you introduce some way to show a loading state, e.g. an isLoadingMenuItems prop?

aldenquimby avatar Sep 05 '25 14:09 aldenquimby