Allow `addContextProps()` to be called on the client-side. (For page transitions that happen 100% in the client and where the server is not invovled at all.) about vike

[deckchairlabs]

Yeah, being able to define everything in *.page.ts files would be so great. When I stumbled across this project my immediate thought was "I could make a clone of Remix with this" https://remix.run/
I really like the clean API they have https://www.youtube.com/watch?v=4dOAFJUOi-s&t=1281s

[brillout]

I do like the idea of keeping everything in as few files as possible, but I think having addContextProps be called with different contexts would be confusing, that's what originally confused me w/ the route file.

This ticket is actually about addressing this. Currently addContextProps() is defined in .page.server.js and always called in Node.js which is an important invariant for people who use SQL/ORM queries in their addContextProps() functions. This ticket is about enabling addContextProps() to be called in the browser by defining it in .page.js instead of .page.server.js.

confusing, that's what originally confused me

Clarifying things is a top priority. Proper documentation will go in a long way in clearing things out.

[chrisvariety]

I do like the idea of keeping everything in as few files as possible, but I think having addContextProps be called with different contexts would be confusing, that's what originally confused me w/ the route file. I'm pretty happy with the current addContextProps setup, but having it all in one file and shaking out the server-side dependencies (see https://next-code-elimination.vercel.app ) could be a nice enhancement.

[gryphonmyers]

What is an example use case for calling addContextProps in browser?

[brillout]

@gryphonmyers If the API server doesn't live on the same machine than the SSR Node.js server, then doing API calls in addContextProps() on the SSR server is an indirection.

[gryphonmyers]

I guess what I'm struggling to wrap my head around is, if we can call addContextProps in the browser, then suddenly the context is mutable by the client, right? Currently the assumption is that when we navigate to a new route, we can reliably get that route's context by fetching from either the server or a cached json file, but what if some part of that context was previously mutated by the client? Those mutations would be lost when we fetch the context for the new route

[brillout]

Each page render gets a whole new contextProps which means that contextProps added in the addContextProps() hook don't leak into the next page render.

[gryphonmyers]

Ok so this feature would not persist state mutations across routes? It's merely an opportunity for further transformations after the handoff from server to client, for that specific route?

[brillout]

contextProps is always temporary and only exist while a page is being rendered, the only difference here would be that contextProps only lives in the browser (instead of being computed on the server and handed off to the brower).

Ok so this feature would not persist state mutations across routes?

Yes.

It's merely an opportunity for further transformations after the handoff from server to client, for that specific route?

There would no server request at all.

[brillout]

@gryphonmyers

In general with SSR, there are two scenarios:

1. HTML is fetched/rendered on the server and then hydrated in the browser.
2. Only the DOM is manipulated; the server is not invovled at all in the rendering process.

When not using useClientRouter() then it's always scenario 1. that is being done.

If using useClientRouter() and addContextProps() is defined in .page.js (as suggested by this ticekt) then, when the user nagivates to a new page, scenario 2 kicks in; the server is not invovled at all. Today addContextProps() is always defined in .page.server.js and therefore vite-plugin-ssr has to make a request to the server to fetch the additional contextProps returned by the addContextProps() hook defined in .page.server.js.

The ticket is about enabling scenario 2 in a way that the server is not invovled at all.

Does that make more sense? Let me know if there are still some confusions.

[gryphonmyers]

Ok I think I'm getting closer to understanding the reasoning here. It reminds me of the "preview mode" feature of Nuxt https://nuxtjs.org/docs/2.x/features/live-preview/. This is a mode you can enable for your application which will cause all asyncData to be called on the client as well as the server (asyncData being roughly analogous to addContextProps in our case). This can be useful in cases where you are prerendering, but want to get data that has changed since prerender occurred. This isn't really something you'd use in production - it's specifically for previewing because there is typically some degree of flashing / layout shift.

Is this roughly equivalent, or is this a feature you're imagining would be used in production?

[brillout]

Currently, addContextProps is always called on the server.

This ticket is about enabling addContextProps to be called in the browser instead of being called on the server.

Why would you want that? Because if, for example, you are using a GraphQL API SaaS then your Node.js server will not be geographically close to the GraphQL SaaS servers; hence calling addContextProps on your Node.js server is a wastful indirection; you may want to call addContextProps directly from the browser instead.

That's it.

Thanks for the discussion btw. it makes me realize I should be careful about being clear in the docs.

[chrisvariety]

Yeah, I am 👎 on this, at least calling it context props (or whatever we end up calling serverside props), all of the logic I have would need to be on the server, and sharing the nomenclature between client and server would just be confusing. You can already call graphql on the frontend without this if you need it (e.g. react hooks)

[gryphonmyers]

Yeah I agree with @chrisvariety. If I need client side fetches to occur I can make them separate from the SSR context. I think allowing the client to be involved here makes everything more difficult to understand. It's easy to understand the sequence of get context props, then use those to render html. That sequence ends once html is sent to the browser, and everything else that occurs is up to the client application and outside the scope of the SSR process.

[brillout]

I actually also have a strong preference of moving as much stuff as possible to the server. Since pages are server-side rendered anyways, it makes sense to keep stuff on the server-side.

That said, I can see situations where it's usueful to have page transitions that happen 100% in the client-side and where the server is not involved at all.

Anyways, no one's knocking at the door for this feature so I'm keeping this ticket open shall someone need this. (To be clear: I'm not interested in covering 100% of all possible use cases out there, but this seems like an important enough one to cover.)

Let's continue the discussion shall someone push for this.

Rest assured, the docs will keep things server-side and, thanks to well-designed docs, the added complexity will only affect people who want this.

I'm removing the discussion label for the time being, but feel free to reply and disagree with anything I say.

[brillout]

After much consideration, I will most likely mark this as wont-fix. As @gryphonmyers and @chrisvariety
pointed out, this would just inherently complexify things. I now believe that there is no way to implement this in a way the keep things simple.

[brillout]

Closing this. If someone reading needs this, let me know.