Skip to content

Add a boolean to mark prerenderable routes #14493

Description

@Beyondo

Describe the problem

Hello! Inside my +layout.server.ts, I load a Cloudflare service binding stored in platform.env.backend to later make RPC calls from +page.ts in SSR contexts because we all know bindings cannot be accessed in universal loads directly. So this was the simple workaround.

The previous context aside to not confuse anyone, the actual problem is when the request comes from a prerendered route, say /, the following error is thrown inside my +layout.server.ts where I do the initialization:

[500] GET /
Error: Cannot access platform.env.backend in a prerenderable route

So I think it's necessary that we've a prerenderable boolean at least, say passed inside event.route so that you'd simply pre-check event.route.prerenderable to prevent accessing a service binding from there. Or even as a meta property such as import.meta.env.PRERENDERABLE if it makes more sense there.

Otherwise, SK devs just cannot avoid that error without 'hacks' such as the two workarounds below.

Describe the proposed solution

We need either something such as this:

event.route.prerenderable

Or this

import.meta.env.PRERENDERABLE

Alternatives considered

I got two workarounds.

First approach (Manual tracking):

// +layout.server.ts
import { load_backend_service } from "$lib/server";

const prerenderable_routes = [
    "/",
];

export async function load(event) {
    if (event.platform && !prerenderable_routes.includes(event.url.pathname)) {
        load_backend_service(event.platform); // event.platform.env.backend binding (Cloudflare Worker)
    }
}

Second approach (Ignore the error):

import { load_backend_service } from "$lib/server";

export async function load(event) {
    try {
        if (event.platform) {
            load_backend_service(event.platform); // event.platform.env.backend binding (Cloudflare Worker)
        }
    } catch { /* prerendering error ignored */ }
}

Second approach is nicer of course which is what I'm currently using, but I do think Svelte having a graceful condition would be a bit better than making a design practice out of ignoring errors in my opinion.

Importance

nice to have

Additional Information

I just think that it doesn't make sense for Svelte to know that a route is prerenderable while the developer is unaware of it and incapable of checking that truth.

But this is by no means a serious issue at all, and I also apologize if the flag already exists in some form despite attempting my best to search the docs beforehand.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions