docs: update SSR doc to reflect version 17#52398
docs: update SSR doc to reflect version 17#52398alan-agius4 wants to merge 1 commit intoangular:mainfrom
Conversation
0ba0214 to
ddccbfd
Compare
264785b to
9be2db3
Compare
Changes to SSR doc
9be2db3 to
debba30
Compare
josephperrott
left a comment
There was a problem hiding this comment.
LGTM
Reviewed-for: dev-infra
| server.set('views', browserDistFolder); | ||
|
|
||
| // #docregion data-request | ||
| // TODO: implement data requests securely |
There was a problem hiding this comment.
@alan-agius4 just wanted to confirm whether this TODO is intentional.
There was a problem hiding this comment.
This was already there
| // TODO: Enable using Fetch API when disabling `HttpClientInMemoryWebApiModule`. | ||
| provideHttpClient(/* withFetch()*/ ), |
There was a problem hiding this comment.
Should we followup with a fix for HttpClientInMemoryWebApiModule?
cc @JeanMeche
| ## Why is hydration important? | ||
|
|
||
| Hydration improves application performance by avoiding extra work to re-create DOM nodes. Instead, Angular tries to match existing DOM elements to the applications structure at runtime and reuses DOM nodes when possible. This results in a performance improvement that can be measured using [Core Web Vitals (CWV)](https://web.dev/learn-core-web-vitals/) statistics, such as reducing the First Input Delay ([FID](https://web.dev/fid/)) and Largest Contentful Paint ([LCP](https://web.dev/lcp/)), as well as Cumulative Layout Shift ([CLS](https://web.dev/cls/)). Improving these numbers also affects things like SEO performance. | ||
| Hydration improves application performance by avoiding extra work to re-create DOM nodes. Instead, Angular tries to match existing DOM elements to the applications structure at runtime and reuses DOM nodes when possible. This results in a performance improvement that can be measured using [Core Web Vitals (CWV)](https://web.dev/learn-core-web-vitals/) statistics, such as reducing the First-contentful paint [FCP](https://developer.chrome.com/en/docs/lighthouse/performance/first-contentful-paint/) and Largest Contentful Paint ([LCP](https://web.dev/lcp/)), as well as Cumulative Layout Shift ([CLS](https://web.dev/cls/)). Improving these numbers also affects things like SEO performance. |
There was a problem hiding this comment.
| Hydration improves application performance by avoiding extra work to re-create DOM nodes. Instead, Angular tries to match existing DOM elements to the applications structure at runtime and reuses DOM nodes when possible. This results in a performance improvement that can be measured using [Core Web Vitals (CWV)](https://web.dev/learn-core-web-vitals/) statistics, such as reducing the First-contentful paint [FCP](https://developer.chrome.com/en/docs/lighthouse/performance/first-contentful-paint/) and Largest Contentful Paint ([LCP](https://web.dev/lcp/)), as well as Cumulative Layout Shift ([CLS](https://web.dev/cls/)). Improving these numbers also affects things like SEO performance. | |
| Hydration improves application performance by avoiding extra work to re-create DOM nodes. Instead, Angular tries to match existing DOM elements to the applications structure at runtime and reuses DOM nodes when possible. This results in a performance improvement that can be measured using [Core Web Vitals (CWV)](https://web.dev/learn-core-web-vitals/) statistics, such as reducing the First Contentful Paint [FCP](https://developer.chrome.com/en/docs/lighthouse/performance/first-contentful-paint/) and Largest Contentful Paint ([LCP](https://web.dev/lcp/)), as well as Cumulative Layout Shift ([CLS](https://web.dev/cls/)). Improving these numbers also affects things like SEO performance. |
| After starting the dev-server, open your web browser and visit `http://localhost:4200`. | ||
| You should see the familiar Tour of Heroes dashboard page. | ||
|
|
||
| Navigation using `routerLinks` works correctly because they use the built-in anchor \(`<a>`\) elements. |
There was a problem hiding this comment.
| Navigation using `routerLinks` works correctly because they use the built-in anchor \(`<a>`\) elements. | |
| Navigation using `routerLinks` works correctly because they use standard anchor \(`<a>`\) elements. |
| You can seamlessly move from the Dashboard to the Heroes page and back. | ||
| Additionally, clicking on a hero within the Dashboard page will display its Details page. | ||
|
|
||
| If you throttle your network speed so that the client-side scripts take longer to download \(instructions following\), you'll notice: | ||
|
|
||
| - You can't add or delete a hero | ||
| - The search box on the Dashboard page is ignored | ||
| - The _Back_ and _Save_ buttons on the Details page don't work | ||
|
|
||
| The transition from the server-rendered application to the client application happens quickly on a development machine, but you should always test your applications in real-world scenarios. | ||
|
|
||
| You can simulate a slower network to see the transition more clearly as follows: | ||
|
|
||
| 1. Open the Chrome Dev Tools and go to the Network tab. | ||
| 1. Find the [Network Throttling](https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#throttling) dropdown on the far right of the menu bar. | ||
| 1. Try one of the "3G" speeds. | ||
|
|
||
| The server-rendered application still launches quickly but the full client application might take seconds to load. |
There was a problem hiding this comment.
I'd propose dropping this altogether. It's a bit confusing that it's a part of the tutorial steps.
This is a pre-existing content, but I think we can drop this part.
There was a problem hiding this comment.
+1 to dropping. If the intent is to demonstrate that SSR is working, maybe point people at view source instead (or the network response for index.html).
If we really want to keep this, I suggest at least swapping the order. Simulate the slower network first and then talk about the effects on the application. Otherwise it's tricky to understand what's trying to be communicated here.
|
Caretaker note: there are some minor comments, but we'll address them in a followup PR. This PR is ready for merge. (the presubmit is not required, there are only docs-related changes) |
jessicajaniuk
left a comment
There was a problem hiding this comment.
LGTM
I think we'll want to revisit after v17 though and see what really should just be rewritten.
|
This PR was merged into the repository by commit cb8a741. |
Changes to SSR doc PR Close #52398
dgp1130
left a comment
There was a problem hiding this comment.
Lots of minor suggestions. I don't think anything here is blocking I just wanted to write them down as I saw them. We can follow up on any of these after v17 is necessary to hit the freeze.
| When integrated with an app, Universal generates and serves static pages on the server in response to requests from browsers. | ||
| The initial static page serves as a fast-loading placeholder while the full application is being prepared for normal execution in the browser. | ||
| To learn more, see [Angular Universal: server-side rendering][AioGuideUniversal]. | ||
| To learn more, see [Angular server-side rendering][AioGuideSSR]. |
There was a problem hiding this comment.
I think we need to rewrite this for a Universal-less world. Maybe something like:
Server-side rendering
A strategy for rendering application HTML on the server during the initial page load. A server-side rendered initial page serves as a fast-loading placeholder while the full application being prepared for normal execution in the browser. To learn more, see [Angular server-side rendering][AioGuideSSR].
| To avoid this error, a [lifecycle hook][AioGuideLifecycleHooks] method that seeks to make such a change should trigger a new change detection run. | ||
| The new run follows the same direction as before, but succeeds in picking up the new value. | ||
|
|
||
| ## Universal |
There was a problem hiding this comment.
Glad to see we're updating this to favor "SSR", however I think the glossary is the one place we'd still want to leave an artifact of "Universal" just for historical reasons (like "Ivy" and "View Engine"). Could be something like:
Universal
A community-driven project for supporting server-side rendering and static-site generation in Angular prior to version 17. Starting at v17, Universal features were folded into Angular's built-in SSR support and Universal is no longer needed.
| You can seamlessly move from the Dashboard to the Heroes page and back. | ||
| Additionally, clicking on a hero within the Dashboard page will display its Details page. | ||
|
|
||
| If you throttle your network speed so that the client-side scripts take longer to download \(instructions following\), you'll notice: | ||
|
|
||
| - You can't add or delete a hero | ||
| - The search box on the Dashboard page is ignored | ||
| - The _Back_ and _Save_ buttons on the Details page don't work | ||
|
|
||
| The transition from the server-rendered application to the client application happens quickly on a development machine, but you should always test your applications in real-world scenarios. | ||
|
|
||
| You can simulate a slower network to see the transition more clearly as follows: | ||
|
|
||
| 1. Open the Chrome Dev Tools and go to the Network tab. | ||
| 1. Find the [Network Throttling](https://developers.google.com/web/tools/chrome-devtools/network-performance/reference#throttling) dropdown on the far right of the menu bar. | ||
| 1. Try one of the "3G" speeds. | ||
|
|
||
| The server-rendered application still launches quickly but the full client application might take seconds to load. |
There was a problem hiding this comment.
+1 to dropping. If the intent is to demonstrate that SSR is working, maybe point people at view source instead (or the network response for index.html).
If we really want to keep this, I suggest at least swapping the order. Simulate the slower network first and then talk about the effects on the application. Otherwise it's tricky to understand what's trying to be communicated here.
|
|
||
| | Properties | Details | Default Value | | ||
| | --------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------- | | ||
| | _`bootstrap`_ | A method that when invoked returns a promise that returns an `ApplicationRef` instance once resolved or an `NgModule`. | | |
There was a problem hiding this comment.
Suggestion: "returns a promise that returns an X instance once resolved" is pretty wordy. Maybe we can do something like:
A method which resolves an X
A method which returns a promise which resolves to an X
A method which returns a
Promise<X>.
As written, it's also unclear if this means Promise<ApplicationRef> | NgModule or Promise<ApplicationRef | NgModule>. It sounds like the former in the doc, but I think it's actually the latter?
|
|
||
| | Properties | Details | Default Value | | ||
| | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------- | | ||
| | _`bootstrap`_ | A method that when invoked returns a promise that returns an `ApplicationRef` instance once resolved or an `NgModule`. | | |
There was a problem hiding this comment.
Question: Do we accept bootstrap in both the constructor and the render function?
|
@alan-agius4 FYI, we've updated the |
|
@alan-agius4 will you cover how to correctly run ssr server for multiple i18n? We need working examples :) |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Changes to SSR doc PR Close angular#52398
Changes to SSR doc