When I load the application initially all data passed into my components (i.e. header, router-outlet, footer) is rendered. In this case I expect to see links generated from an api in the footer.
More often than not, I see a commented out html line where I expect to see the async data. But right after I reload, I see the data. This is unacceptable because the sole reason for using Angular-Universal (SSR) is for SEO crawl.
- [x ] aspnetcore-engine
- [ ] common
- [ ] express-engine
- [ ] hapi-engine
- [ ] module-map-ngfactory-loader
SEO Crawl.
@nguniversal versions
<!--
Output from: `ng --version`.
Angular CLI: 1.7.0
Node: 8.11.3
OS: win32 x64
Angular: 5.2.5
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, platform-server, router
@angular/cli: 1.7.0
@angular-devkit/build-optimizer: 0.3.1
@angular-devkit/core: 0.3.1
@angular-devkit/schematics: 0.3.1
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.0
@schematics/angular: 0.3.1
@schematics/package-update: 0.3.1
typescript: 2.5.3
webpack: 3.11.0
If nothing, output from: `node --version` and `npm --version`.
Windows (7/8/10). Linux (incl. distribution). macOS (El Capitan? Sierra?)
-->
Project was created from asp.net core SDK 2.1.302. Leveraging TransferState.
If I understand correctly I am seeing the same behavior. I am actually using Javascript and not aspnet.
The first call to my app will not render any async data in the page returned, the TransferState is empty and my resolvers do not get called. Any subsequent calls will render everything server side as expected.
I am also in the same boat as you. I am only doing server side rendering for SEO. Additionally, I am running on AWS lambda, so it is not necessarily just the first call that will have this problem since lambda could launch new instances on any call.
Shot in the dark, but are your HTTP requests using absolute URLs? Otherwise, we will need a minimal reproduction repository to investigate.
I am experiencing the same issues. I posted a SO question with the relevant files here: https://stackoverflow.com/questions/54245667/angular-universal-7-not-making-http-calls
However, if I get a chance tomorrow, I will attempt to create a public repro of the issue. I can tell you that the app I am experiencing this with does not have any strange implementations, and just a simple httpClient.get call will return an error of [Error] because the call is cancelled.
@CaerusKaru I got bored and did it tonight.
Here's a project which will repro the issue in as simple a circumstance as I could make. I left a few bells and whistles from my target app, in case they were causing the problem, but also added test cases without them to rule them out.
https://github.com/swimmadude66/ngUniversal-http-repro
I've added repro steps in the README, but I will restate them here, just in case:
npm install, then npm run buildssr, then npm start. Once Ready and listening is logged, the app will be available at http://localhost:3000
The 2 pages are on / and /numbers. Root loads a message from the API (directly, and through my http cache I use in the app with a problem). /numbers will load numbers from the api, and concatenates them. Those numbers are loaded from a resolver, which returns an observable of the results.
The cache service uses local/session storage in the browser, or the TransferState in the server.
Visiting either of these pages on a fast internet connection and in a browser will yield a working app. However, if you curl the pages or fetch from postman, the html generated will have empty elements where the API responses should be. Additionally, if you watch the terminal, the error handler picks up an [Error] from the api call on the page, and another error when trying to report that error to the server. Logging either of these with Json.stringify will yield {}
Here's hoping this is enough to nail down what's wrong!
In your example, change the SSR interceptor not to use Object.assign. Use request.clone({url: fullUrl}) instead.
I'll give the OP or someone else another day to come up with a reproduction of the original issue before this is closed. (We can always reopen if you come up with one later).
WOW. When I change that one line, it suddenly works. I cannot believe how long I have spent on this issue. The only catch now appears to be that cookies do not transfer with the subsequent requests, so I will have to figure out some way to solve that.
Thank you so much, and I hope this helps others! Any chance you happen to know why request.clone works where Object.assign does not? It seems like they should be doing essentially the same thing (and I even saw people recommending the 2 equally in other guides) but obviously they do not. At this point its just for morbid curiosity if nothing else!
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._
Most helpful comment
In your example, change the SSR interceptor not to use
Object.assign. Userequest.clone({url: fullUrl})instead.