Preventing pageContext JSON fetch in V1?

[shahyar]

I read through the code and some tickets, notably #95. I can set meta.Page.env = 'client-only', which of course has the effect of rendering everything on the client without the *.pageContext.json fetch.

My goal is streaming SSR for the first page load, and then all subsequent nav would entirely render on the client. But I have been unable to achieve this. No matter what I do, pageContext is fetched from the server. Even when I clear passToClient.

In the code, there's a comment about a workaround "for the fact that the client-side cannot known whether a pageContext JSON request is needed", and suggests defining all necessary pageContextInit keys -- but the code in serializePageContextClientSide seems to work opposite to this -- if any passToClient keys are found, it sets _pageContextInitHasClientData = true and causes the JSON fetch. It's always true from what I can see.

Is this a regression in V1 or is it intended to work this way? Is there any way around this?

[brillout]

It only makes a .pageContext.json requests if:

1. There is a onBeforeRender() that will be called and that is server-only.
2. There is a pageContextInit prop that is included in passToClient.

Double check whether that's the case and if both are false and it still makes a JSON request, then report back as it would be a bug.

Note that this is behavior is part of the CI, so chances are that it does work as intended.

[shahyar]

Understandable. So, does this mean that passToClient is only for use cases where one would always do SSR? I thought my app could do:

1. Initial SSR streaming render
2. Hydrate
3. Switch into SPA mode

Based on what I'm hearing from you, it seems that the correct course of action is to create my own context/storage, output that within onRenderHtml, and hydrate onRenderClient. Is that correct?

[brillout]

In general, I'd reduce pageContextInit to a strict minimum. Usually pageContextInit is only used for authentication, e.g. for providing pageContext.user.

Let me know if that answers your question.

[shahyar]

Hey @brillout, coming back to this question. The more I think about this, the more I'm wondering if an additional env mode is needed. The way it's set up, Client Routing doesn't work the way one would expect it to. With Client Routing + server-and-client, it still makes pageContext.json requests. If you want to avoid this, you move everything to an external store (eg. pullstate), but now you lose the ability to access your store during guard, because it's not in the React tree. One would have to completely bypass these features of Vike and implement their own <Guard> in the layout to make this work.

I'd say we need server-or-client-only. The difference between the modes for me is the following in Client Routing:

• server-only outputs raw HTML; no JS bundle attached. Nav = fetch next HTML from server.
• client-only outputs only JS bundles; no HTML. Nav = fetch JS bundle if needed and renders entirely client-side.
• server-and-client gets JS bundles, HTML, and hydrated pageContext in first load. Nav = fetches pageContext from the server if necessary (eg. if pageContext.user from passToClient was present previous request's pageContext result), then re-renders React tree on client side using hydration.
• server-or-client-only same as server-and-client for initial load. Nav = same as client-only.

Basically, I feel that the following code is breaking this from working:

  if (Object.keys(pageContext._pageContextInit).some((p) => passToClient.includes(p))) {
    pageContextClient._pageContextInitHasClientData = true
  }

I only want Vike's SSR server to do initial HTTP requests. Afterwards, it should be completely out of the picture, and let the app turn into SPA mode.

Is this something that you'd think aligns with Vike's plans? I could look at putting together a PR.

[brillout]

The best would be a minimal reproduction showcasing what you expect and what happens instead.

I agree that there should be a way to not have any .pageContext.json requests and it's very much a priority. It should actually already be possible (although I'm less sure about if when using the guard() hook).

Btw. in case your company is up for it: https://github.com/sponsors/brillout.

I'm still just investigating personally, but if we decide to use Vike, you can count on that.

Any news on that? 👀

[shahyar]

The best would be a minimal reproduction showcasing what you expect and what happens instead.

A minimal repro would be simply adding user: { username: 'foo' } to the pageContextInit of examples/react-streaming-v1, and 'user' to passToClient. Now, every page requires a pageContext fetch.

But that should only be necessary on the first page load; after that, I know who user is. I can also manage user state with a React hook (eg. context, pullstate). But I need to be able to modify pageContext.user itself on the client-side so that guard will work.

Any news on that? 👀

Our org's budget is fixed until January, after that we'll be happy to chip in. :) Would be great to have a chat around then if you have some time to spare. In the mean time, I'm reaching out to a customer who is about to use Vike as well.

[brillout]

only [...] necessary on the first page load; after that, I know who user is

You know that, but Vike doesn't and cannot know that.

AFAICT a new config is needed.

I actually am considering a new config to provide the user more control over whether .pageContext.json requests are made. I'll consider your use case then.

It isn't the top priority right now, so it may take a while until I implement it.

Our org's budget is fixed until January, after that we'll be happy to chip in. :) Would be great to have a chat around then if you have some time to spare. In the mean time, I'm reaching out to a customer who is about to use Vike as well.

Sounds great and, yea, I'm up for a chat/call. Looking forward to it :).