I still strongly believe that this should be appended in platform-server instead.

platform-server doesn't know in which context the module is being rendered and I don't think it should. It shouldn't matter if we are rendering an app-shell, SSG or SSR page.

platform-server doesn't know in which context the module is being rendered and I don't think it should. It shouldn't matter if we are rendering an app-shell, SSG or SSR page.

You're correct, but that doesn't mean it shouldn't be responsible for marshaling the change into the DOM with consistency and ubiquity. App shell still means there was pre-rendering done, which is useful guidance for us. Universal can then override this string to be more specific based on the use case.

Hi team! We plan to collect some stats from the HTTPArchive and it'd be great to have an ability to identify sites that used SSR or SSG. This change would be super helpful to achieve this. Just wanted to ask if there are additional discussions/reviews that should happen or we can land the change as is and refactor later if needed? Thank you.

In discussions offline, we realized that to get the coverage that we need on reporting metrics, we need this string to be populated by default in platform-server, and then configurable by runtime (e.g. express-engine, app-shell, etc). Anything less than that would create gaps in reporting for those that roll their own rendering solution without the Angular Universal engines.

As @CaerusKaru pointed out this can create gaps for applications not using the NgUniversal but calling the renderModule directly. I am still not conceived that given control to the user is the right thing to do here. As we'd rely on the users to set the right thing and it would extended the unnecessary the API for something that the renderer doesn't need.

Maybe something like

<meta property="ng:page-mode" content="SSR/SSG/CSR/Unset" />

or

<aio-shell ng-version="13.2.2" ng-page-mode="SSR/SSG/Unset">

That said, at the moment from Web archive we can identify if an Application is using SSG.

It's also important to point that in an application you can have a hybrid approach were certain pages are SSG and others are SSR

Thanks for the replies!

I noticed that there is a new PR created by @CaerusKaru that adds a special token: angular/angular#46887. @alan-agius4 I was wondering if it might be ok to have that special token created in angular/angular#46887, but keep it private (by prefixing with ɵ, i.e. ɵSERVER_CONTEXT), so it can be leveraged in NgUniversal without declaring it as a public API. WDYT?

If the API is private, there is no real reason why the API should be provided by the platform-server IMHO. As users using directly renderModule and renderApplication will not be able to provide the context.

I am still not trilled to put this in platform-server as we have control over the index.html and the context is not used by the framework as its only used for runtime stats.

For the FW, it doesn't matter if the page is SSR, SSG or AppShell.

--

I will reply in the linked PR as a DI token is problematic in this case.

@alan-agius4 we've landed a PR on the platform-server side to be able to pass a document reference: angular/angular#47032, but it'd be released in a few weeks (in 14.2.0) from now and would require some extra changes on the NgUniversal side (to parse the DOM). I was wondering if we can update this PR and use a similar approach (string replacement) to add a <meta> tag before a closing </head> tag for now, WDYT?

yeah we can do that as an interim solution.

Superseded by #2846

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}