Usage to set value feels non-idiomatic

[eric-burel]

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?

[manvalls]

Refer to this note on the README:

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.

[eric-burel]

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.

Thanks for your fast answer, have fun with Qwik!