Possible to to render pages directly vs using `renderPage(...)`? #527

coryvirok · 2022-11-28T19:52:22Z

coryvirok
Nov 28, 2022

Hello! First off, thank you for building VPS. I'm coming from more of a traditional server template architecture and was hoping to use VPS in a similar way.

I'd like to do the following:

Create my routes in Express/Fastify
Create Pages using VPS
In my Express/Fastify route handler, (e.g. GET /user) create the props for pages/user/index.page.svelte and render the page to a string before returning the response in my Express/Fastify route handler.

E.g.

app.get('/user', async (req, reply) => {
    const props = await buildUserIndexPageProps(req)
    const htmlResponseString = await renderPage(req.url, props)
    return reply.statusCode(200).header('Content-Type', 'text/html').send(htmlResponseString)
})

The issue I'm running into is that it doesn't appear that it's possible to pass props directly to my Page component using renderPage(). renderPage() expects that all prop building happens in onBeforeRender() or in render(). In order to use VPS like I would a Django template, I need to be able to build the props in my Express/Fastify route handler and just pass them through to VPS.

I'm initially interested in building an HTML-only experience (i.e. no JS) and potentially adding in hydration later on.

Is this possible?

Thanks in advance

brillout · 2022-11-29T10:09:14Z

brillout
Nov 29, 2022
Maintainer

You can define additional pageContent properties: just pass them to renderPage() with pageContextInit.

As for routing, I don't see a rationale for using Express/Fastify instead of VPS. So my recommendation is to use VPS's built-in router unless you have a good reason for not doing so.

2 replies

coryvirok Dec 1, 2022
Author

In order to pass props directly to the page from the middleware/Express/Fastify route, I think you're saying to do the following:

// server.ts - the Fastify app

app.get('*', async(req, reply) => {
  // Determine which page the URL maps to somehow and build the props for that page
  const pageProps = buildProps(req.url)
  const pageContextInit = {
    urlOriginal: req.url,
    customProps: pageProps
  }
  const pageContext = await renderPage(pageContextInit)
  const { httpResponse } = pageContext
  if (!httpResponse) {
    return reply.code(404).type('text/html').send('not found')
  }
  const { body, statusCode, contentType } = httpResponse
  return reply.status(statusCode).type(contentType).send(body)
}

// _default.page.server.js

export async function render(pageContext: PageContextServer) {
  // Pull the page's props (that were built by the Fastify request handler) and stuff them
  // into pageContext so we don't need to have an `onBeforeRender()` method for the page
  pageContext.pageProps = pageContext.customProps

  const app = pageContext.Page.render(pageContext)
  const appHtml = app.html
  const appCss = app.css.code
  const appHead = app.head

  return escapeInject`<!DOCTYPE html>
    ...
  `

// index.page.svelte

<script>
  export let pageProps
</script>
<div>... use pageProps ... </div>

I hope you can agree that there are some problems with the above:

We are duplicating the logic to determine which page maps to which URL
_default.page.server.js is patching the pageContext object with props from the request handler in order to bypass the need to have an onBeforeRender() method.

As for the reasons why it would be useful to build props in the request handler (vs onBeforeRender()):

The bulk of web apps that are running in production right now do it this way. Which means if you want them to adopt VPS, they're going to need to rewrite their request handler to move all of the prop building into onBeforeRender() which is a non-starter. E.g. it's common in Express apps to attach useful data to the request. That data is then used in request handlers to build the data to render the page. If that data is now built in onBeforeRender() it won't have access to the data hanging off the request. Which means you'll need to explicitly add it to the page context for every route.
Determining what to render is already handled on the server via Express/Fastify routing. This means the VPS router is duplicating that logic and is likely less performant than the framework's router. E.g. "every time a page is rendered the Route Functions of all our pages are called and awaited for" from https://vite-plugin-ssr.com/route-function#async. Whereas Express and others have a highly optimized router that does not run every route function before determining what to render.
If I want to plug in a react/Svelte/etc. component into an existing server rendered page in something like an Express with EJS templates app - I want to only render that single component. I know which .tsx file the component lives in and the request handler knows which props it needs. With VPS, there is no way to render the component without going through renderPage().

My suggestion:

Decouple `renderPage()` from `pageContext.Page`

Allow for the middleware/Express/Fastify route handler to directly pass in the path to the Page component, (e.g. const page = resolveComponent('./src/pages/index.page.tsx + renderComponent(page, propsBuiltInExpressRoute).) This would allow folks who already have very large web apps that use Express/Fastify to server render components/pages without needing to use the VPS router.

This would also make integrating with existing frameworks much much easier since there's no need to expose a route like, app.get('*') since rendering of pages is handled in the framework's request handers.

Authentication/route guards are no longer necessary for folks who want to use VPS in this manner. That's already handled by Express/Fastify.

302 redirects can happen in the Express/Fastify handlers instead of in a single place like app.get('*') where we need to pass the redirect URL up through the VPS plumbing from the server-side code that VPS runs, e.g. index.page.server.js.

FWIW, I think this type of change would make it much much easier for folks who have well established codebases that do server rendering to adopt VPS.

brillout Dec 10, 2022
Maintainer

While I agree with the sentiment and motivation here, it's not a completely trivial change to VPS.

If a company wants this, PM me on Discord.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Possible to to render pages directly vs using `renderPage(...)`? #527

{{title}}

Replies: 1 comment 2 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Possible to to render pages directly vs using renderPage(...)? #527

coryvirok Nov 28, 2022

Replies: 1 comment · 2 replies

brillout Nov 29, 2022 Maintainer

coryvirok Dec 1, 2022 Author

My suggestion:

Decouple renderPage() from pageContext.Page

brillout Dec 10, 2022 Maintainer

Possible to to render pages directly vs using `renderPage(...)`? #527

coryvirok
Nov 28, 2022

Replies: 1 comment 2 replies

brillout
Nov 29, 2022
Maintainer

coryvirok Dec 1, 2022
Author

Decouple `renderPage()` from `pageContext.Page`

brillout Dec 10, 2022
Maintainer