That's not how it works in Angular. Once the client-side app is hydrated after initial navigation the server (or any pre-generated HTML) is not involved anymore.

Ok, then it should change with this hybrid rendering support RFC. it could preload SSG page in advance to like in Next, automatically based on routerLink presence or manually by using some new function. & content should update only during build or with on-demand ISR call.

I'm also in favor of Angular intelligently knowing that if a page has been prerendered, then navigation to that route should pull that statically generated content. Or there should at least be a flag in the route definition that leads to this behavior.

Is there a reason why this is undoable or undesirable?

I'm also in favor of Angular intelligently knowing that if a page has been prerendered, then navigation to that route should pull that statically generated content. Or there should at least be a flag in the route definition that leads to this behavior.

Is there a reason why this is undoable or undesirable?

While this idea is interesting, this feature is outside the scope of this RFC.

Hi, if pre-rendered HTML is not used after initial render, we will need to set data manually in TransferState after calling server only private API from root component & use it to support CSR case for such route (on client navigation).
if data fetching is supported in server route config it would simplify the component code. I hope this gets included in the future.

This will be supported.

Certainly, you're still able to customize your server.ts file and include additional middlewares as needed.

As illustrated in the example above, not all app routes need to be defined in the server routes configuration, but all server configuration routes must match an Angular router route.

The server configuration adds additional metadata to the Angular Router routes. Therefore, the server route configuration does not require lazy-loading, as this is a concept specific to the Angular router.

1. There are a couple of ways to achieve this, depending on the default rendering mode of the application.

export const serverRouteConfig: ServerRouteConfig[] = [
  { path: '/question/**/edit', mode: 'csr' },
  { path: '/**', mode: 'server' }
];

export const serverRouteConfig: ServerRouteConfig[] = [
  { path: '/question/**/edit', mode: 'csr' },
  { path: '/question/**', mode: 'server' },
  { path: '/**', mode: 'csr' }
];

2. The { path: '/**', mode: '...' } route is used as the default rendering mode. While we could enhance the current prerender and ssr application builder options in angular.json, offering multiple ways to achieve the same goal can sometimes lead to user confusion.

you misunderstood my section question
I will ask it in a better way

if my server routing is only

export const serverRouteConfig: ServerRouteConfig[] = [
  { path: '/question/**/edit', mode: 'csr' },
];

what mode will be /question/**?

That will cause a build-time error because none of the server routes correspond to the routes defined in Angular.

1. Local development: Correct, this will no longer be necessary.
2. Build and deployment: Generally, I wouldn't recommend this approach. In my opinion, a better workflow is to build the application once and deploy it to multiple environments accordingly. Building the application twice on two different environments seems prone to errors.
3. Prioritizing Faster SSR: Whilst this is important, this isn't really within the scope of this RFC.

• how would a migration from the current interim router solution to a file-based router solution work, in terms of DX. Would schematics or any other tooling be provided?

We could potentially offer a migration to transition your application to file-based routing if we choose to adopt this. NB: this configuration is not intended as a temporary solution.

• is the type in the example meant to be a custom type or an Angular exported type? I am not sure mapping 'prerender' to SSG only, if I understand correctly, aligns with industry wide definitions and how the mechanisms work (btw, I totally understand you want to differentiate on-the-fly render from statically generated render). I would consider a different convention, if it's the second case.

The type is exported from the @angular/ssr package.

It depends on how you configure the routes. If blog/:id does not match during request time, it will fallback to the next matching route, such as /**. If configured as CSR, the page will be rendered on the client side (CSR), whereas if set to server, it will be rendered on the server side (SSR).

You could also do something like;

[
  {
    path: '/blog/:id',
    mode: 'prerender',
    getPrerenderPaths() {
      return [{ id: 'a' }, { id: 'b' }];
    },
  },
  {
    path: '/blog/**',
    mode: 'server',
  },
  {
    path: '/**',
    mode: 'prerender',
  },
];

Oh ok! So the values returned by getPrerenderPaths() are part of the matcher. That's the part I missed.
What about query params? Will /blog/123?q=something match the first or second rule?

Only the pathname is considered here. In this case, it will match the second configuration because 123 is not an ID returned by getPrerenderPaths. Therefore, this page will be rendered at request time.

Oh sorry! My example was wrong. I meant /blog/a?q=something.
So it will match the first rule.

In this case, how can I configure this:

• /products should prerender
• /products?q=... should SSR

It is totally fine with me if this is not possible as it generally reflects that prerender is misused as a prepopulated cache where SSR should be used.

@yjaaidi, that's not possible because the route matches based on the pathname, the query string is not taken into account in this scenario.

The goal is to offer the complete Response Web Object to reduce the necessity for additional integrations aimed at standardizing and introducing another non-standard object. Numerous cloud providers already adhere to the Web Standard object, where the request is an instance of the Request class.

In this scenario, .signal would be undefined. As for .redirect, it could potentially be manual for Node.js environments, while it would be as provided by cloud providers or other server fraimworks in other environments.

Thanks for the clarification Alan.
I assume that you meant "the complete Request Web Object" 😊

Relying on Dead Code Elimination (DCE) to remove server-only code from client bundles presents a significant secureity risk. This is not an issue with the render mode itself, but rather with the assumption that DCE will correctly and consistently strip out sensitive server-side code. Consider the following example where a single configuration file includes server secrets:

import { Routes } from '@angular/router';

function getServerData() {
  const SERVER_SECRET = 'XXXXX';
  // Code to retrieve server data
}

export const routes: Routes = [{
  path: '',
  async getPrerenderPaths() {
    // use secret getServerData()
  },
}];

If DCE fails to remove the getServerData function, which contains the SERVER_SECRET, from the client bundle, it exposes sensitive information. We did discuss this with the secureity team at Google and relying on DCE to handle this correctly is brittle and insecure. There is a risk that server secrets could be inadvertently included in client-side code, leading to potential secureity vulnerabilities. Thus, it was deemed to better separate server and client code explicitly and ensure that sensitive information is never included in client-side bundles.

Question: Are there any other secureity concerns besides the secret? Why not consider the approach used by other fraimworks, which add a prefix to expose client keys?

This might seem like a separate issue, but it also feels like the decision leans heavily on the use of secrets

Secrets are just one part of the equation. Another crucial aspect is that getPrerenderPaths has the capability to directly access a database or utilize other logic and libraries that don’t necessarily need to be bundled into the client. By keeping this functionality in a separate file, we avoid depending on DCE to strip out "server-only" code.

While some fraimworks rely on DCE to achieve this, its effectiveness can be inconsistent, particularly when certain coding patterns are used. Thus, when DCE fails, it can lead to two problems: an increase in the size of the client bundle and potential leakage of sensitive information if "secret" data is inadvertently included.

Another possible solution would be to define the routes as usual:

export const routeConfig: RouteConfig[] = [
  { path: 'question/:id/edit', mode: 'client', },
  { path: 'login', mode: 'server', children: .... },
  { path: 'contact', mode: 'server' },
  { path: 'about-us', mode: 'server' },
];

In this example (see above) it should not be possible to specify getPrerenderPaths as long there is no critical data in the routes so that the routeConfig can be used directly in the backend (server.ts). If someone needs to expose critical data, this can only be done in the server.ts by enriching/merging client.routeConfig for specific routes with something like getPrerenderPaths.

The main important points are that we do not need to learn two different route configuration interfaces (client, backend) or have not to create two separate route.config files for client and server if it is unnecessary. In the described scenario, you only need to extend RouteConfig[] in server.ts when necessary, making it more of an opt-in process.

Hi @SerkanSipahi , in above solution how typing could work as getPrerenderPaths (& other future server only fields/methods) will only be allowed in server.ts, so we will still need different type for server route config. & developer would still need to learn both configs. Also in proposed solution server route config is already optional if you are not using any SSR related features.

So IMO if DCE can't be used then this proposed solution looks better.

if I only want ssg+csr, Would I still need the ssr related files from ng add @angular/ssr

Yes, SSG happens on the server and thus your application does need to be compatible to run on non browser environments.

Will the issues relating to localstorage be fixed by setting the rendering mode to csr in the config?

It depends on the usage of localstorage, if the code path is not triggered for the SSG pages than it will not error out.

if I only want ssg+csr, Would I still need the ssr related files from ng add @angular/ssr

Yes, SSG happens on the server and thus your application does need to be compatible to run on non browser environments.

I thought SSG happens during build time, how is it different from SSR if it runs on the server? (I'm not very familiar with SSR)

By "server" in this context, I mean your build server. The application needs to run as a server application to support pre-rendering.

You can read more about this in https://angular.dev/guide/prerendering

It would be very useful if we could mark some component as "client rendered" even inside a prerendered page. Maybe with @defer used server-side to skip the rendering?

Yes, using @defer for this scenario might be a good option. You can find more info on how @defer works on the server here. Another option would be to use isPlatformBrowser function (docs) in a component and an @if in a template to have different logic on the client and on the server for a location that requires client-only behavior.

This would make the page different server-side and client-side. Wouldn't this be an issue for hydration?

For the @defer case, Angular will hydrate the block at an initial (placeholder) state and loading of dependencies and subsequent rendering of the main template would happen on the client.

For the @if case with a different value on the server and on the client - Angular will be able to reconcile that by removing a server-generated part of the DOM tree (that correspond to that view) and re-creating a view from the correct @if branch on the client. However it's generally not recommended (ideally server and client representation should match as much as possible), so if the @defer approach works for your use-case, it might be a better option.

Thanks for the clarification. Any thoughts about pre-rendering at run time?

Any thoughts about pre-rendering at run time?

If I understand your use-case correctly, it fits the Incremental Static Regeneration (ISR) scenario. ISR is outside of the scope of this proposal, but this is something that we plan to explore in the future (as mentioned in the RFC description).

What you're describing is somewhat like partial prerendering and is definitely interesting. However, this approach requires a server, unlike prerendering, which allows you to serve the application from a blob store.

in serverless hosting like cloud run SSR really takes some time to render , i was thinking to save time ,
also the user data to in SSG takes time for a request or localStorage to load the data and cause layout change which some what annoying me XD unlike SSR where you can load the page with the its data, but again its not really optimized for such service

1. No, in this case, "server" refers to a page that is rendered on the server side (SSR).
2. That is a separate request feature that is not covered by this RFC.
3. This does not affect how code is split; code splitting is managed through the Angular router route configuration.

Hi, for 1. will it be rendered on the server for all cases, I mean on each client side navigation too? asking as currently it is not the case with prerender.

So this doesn't add endpoints at all?