index.html formatting breaks Universal SSR

dottodot commented 6 years ago

Versions

Angular CLI: 1.6.1
Node: 8.9.1
OS: darwin x64
Angular: 5.1.1
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, platform-server, router
... service-worker

@angular/cli: 1.6.1
@angular-devkit/build-optimizer: 0.0.36
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.42
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.1
@schematics/angular: 0.1.11
typescript: 2.4.2
webpack-bundle-analyzer: 2.9.1
webpack: 3.10.0

Repro steps

Build the app

Observed behavior

After building the app and starting the express app and I can see I not getting SSR content. However if I open the compiled index.html and save it it Visual Code so that the html is formatted again the problem goes away. This suggests that the build process is somehow formatting the html in a way that's causing the issue, but I don't get any errors.

Also the other odd thing is if I removed the Service Worker I don't get the issue so I initially though that was the problem as reported here https://github.com/angular/angular/issues/20890

Desired behavior

Be able to include build app and have SSR.

I'm just very confused as to how the combination of the formatted html and service worker can be preventing ssr working.

Mention any other details that might be useful (optional)

I've tried removing all additions to my index.html to make sure nothing I've added causes the issue. I've only recently started having this issue but can't be sure of which version.

asadsahi commented 6 years ago

@alxhub read some discussion in this thread which is closed, However, I am having similar issue as described here. On first SSR load i get complete html (below)

first-load-html.txt

Subsequent page loads are cached:

But the html is trimmed down. (below): trimmed-html.txt

This is ngsw.json after build. ngsw.json.txt

Here is another important question, if server rendered pages are loaded from server, then should these pages be cached by service worker? Any best practice of caching SSR documents in the context of service worker?

dottodot commented 6 years ago

Yes that was my issue that I posted in the main angular repo, not sure why it was closed without any explanation. Anyway after that I then discovered that I can get both ssr and service worker working together simply by reformatting the generated index.html, which is why I've posted in cli as wondering if something in the build process is causing the issue.

So after building my app my index.html looks like

<!doctype html><html lang="en"><head><meta charset="utf-8"><title></title><base href="/"><meta name="viewport" content="width=device-width,initial-scale=1"><link rel="icon" type="image/x-icon" href="/favicon.ico"><link rel="manifest" href="./manifest.json"><meta name="theme-color" content="#3e3935"></head><body><bos-root class="site"></bos-root><script type="text/javascript" src="inline.f6b500976c47223e609b.bundle.js"></script><script type="text/javascript" src="polyfills.948979b9d906d248bcd3.bundle.js"></script><script type="text/javascript" src="main.421aaf9b0deca09e5fdd.bundle.js"></script></body></html>

and I don't get any ssr with a service worker, but if I format that index.html to

<!doctype html>
<html lang="en">

<head>
    <meta charset="utf-8">
    <title></title>
    <base href="/">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link rel="icon" type="image/x-icon" href="/favicon.ico">
    <link rel="manifest" href="./manifest.json">
    <meta name="theme-color" content="#3e3935">
</head>

<body>
    <bos-root class="site"></bos-root>
    <script type="text/javascript" src="inline.f6b500976c47223e609b.bundle.js"></script>
    <script type="text/javascript" src="polyfills.948979b9d906d248bcd3.bundle.js"></script>
    <script type="text/javascript" src="main.421aaf9b0deca09e5fdd.bundle.js"></script>
</body>

</html>

my service worker works and so does ssr. I just can't understand why that would be. I absolutely mystified as the only difference is one is minified html.

asadsahi commented 6 years ago

@dottodot what you have shown seems to be the prod build index.html. which doesn't look like and SSR generated source.

If you look at the first file I sent above that has alot of source come from SSR and after service worker caches that source, it caches trimmed version, which is issue in my case.

I am also not sure if it is a good idea to cache index.html with service worker if we are using SSR since each url might have different source rendered from server and there might now be much gain we get from performance standpoint by caching index.html if it is SSR rendered already.

dottodot commented 6 years ago

@asadsahi yes it is the prod build index.html. My point was that if I format that generated index.html as I've shown the problem goes away. Also removing the index.html from the service worker also resolves my issue, so maybe the best approach is to not cache the index.html at least until someone can confirm if this is a bug or if index.html just shouldn't be included when using a service worker with universal.

asadsahi commented 6 years ago

@dottodot what is confusing me is that you are stating your problem with html file which doesn't look like SSR generated source

This source has app component selector, but I am expecting if this is SSR source this should be the pre-rendererd output instead.

Note: This is not ssr source.

<!doctype html>
<html lang="en">

<head>
    <meta charset="utf-8">
    <title></title>
    <base href="/">
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link rel="icon" type="image/x-icon" href="/favicon.ico">
    <link rel="manifest" href="./manifest.json">
    <meta name="theme-color" content="#3e3935">
</head>

<body>
    <bos-root class="site"></bos-root>
    <script type="text/javascript" src="inline.f6b500976c47223e609b.bundle.js"></script>
    <script type="text/javascript" src="polyfills.948979b9d906d248bcd3.bundle.js"></script>
    <script type="text/javascript" src="main.421aaf9b0deca09e5fdd.bundle.js"></script>
</body>

</html>

Therefore, if you are saying you are having problem with service worker in the context of SSR then what service worker should cache is whatever server sent to client. If SSR, it should be final output of the page, if it is non-ssr then it should be source above.

dottodot commented 6 years ago

Yes I know, I'm trying to explain what I think is causing SSR to not work, which I believe is the index.html file, this is why posting the contents of the generated file not ssr generated source.

If you forget about the html I've posted, it's a simple as with the index.html included in the service worker ssr doesn't work. If I've remove the index.html from the service worker ssr works.

asadsahi commented 6 years ago

Right, So the very first time you get source from server is SSR generated source (i.e before service worker caches it)? If that is the case then it surely is something wrong with how Service worker caches that page.

Original question still begs some explanation from some expert, "Whether we should cache SSR page in service worker?" :)

hansl commented 6 years ago

Hi @dottodot

I don't see a reproduction for your issue. Could you provide a github repo we could clone and look at? It should contain the smallest amount of code (as close as a new app) as possible.

Thanks!

dottodot commented 6 years ago

@hansl unfortunately I've been unable to replicate in a new app, so probably something particular to my setup. Trouble is as there is no errors so it could be anything and not sure how I can narrow it down.

asadsahi commented 6 years ago

@hansl would you be able to comment on question I have asked here?

ssatz commented 6 years ago

@dottodot : Experiencing the same issue. I have enabled Service worker and Angular universal but however when viewing the view source only angular tags are there.

As you stated when i format the index.html , this seems to be perfectly working. Very Strange ! I thought i am the one Experiencing the weird issue. I am using @angular/cli Version 1.6.1.

Have you solved it?

dottodot commented 6 years ago

@ssatz Unfortunately not, I suspect there will be more as there is no error and you only find out when you check the view source.

ssatz commented 6 years ago

Hello All, Please find the repository to reproduce the bug. https://github.com/ssatz/Angular-SSR-Service-Worker

Build SSR using NPM and view the view source.

geometricpanda commented 6 years ago

Yeah I’ve found the same When visiting my app without the service worker, installed, I’m seeing the SSR instead of the built index.html, as expected. The service worker then gets installed by the browser. I then revisit my app and now when I view source it’s the SPA build of index.html not the SSR.

My gut instinct is telling me that during the build possibly, the SPA version of index.html is getting packaged into the js, and that the service worker is caching that, instead of caching the SSR html.

My expectation would be that the SSR html would be cached in the SW.

kaikcreator commented 6 years ago

Same issue here. Any news about that? I've removed index.html from the SW cache in the meanwhile in order to get SSR.

asadsahi commented 6 years ago

I am guessing removing index.html will remove offline capability from PWAs since index file isn't cached anymore.

kaikcreator commented 6 years ago

Yes, you're right. But if I don't remove index.html from cache, then SSR doesn't work. I've trying by formatting the index.html file as suggested by @dottodot and @ssatz, but in my case it doesn't work neither.

Until this issue is fixed, there's no win-win solution here: Or I lose offline capabilities, or I lose SSR capabilities :(

quen2404 commented 6 years ago

I have the same issue... Any news ?

Priemar commented 6 years ago

Hey guys,

after investigating some hours, i want to share my results. (feel free to correct me if im wrong)

my setup:
angular cli 6.0.1

service worker
ssr (angular universal)
i used the smallest setup for ngsw-config.json

{
  "index": "/index.html",
  "assetGroups": [{
    "name": "app",
    "installMode": "prefetch",
    "resources": {
      "files": [
        "/favicon.ico",
        "/index.html",
        "/manifest.json",
        "/*.css",
        "/*.js"
      ]
    }
  }, {
    "name": "assets",
    "installMode": "lazy",
    "updateMode": "prefetch",
    "resources": {
      "files": [
        "/assets/**"
      ]
    }
  }]
}

FYI: i think formatting the index.html is not the reason why the ssr, etc. doesnt work as expected.

How it works under the hood:

Navigate to the site for the first time: (i.e.: http://localhost:4200) this response is the SSR rendered version of the index.html. (so far so good) the SSR rendered index.html will be shown.

the service worker gets installed, and starts to load the resources (in the meantime) (def. in ngsw-config.json) in our example the index.html. -> this index.html will be cached. (if the site gets reloaded or you are offline, the serviceworker will return this index.html. Thats what we expect).

after analysing the network traffic, i saw that the index.html (resource) which is loaded by the service worker is never prerendered. so i watched the server code (here is the important part)

app.get('*.*', express.static(join(DIST_FOLDER, 'browser')));

app.get('*', (req, res) => {
  res.render(join(DIST_FOLDER, 'browser', 'index.html'), { req });
});

in our case when the serviceworker loads the index.html he the server route for returning the static file from our dist/browser folder is used. its like calling http://localhost:4200/index.html which means the cached index.html is never ssr. its always the static file from our dist/browser folder.

After reloading the site the service worker will return the cached index.html and thats it. using an app-shell would help in that case. bec. the app-shell is compiled and added in our static index.html. (maybe thats a solution for some of you), but in my case i definitly want to use ssr.

i tried to modify the server source, to return also a rendered version of the index.html. instead of returning the static version. I added

app.get('/index.html', (req, res) => {
  res.render(join(DIST_FOLDER, 'browser', 'index.html'), { req });
});
....
app.get('*.*', express.static(join(DIST_FOLDER, 'browser')));

before the static file path. Now the result was as expected. The first call worked (ssr page). service worker loaded the prerendered index.html. (that looked perfect)

sadly there was the next problem incoming: when i tried turned the network off. the site was not working anymore. (but thats one of the most important things for my case)

to figure out why took me quite a while.

the problem here was: the serviceworker loaded the ssr index.html. but if you take a look at angular-cli dist folder (there is a file ngsw.json) which contains a hashtable for all static resources. like our index.html and this hash is based on the static file in the dist folder.

if we return an ssr index.html -> its content look different (obvi.) that results in a different hash. but the service-worker compares the hash from the ngsw.json hashtable and the response (index.html) if its hashes doesnt match he will do another call index.html?ngsw-cache-bust (to load the index.html again) and if this hash is also different (which is obvi.) the index.html will never get cached.

-> and thats the crux here. a solution would be:

manipulating the server.ts as i did. to return a ssr index.html version
and removing the index.html hash from ngsw.json (but this file is generated and i didnt found a proper solution todo this (not sure if its a good idea todo this) that looks like a dirty workaround, but it should work)

Resumee: (but thats only my personal opinion)

SSR combined with PWA is actually only worth for the first initial call of the site. -> bec. its fast and got prerendered. After reloading, the SSR has absolutly no effect. except you want to implement the solution above.

Whats also important to keep in mind. if you are using a proxy you have to disable the caching for the index.html -> otherwise ssr will not work (or if you you render with user specific content, it will be a security problem... cached user specific data...)

Sorry for such a long post, but i didnt found a good answer searching the web. Maybe it helped someone. (if anything is not clear feel free to contact me)

kamalakkanni commented 6 years ago

thanks,now ssr and service worker both are working.But in offline it shows network disconnected error while navigating to other routes and refreshing the page

kamalakkanni commented 6 years ago

below is my swprecacheconfig.json

module.exports = { navigateFallback: 'dist/browser/index.html', stripPrefix: 'dist/browser', root: 'dist/browser', staticFileGlobs: [

'dist/browser/index.html',
'dist/browser/**.js',
'dist/browser/**.css',
'dist/browser/**.ico',
'dist/browser/assets/images/**.jpg',
'dist/browser/assets/images/**.png',
'dist/browser/assets/images/**.gif',
'dist/browser/assets/js/**/**.js',
'dist/browser/assets/js/**.js',
'dist/browser/assets/css/**.css'

// 'dist/browser/assets/fonts/.{js,html,css,png,jpg,gif,svg,eot,ttf,woff,ico}', // 'dist/browser/.{js,html,css,png,jpg,gif,svg,eot,ttf,woff,ico}', // '!dist/browser/(Subscription)/*/.{js,html,css,png,jpg,gif,svg,eot,ttf,woff,ico}' ],

runtimeCaching: [{ urlPattern: /^https:\/\/.s3..com\//, handler: 'cacheFirst' }] };

@Priemar pls help me to fix it

Priemar commented 6 years ago

@kamalakkanni

i didnt used swprechache, so i dont know in detail how the generated code looks like, but if its similar to the ngsw build, your config looks good.

are you lazy loading module packages ? if yes are lazy load them at router level ? it looks like you are

for me it looks like the required module isnt in the cache. Means you loaded i.e. the main module. then you went offline. Now you navigate to a lazy route, and its shows an error bec. you try to lazy load the missing code.

if thats the case, we need to figure out why the serviceworker isnt prefetching the lazy modules.

in my case the serviceworker is prefetching all modules. What also could be a problem. If you load the main site. -> serviceworker starts prefetching the item. If you close your app to fast. The serviceworker maybe didnt prefetched all modules... that means they are not in the cache. If you go offline now and back to the app, you will get the same result, bec the modules are not cached.

Please check:

do you use lazy load modules ..
are these modules in the cache, before you go offline

kamalakkanni commented 6 years ago

I didn't use lazy loading for modules.after route navigation also offline working fine.but not ssr in production server

Priemar commented 6 years ago

And thats the point what i mentioned in my first answer. The generated ngsw-serviceworker caches index.html. If im reloading the page, always this index.html is served from cache.

You can check if swprecache acts like ngsw. Remove all serviceworkers and clear the cache. Then navigate to your app. If you check the network traffic, you should see the initial page (url) is from the server and prerendered. -> thats should work.

in the meantime the serviceworker prefetches all defined resources. Please check the

index.html

this is your fallback page. -> this index html should also prerendered.

If you reload the app, no matter which route you take, the network traffic will tell you if the route is taken from cache. Which i expect is the prerendered index.html

If thats the case you have exactly the same behv. i got with ngsw. In my opinion SSR for those service-worker (ngsw, maybe swprecache) implementations is no implemented as expected.

Its working for the inital load. (thats works) But after page changes, the serviceworker should fetch the actual route from the server and caches this route. If you reload the page now, it should return the last cached route. Thats what i expected.

Theoretically its not difficult to implement a serviceworker which acts like this. But rewriting the whole generation logic and keep it uptodate is a lot of work.

Im not sure but i think swprecache allow you to write plugins. I dont know how this plugin mechanism works, but maybe you can write a plugin which fetches the last page after navigating in your app.

If you dont want to rewrite the serviceworker, i recommend using an appshell. I think thats a good mix of SSR and serviceworker, the page feels pretty fast, even not all informations are visible on refresh.

My case was a bit more tricky i needed to deliver different app-shells. One for the logged-in user and one for the not logged in once. So i had to give the serviceworker prefetch the information if the user is logged in or not (which is also not supported in the actual service worker implementations)

If i get the chance to get in contact with one of the angular core developers, i would discuss this and maybe we find a good solution on the base system. If there are not more ppl which need this behaviour to SSR PWAs i think this feature will not be available soon ^^ and the only solution is to write your own service-worker.

but ill keep you up to date, if there is something new. or if i found another solution for this.

sorry for the bad news

kamalakkanni commented 6 years ago

Hi,

thanks for your help.can you pls tell me how to use ngswconfig.json if its working fine with ssr

Thanks

Priemar commented 6 years ago

You are welcome, i dont see any benefits switching to ngsw, for you, bec. it will act like your actual sw.

But here is the tutorial: https://angular.io/guide/service-worker-getting-started

kamalakkanni commented 6 years ago

Hi,offline is working but not ssr in online.pls help me.If i changed server.ts as per your suggestion .Iam getting cannot get error and site is not loaded.I copied server.ts from https://github.com/ssatz/Angular-SSR-Service-Worker.SSR is working for some pages and not working for some pages. pls help me to fix it.thanks

How can I catch dynamic urls and exclude subsite url in ngsw caching

d2kx commented 6 years ago

That hint re: deleting the index.html hash from the ngsw-manifest output was worth gold, @Priemar !! Thank you so much.

Now I've got Universal & Service Worker working together in harmony <3

Really should be a proper way to do this though.

hiepxanh commented 6 years ago

ok, finally someone can have an full instruction for us to follow? please, too much step with error to try :(

vytautas-pranskunas- commented 6 years ago

@D2KX but can your app work offline then?

vytautas-pranskunas- commented 6 years ago

Anu progress on this one? I think this is extremly important for proper PWA

Priemar commented 6 years ago

@vytautas-pranskunas- sure the app will work offline, otherwise i wouldnt call it an pwa.

gkalpak commented 6 years ago

No, I don't think that removing index.html from the generated ngsw.json would allow the app to work offline. I definitely do not recommend that.

As has been mentioned in some answers above, SSR works as expected on the first request (before the SW is activated). Once the SW takes over, the non-prerendered index.html is served, but that is OK, since it is served by the SW and doesn't require a round-trip to the server. (Offline mode also works fine in that case.)

This is by design: SSR speeds up the requests where no SW is in effect (including first-time visits, SEO, etc) and SW speeds up subsequent requests (and enables offline mode) by serving the cached files and scripts.

I am going to close this, since everything works as expected. Note: There are still issues with using app-shell. This is tracked in #8794.

vytautas-pranskunas- commented 6 years ago

But I am sure you understand that ssr should refresh index content on every inner navigation, but if only first navigation is cached so it is not SEO friendly because no matter where bot navigates internally it gets same cached index? That's why SW is not compatible with SSR i think. Or?

gkalpak commented 6 years ago

it is not SEO friendly because no matter where bot navigates internally it gets same cached index?

Again, SW is irrelevent for SEO. Web crawlers do not use ServiceWorkers. So, whether your app has ServiceWorker support or not, it doesn't make any difference for crawling the content (for indexing, previewing, etc.). For SEO, SSR works as expected.

For actual, human users accessing your app from the same device/browser, SSR speeds up the first ever request and then SW takes over and speeds up all subsequent requests. In that sense, they both work as expected and in tandem to improve the overall UX.

vytautas-pranskunas- commented 6 years ago

O, but how if crawlers are hitting same files how do they bypass SW? SW is nothing else then javascript file or SW just gets registered itself in browser?

On Tue, Jul 10, 2018 at 9:56 AM George Kalpakas notifications@github.com wrote:

it is not SEO friendly because no matter where bot navigates internally it gets same cached index?

Again, SW is irrelevent for SEO. Web crawlers do not use ServiceWorkers. So, whether your app has ServiceWorker support or not, it doesn't make any difference for crawling the content (for indexing, previewing, etc.). For SEO, SSR works as expected.

For actual, human users accessing your app from the same device/browser, SSR speeds up the first ever request and then SW takes over and speeds up all subsequent requests. In that sense, they both work as expected and in tandem to improve the overall UX.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/angular/angular-cli/issues/8872#issuecomment-403734351, or mute the thread https://github.com/notifications/unsubscribe-auth/ADvMl4IGSDMbf49ATA_DdDCWD_YkZHbhks5uFF4lgaJpZM4RB7dX .

--

Pagarbiai,

Vytautas Pranskunas

Priemar commented 6 years ago

Again, SW is irrelevent for SEO. Web crawlers do not use ServiceWorkers. So, whether your app has ServiceWorker support or not, it doesn't make any difference for crawling the content (for indexing, previewing, etc.). For SEO, SSR works as expected.

For actual, human users accessing your app from the same device/browser, SSR speeds up the first ever request and then SW takes over and speeds up all subsequent requests. In that sense, they both work as expected and in tandem to improve the overall UX.<

I 100% agree with gkalpak.

What we discussed above:

You start your app for the first time. The first request goes to the server. The server returns a SSR document. (in the meantime the SW will cache all prefetch files (which are defined in the generated swconfig). This includes the inital document (also defined in the config) which is per default the index.html

the default implementation of the SSR server code will only render routes which are not documents. documents are returned as they are on the server.

that means if the SW loads the index.html and adds this file to the cache. This index.html is not prerendered.

If you now reload your app the SW will serve the default document (index.html) from the cache and this file is not prerendered.

resumee: the first app load will give you a fast prerendered version. The next reloads will always serve a not prerendered version.

I found a Dirty Workaround to force the server to return a prerendered index.html and the SW to cache it. as i mentioned above: I defintily would not recommend todo this, bec you need to change autogenerated files. Which you should never do, + there could be security issues, other sideffects etc.

Actually there is no solution with the NGSW implementation. Sure you can write your own SW etc. but normally time is money so i would recommend: change the design of your app by using "app-shell" etc...

writing your own SW is not worth the effort you have to put in.

@gkalpak :

No, I don't think that removing index.html from the generated ngsw.json would allow the app to work offline. I definitely do not recommend that.<

Yeah its working when u manipulated the ngsw.json, as i wrote above, bec the serviceworker is still caching and serving the index.html, but per default it will cache-bust the index.html bec. the hash of the prerendered index.html doesnt match the hash in the hashtable of the config (obvi.)

But as u said i would not recommend it.... definilty not

Priemar commented 6 years ago

@vytautas-pranskunas-

SW gets registred in the browser. YES Crawlers are always requesting informations directly from the server. (for every route) this means every "site / route" the crawler is requesting the server will return the SSR result (depending on the server code).

vytautas-pranskunas- commented 6 years ago

OK thats makes sense but then I do not get why @Priemar needs workarounds? Because for user "view source" does not really matters

Priemar commented 6 years ago

@vytautas-pranskunas- bec. reloading the app where all files come from the SW. will show the unrendered "index.html" until the browser finished rendering. This are just milliseconds not more, but its still visble for the user.

So its not required but u know: everything for the best UserXP :)

keep in mind im against this workaround ... just wanna show why the acutal generated ngsw. acts like it does.

gkalpak commented 6 years ago

No, I don't think that removing index.html from the generated ngsw.json would allow the app to work offline. I definitely do not recommend that.<

Yeah its working when u manipulated the ngsw.json, as i wrote above, bec the serviceworker is still caching and serving the index.html, but per default it will cache-bust the index.html bec. the hash of the prerendered index.html doesnt match the hash in the hashtable of the config (obvi.)

@Priemar, just removing the index.html entry from ngsw.json (as was suggested in https://github.com/angular/angular-cli/issues/8872#issuecomment-392350259) will break offline afaict.

Regarding your approach to cache prerendered index.html: Unless I am misunderstanding something, this will not work correctly when you have routes, because the same index.html will be rendered for all of them (which look like navigation requests to the SW). In the best case scenario, you will get a flash of irrelevant content (which is way worse imo than a delay of meaningful content :grin:).

Priemar commented 6 years ago

@gkalpak :

just removing the index.html entry from ngsw.json (as was suggested in #8872 (comment)) will break offline afaict.

you are right: you have to remove it form the hashtable. bec the ngsw code will check the hashvalue of the served files with the hashtable, and if this hashes are not equal (which is not possible bec how should you know at compilation time, what the hash of a dynamic prerendered file looks like). the sw will not cache this index.html and it will not work offline. ... so you have to force the sw to accept and cache the prerendered index.html (thats what i mean).

Regarding your approach to cache prerendered index.html: Unless I am misunderstanding something, this will not work correctly when you have routes, because the same index.html will be rendered for all of them (which look like navigation requests to the SW). In the best case scenario, you will get a flash of irrelevant content (which is way worse imo than a delay of meaningful content 😁).

and yes thats the next point i didnt mentioned yet. and there is no workaround for it ^^ theoretically the sw need to refresh the cached index.html on every route change ... which leads to other problems.

So all over all i think we both agree on not doing any workarounds and use the default mechanism, there is a reason why it acts like it does. To change this behaviour a completly different implementation is required. -> which leads to other disadvantages ...

in my opinion closing this issue is pretty good. there is no need to discuss a scenario (workaround) nobody should use :)

as i said, i just wanted to clearify why things work like they do with the default implementation.

cheers

vytautas-pranskunas- commented 6 years ago

And how i can test crawlers behaviour that it get stright to SSR content?

On Tue, Jul 10, 2018 at 11:04 AM Priemar notifications@github.com wrote:

@gkalpak https://github.com/gkalpak :

just removing the index.html entry from ngsw.json (as was suggested in

8872 https://github.com/angular/angular-cli/issues/8872 (comment))

will break offline afaict.

you are right: you have to remove it form the hashtable. bec the ngsw code will check the hashvalue of the served files with the hashtable, and if this hashes are not equal (which is not possible bec how should you know at compilation time, what the hash of a dynamic prerendered file looks like). the sw will not cache this index.html and it will not work offline. ... so you have to force the sw to accept and cache the prerendered index.html (thats what i mean).

Regarding your approach to cache prerendered index.html: Unless I am misunderstanding something, this will not work correctly when you have routes, because the same index.html will be rendered for all of them (which look like navigation requests to the SW). In the best case scenario, you will get a flash of irrelevant content (which is way worse imo than a delay of meaningful content 😁).

and yes thats the next point i didnt mentioned yet. and there is no workaround for it ^^ theoretically the sw need to refresh the index.html on every route change ... which leads to other problems to solve.

So all over all i think we both agree on not doing any workarounds and use the default mechanism, there is a reason why it acts like it does. To change this behaviour a completly different implementation is required. -> which leads to other disadvantages ...

in my opinion closing this issue is pretty good. there is no need to discuss a scenario (workaround) nobody should use :)

as i said, i just wanted to clearify why things work like they do with the default implementation.

cheers

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/angular/angular-cli/issues/8872#issuecomment-403753134, or mute the thread https://github.com/notifications/unsubscribe-auth/ADvMl_sURvZnc1jeOzjEOPMrLNQ50nPfks5uFG4ogaJpZM4RB7dX .

--

Pagarbiai,

Vytautas Pranskunas

Priemar commented 6 years ago

@vytautas-pranskunas-

you can use google search console. there is an option to visualy show the crawler results.
or you use the network tab from the browser. Load your site url you wanna check. -> search the request in the network tab and click preview -> here u can see what the server returns (prerendered or not)

gkalpak commented 6 years ago

But make sure the file was not served by the SW. There are several ways to achieve this for testing:

Build the app in non-production mode (SW is only included in production mode).
Remove serviceWorker: true from your angular.json config (or have a different build-target with serviceWorker: false.
Remove the generated ngsw.json from the built artifacts.
Disable SW in the browsers DevTools (e.g. in Chrome's DevTools, there is a Service Workers section in the Application tabs, that has a Bypass for network checkbox).

vytautas-pranskunas- commented 6 years ago

So my question was that how hoe i see in action crawler going through different page routes and see that it gets content not from SW but from SSR. :)

On Tue, Jul 10, 2018 at 11:40 AM George Kalpakas notifications@github.com wrote:

But make sure the file was not served by the SW. There are several ways to achieve this for testing:

Build the app in non-production mode (SW is only included in production mode).

Remove serviceWorker: true from your angular.json config (or have a different build-target with serviceWorker: false.

Remove the generated ngsw.json from the built artifacts.

Disable SW in the browsers DevTools (e.g. in Chrome's DevTools, there is a Service Workers section in the Application tabs, that has a Bypass for network checkbox).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/angular/angular-cli/issues/8872#issuecomment-403763340, or mute the thread https://github.com/notifications/unsubscribe-auth/ADvMlwS6xbeXkk90pORtt_snaXwylTtbks5uFHaNgaJpZM4RB7dX .

--

Pagarbiai,

Vytautas Pranskunas

vytautas-pranskunas- commented 6 years ago

I have tried project from universal starter with enabled SW (followed by this issue: https://github.com/angular/angular/issues/23613#issuecomment-403525089) and i see no prerendered index.html even first one:

gkalpak commented 6 years ago

I have followed the steps outline in https://github.com/angular/angular/issues/23613#issuecomment-403525089 and I see prerendered content. You are probably not capturing the first request or deviating in some other way.

In any case, this has now moved into "support request" territory, for which this issue tracker is not suitable for. Please repost your issue on StackOverflow using tag angular.

_{If you are wondering why we don't resolve support issues via the issue tracker, please check out this explanation.}

angular-automatic-lock-bot[bot] commented 5 years ago

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.}

angular / angular-cli