You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've studied the subject of having a "server context" a while ago when RSCs were released: https://prismic.io/blog/advanced-nextjs-server-context. I was taking a look at the README and I am not sure about the demonstration example.
You seem to expect a specific order in the rendering, first the page, then the component that consumes the value set by the page via the cache. But I am not 100% sure this rendering order is guaranteed in Next.js, namely during navigation and updates.
I don't know if the same can be achieve with a page and its RSC but I wouldn't be surprised if it could happen, eg with Server Actions.
In my understanding, using "cache" as a server context is more relevant to guarantee that you do some operations only once: creating a stateful client (needed to properly optimize graphql), parsing search params for instance. So more a "cached get" than a "set/get" as demonstrated.
What do you think?
The text was updated successfully, but these errors were encountered:
Note: when navigating on the client side the layout is not re-rendered, so you need to set the context both in the page and in the layout.
The approach used here in this package has also been adopted in next-intl if I'm not mistaken, so it is kind of becoming the de-facto standard for RSC server context.
In regards to what I think, I think that RSC was a good idea, but rather poorly implemented. I have since moved to Qwik for my side projects.
Right you already caught the problem for the layout. I will try to run experiments to see if it can be bypassed for pages/components too, I do have doubts when it comes to server actions.
Hey,
First, great library!
I've studied the subject of having a "server context" a while ago when RSCs were released: https://prismic.io/blog/advanced-nextjs-server-context. I was taking a look at the README and I am not sure about the demonstration example.
You seem to expect a specific order in the rendering, first the page, then the component that consumes the value set by the page via the cache. But I am not 100% sure this rendering order is guaranteed in Next.js, namely during navigation and updates.
For instance it is possible to fetch the RSC payload for a page, without running its layout (it creates a risk of leak for private, non-user specific content if you are not careful), so you can't assume that if a layout sets a value, the page will get it.
I don't know if the same can be achieve with a page and its RSC but I wouldn't be surprised if it could happen, eg with Server Actions.
In my understanding, using "cache" as a server context is more relevant to guarantee that you do some operations only once: creating a stateful client (needed to properly optimize graphql), parsing search params for instance. So more a "cached get" than a "set/get" as demonstrated.
What do you think?
The text was updated successfully, but these errors were encountered: