Mark route as "ssr only"

[tomyan]

Describe the problem

It's currently possible to ensure that a route is server rendered by adding the rel="external" attribute to any links to it. It would be convenient to configure this once in the page that should always be server rendered. A use-case for this is a page that needs to set a cookie (e.g. once #909 is implemented). In my case I have a /login route that does this (sets a cookie and redirects to an OpenID Connect provider). At the moment I implement this as an endpoint, but this isn't ideal as if something goes wrong it would be difficult to ditch the redirect and render a page that explains the error to the user.

Describe the proposed solution

I'm not too sure how it would be implemented (happy to help if I can, but I think #909 might be more tractable for a beginner like me). There's another problem I've come across that endpoints are not server rendered by default (I've also used rel="external" to work around this issue - seems like the solution to this would be similar.

Alternatives considered

I can use an endpoint to work around this limitation (or perhaps hooks) but it won't handle errors as well (or be as convenient).

Importance

would make my life easier

Additional Information

No response

[rmunn]

At the moment I implement this as an endpoint, but this isn't ideal as if something goes wrong it would be difficult to ditch the redirect and render a page that explains the error to the user.

One thing you might be able to do right now, without waiting for a new feature to be implemented, would be to have your /login endpoint redirect to one of two places:

• Success: redirect to OpenID Connect provider
• Failure: redirect to /login-error?errorCode=what-went-wrong

And then your /login-error route is a page, not an endpoint. It would use the load function to take the error code from the query, look up an appropriate human-readable error (or if you have your site translated into multiple languages, the appropriate translation for that error message), and render a nice explanation of the error.

Alternately, so as to not have a different error page for everything, redirect to /error-page?errorFrom=/login&errorCode=what-went-wrong, and then the error-page might look at errorFrom and decide which layout component to load to render the error text, so that the layout of the error looks similar to the layout of the page you came from. Whether that's a better alternative kind of depends on your site and how it's designed.

[benmccann]

We might be able to solve this with routing hooks when we implement those (#552)

[Rich-Harris]

#909 isn't going to be implemented. Now that we have page endpoints, I think the set-cookie case is easy enough to implement (with redirect/error handling 'for free') that I reckon we can probably close this issue, unless there are other use cases for SSR-only pages?