fix: seed useUser with auth.currentUser to prevent undefined on initial render

[tyler-reitz]

Problem

Since 4.2.3 (#539 removed the initialData seeding), useUser() returns {status: 'loading', data: undefined} on the first render when called in a child component whose parent only called useSigninCheck() as a guard.

The root cause: useSigninCheck and useUser use different observable IDs (auth:signInCheck:... vs auth:user:...). When the guard resolves and renders the child, the child's useUser() creates a fresh SuspenseSubject that hasn't received a value yet. Firebase's onAuthStateChanged fires asynchronously, so the first snapshot is always loading.

This breaks patterns like:

function AuthGuard({ children, fallback }) {
  const { status, data: signInCheckResult } = useSigninCheck();
  if (status === 'loading') return fallback;
  if (signInCheckResult.signedIn) return children;
  return <Redirect to="/login" />;
}

function ProfilePage() {
  const { data: user } = useUser(); // undefined on first render
  const { data: idTokenResult } = useIdTokenResult(user as User, false); // throws
}

Fix

Restore the synchronous seed: if auth.currentUser is truthy (a signed-in user is available), set it as initialData before passing to useObservable. This means useUser() returns the user immediately on the first render without waiting for the async observable.

The check is if (auth.currentUser) (truthy, not !== undefined) to avoid the ambiguous case where currentUser is null before auth has finished loading from storage. If we seeded null in that case, callers would incorrectly see a signed-out state during initialization.

Testing

• All 14 auth tests pass
• The specific test synchronously returns a user if one is already signed in covers the exact behavior restored here

Fixes #582

[gemini-code-assist]

Code Review

This pull request updates the useUser hook in src/auth.tsx to seed initialData with auth.currentUser when a user is already signed in, enabling synchronous rendering on the first load. The review feedback points out that this implementation unconditionally overwrites any caller-provided initialData or startWithValue options, and suggests only seeding the user if these options are not already explicitly defined.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[armando-navarro]

Two asks, non-blocking since I'm approving:

1. Add a regression test that fails on main. The test you cite passes on main in test suite runs, so nothing today stops a future #539-style removal from silently regressing #582 again. The guard-pattern structure works even mid-suite because useSigninCheck and useUser cache under different ids: parent renders a useSigninCheck guard; once signedIn, mount a child calling useUser(); assert the child's first-render data is the user. Happy to share the exact test I used.
2. Correct the Testing section of the PR body (it becomes the squash-commit message): "All 14 auth tests pass" is equally true on main, and the cited test only discriminates when run in isolation. With ask 1 done, the body can simply point at the new test.

A couple more non-blocking notes that didn't fit as inline comments:

• Is it Intentional that useSigninCheck stays unseeded? Post-merge, the two auth hooks disagree on first-render state for a signed-in user (useUser → instant success, useSigninCheck → loading flash). jhuleatt's comment in #582 pointed at the two hooks using different observables as the root problem; warming/sharing from useSigninCheck (no-claims path) would close the asymmetry and has no currentUser-timing windows at all. Fine as a follow-up — asking mainly whether it's on your radar.
• Since #539's objection was "undocumented tri-state," worth one line in the body noting the ground has shifted: the SDK now documents currentUser: User | null and exposes authStateReady(). Truthiness is still a fine choice here (authStateReady() is async and can't help a synchronous first render), but pre-empting the #539 argument in the body will save a review cycle if Jeff looks at this.
• A component that mounts while signOut() is in flight will now show the outgoing user on its first frame and see no loading status for that mount (success(user) → success(null)). Main already showed a stale signed-in frame one paint later in the same window, so this is a one-frame delta, not a new failure mode — but if someone ever reports "flash of signed-in UI during logout," this is where it lives.

Approving.

[armando-navarro]

Consider documenting the behavior change where users will see it: one JSDoc sentence on useUser (first render is success for already-signed-in users; in suspense mode, signed-in users no longer suspend) + a docs regen. The suspense change is arguably the biggest surface change and it's currently only visible by reading this code comment.

[armando-navarro]

initialData's type collapses to any, so this assigns with no cast at all (verified with the repo's own tsc). If you keep a cast, the codebase's existing idiom is as any as.