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:

```tsx
function AuthGuard({ children, fallback }) {
const { status, data: signInCheckResult } = useSigninCheck();
if (status === 'loading') return fallback;
if (signInCheckResult.signedIn) return children;
return ;
}

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.

#539's objection was that `currentUser` was undocumented tri-state. That ground has shifted: the SDK now explicitly documents `currentUser: User | null` and exposes `authStateReady()`. Truthiness is still the right check here since `authStateReady()` is async and can't help a synchronous first render.

Testing

Added a regression test: `synchronously returns the current user without waiting for the observable`. The test installs `NEVER` as the `auth:user` observable before rendering, so any synchronous user value on first render must come from the `initialData` seeding path, not from the observable. Without the fix: `status: 'loading'`. With the fix: `status: 'success'`, `data: auth.currentUser`.

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.

[tyler-reitz]

Added a regression test in 670733a that should address the ask.

The approach: before rendering, we replace the auth:user observable in the preloaded cache with NEVER (an observable that never emits). This means any synchronous user value on first render must come from the initialData seeding path (the fix), not from the observable. Without the fix the first render sees status:'loading'; with it, status:'success'.

One tradeoff worth noting: the test deletes the cache entry via (globalThis as any)._reactFirePreloadedObservables and hardcodes the internal key format auth:user:${auth.name}. The global is deliberately on globalThis for cross-module sharing, so it's stable in practice, but the cache key is an internal detail. If that format changes, the test would fail on main for the wrong reason rather than silently passing. Happy to extract a test utility (_deletePreloadedObservable) from useObservable.ts if you'd prefer to avoid the raw global access.

[tyler-reitz]

Re: useSigninCheck staying unseeded — yes, it's on our radar. The asymmetry is real and the shared-observable approach you described (warm useSigninCheck's no-claims path, let useUser read from the same cache entry) would be the cleaner fix. Tracking it as a follow-up so it doesn't get lost.

[tyler-reitz]

Code review also surfaced a pre-existing bug that this PR exercises more frequently: #736 (useObservable mutates the shared _immutableStatus snapshot in-place). Filed separately — not blocking merge.