@luis_llanes do you have an example for this pls, also I'm talking about the build for the static route is it gonna be static on build or dynamic as it all turned to dynamic?!

It’s gonna be static up to the <Suspense> boundary

That’s why it’s important to place <Suspense> boundaries as close as possible to the components that suspend

Let me see if I have a repo with that use case, if not I’ll try to replicate it quick

Thanks alot appreciate it

For now, answering your question, context doesn’t make any component client neither dynamic, what makes routes dynamic is accessing to dynamic/async APIs such as cookies, headers, searchParams, and reading promises in the body of components

Yup exactly so my getCurrentUser is using cookies that's why it make it dynamic on build

but I saw like Lee for fast showing the user session he uses it like this and pass it to the context to use hook but this results in all pages to be dynamic so I was confused about it

use(promise) is for the latter use case, and if you want only the component that it’s calling “use(authPromise)” to be suspended then you need to wrap it in <Suspense>

Let me see if only the page that imports the component that calls “use” is dynamic or them all

What auth library are you using?

supabase auth

here is my build after wrapping the whole layout of this sessionProvider which got authPromise as a prop

Well for Clerk, for example, that is the default, as soon as you wrap your whole app in their Provider all routes automatically become dynamic.

This didn’t show you wrapping your app in a SessionProvider because it was abstracted under <Providers>

Umm, that's abit weired to make pages that should be only static or have only static content to by dynamic I didn't use clerk before and didn't know about that like for supabase
they don't provide you with a sessionprovider to access session on the client that you need to do by yourself so I was searching for the best and fast solution rather than making all my routes dynamic

I replicated your implementation

TLDR: Next.js opts you out of static rendering since cookies is a dynamic API and using it in a layout or page will opt a route into dynamic rendering.
nextjs.org/docs/app/api-reference/functions/cookies#good-to-know

Maybe your best bet would be to request the session at the page level in only the pages you want to be protected/where you need the user session.

I'm getting the same results
https://github.com/llanesluis/template

The best approach would be to call the getSession() function at the page level if you want granular session checks/get the user session, this way you keeo your pages static except the ones calling the function, and instead of passing the session promise through context you can pass it down from the page (server component) to the client component.

For whole sections that require the user session you can granularly wrap only the section or nested layout instead of the rootlayout

This branch shows the other approach, the more granular way, keeping all static unless you opt out by calling the getSession function, if you run the build you will see only the root page and the pages under /about/ layout are dynamic
https://github.com/llanesluis/template/tree/demo-session-without-global-provider

Thanks alot for your help

You're welcome! You had time to check the repos?