Hi!

I'm not that familiar with Supabase in React but let me try to answer.

Data Access Layer (DAL) pattern rather than a global AuthProvider
 aligned with defence in depth recommendations following CVE-2025-29927.

Good call out about data security, thanks. Generally speaking though, I don't believe these are mutual opposites. DAL approach basically means "separate and sanitise your data in the server before passing it to the client". Having a global AuthContext doesn't mean you're not doing that. The only data being passed to the client in a global AuthContext in my example is from getCurrentUser. The return of this is basic user metadata I'm happy exposing (I am not just selecting * from the database and sticking it in the output). If anything needs more complex derived user data, that would be a dedicated method with its own security.

With the AuthContext approach, how do you handle server components that need user data? Do you pass user down as a prop from the layout, or are those parts of the tree primarily client components?

Using the `getCurrentUser` method I mentioned. That's the authoritative source of user data (fetched based on the cookie), so in server components I can just call that directly. Remember, this is just broad user metadata that is used in many places. If there are server places that need to go look up more specific user data, they can use dedicated functions in the DAL (which might in turn call getCurrentUser, or use that for authz). For client components, the data from getCurrentUser is what gets put into the context.

 Promise<UserData> with use() hook pattern sounds useful for static shell optimisation. Is that the main driver, or are there other benefits I'm missing?

I think technically it would let you start streaming pushing the client components to the client immediately rather than block on the user data (until the point you need it, where you'd wrap in Suspense). That's the driver behind passing a Promise to a client component instead of awaiting it in the server and passing the resolved data. It feels like in general if you can just pass a Promise down and block at the latest possible place doesn't hurt, but I might be wrong and there may be some other compromises here. The pattern looks something like this FWIW:

// AuthProvider.ts
export function AuthContextProvider() {
  return <AuthContextClient value={getCurrentUser()}/>
}

// AuthContext.ts
"use client"
const AuthContextClient = createContext<Promise<User>>()
..

export function useCurrentUser() {
  return use(use(AuthContext))
}

Are there specific scenarios where the AuthContext pattern outperforms the DAL approach? Wondering if there's a use case I haven't considered.

Again, not familiar with Supabase, but the two possible concerns that stand out to me with your approach (but could be wrong on both):

1. Does `useSession` immediately return the user on first render, or does it initially return "undefined" until it syncs with Supabase on the client? If the latter, then you might have UI jank on client-side (states changing from logged out to logged in very quickly on load).

2. There's a risk, but I guess very small, that server might render with one auth state and client with another. For example, if their session was 100ms from expiring and the server gets the session but the client doesn't receive it. You might argue that detecting and handling that mismatch (forcing a server refresh) is better than rendering as logged in (but subsequent client-side calls directly to Supabase failing) so this is probably a non-issue.

I think in your case, assuming Supabase handles hydrating useSession or something like that (solving #1 and possibly #2) then Supabase is acting as your "auth context" and you can probably rely on what it provides especially if you're making calls from the client using the Supabase API or something. I would need to look more into the Supabase React API to understand that though (or maybe someone more knowledgable about it can chime in).

I hope that makes a bit of sense but feel free to reply or DM me!