docs(service-worker): use timer instead of interval

[JackOlsen]

Use RxJS timer creation operator instead of interval so that first check for updates happens shortly after app startup. Change recurring check interval to 1 hour, rather than seemingly arbitrary 21.6 seconds.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• angular.io application / infrastructure changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[JackOlsen]

I signed it!

…

On Wed, Nov 28, 2018 at 12:12 PM googlebot ***@***.***> wrote: Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 *Please visit https://cla.developers.google.com/ <https://cla.developers.google.com/> to sign.* Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it. ------------------------------ What to do if you already signed the CLA Individual signers - It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data <https://cla.developers.google.com/clas> and verify that your email is set on your git commits <https://help.github.com/articles/setting-your-email-in-git/>. Corporate signers - Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version <https://opensource.google.com/docs/cla/#troubleshoot>). - The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data <https://cla.developers.google.com/clas> and verify that your email is set on your git commits <https://help.github.com/articles/setting-your-email-in-git/>. - The email used to register you as an authorized contributor must also be attached to your GitHub account <https://github.com/settings/emails>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#27332 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE168WZQi_An30IxYIwlz43Zu9TnMkC8ks5uzu4-gaJpZM4Y4Wog> .

[googlebot]

CLAs look good, thanks!

[gkalpak]

Wow, this is our example for setting up update checks??? This will prevent the app from stabilizing (due to the interval/timer) and the SW will never be registered (since it waits for the app to stabilize first) 🤦‍♂️

Other than that, I think the interval is preferable. There is no need to check when the app loads, since the SW will check on each navigation anyway.

But we do need to fix the issue with preventing the SW from being registered 😁

The proper way to do this is to first wait for the app to stabilize and then start polling for updates:

import { ApplicationRef } from '@angular/core';
import { concat, interval } from 'rxjs';
import { first } from 'rxjs/operators';
...
constructor(appRef: ApplicationRef) {
  concat(appRef.isStable.pipe(first(v => v)), interval(6 * 60 * 60 * 1000)).
    subscribe(() => updates.checkForUpdates());
}

The code can be formatted in a way that is more understandable for beginners. E.g.:

constructor(appRef: ApplicationRef) {
  const appIsStable$ = appRef.isStable.pipe(first(isStable => isStable === true));
  const everySixHours$ = interval(6 * 60 * 60 * 1000);
  const everySixHoursAfterAppIsStable$ = concat(appIsStable$, everySixHours$);

  everySixHoursAfterAppIsStable$.subscribe(() => updates.checkForUpdates());
}

@JackOlsen, would be be interested in making the necessary changes (in both the example code and guide)? 🙏

[gkalpak]

I am 99% sure this was supposed to be 6 hours (6 * 60 * 60 * 1000) 😁

[gkalpak]

This initial delay is still arbitrary and does not guarantee that the app has loaded (although hopefully is has).

[JackOlsen]

I wasn't aware of ApplicationRef.isStable, but that makes sense as a hook for initiating polling for updates.

Regarding this:

There is no need to check when the app loads, since the SW will check on each navigation anyway.

I think I'm following now. The SW will check for an update every time the page is loaded, and if it finds an update, an event will be emitted on SwUpdate.available, right?

[gkalpak]

Right! Basically, a check for update is triggered in the following cases:

• When the SW is instantiated by the browser.
• On every navigation request (i.e. when navigating to your index.html but when fetching a JS script).
• When the user calls SwUpdate#checkForUpdates().

In all those cases, if an update is found, a message is emitted on the SwUpdate#available observable.

[jenniferfell]

I was just reviewing this as part of doc PR triage (thus the label additions). Two things:

• Please update the commit message to begin with "docs:" per our conventions here: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit

• I don't find any mention of "interval" in the guides, so this change doesn't seem to invalidate any existing guide content, but that fact makes me ask: Does something need to be added to the guide? Any chance you'd be willing to draft an update as part of this PR? :-) (If not, we can open an issue to add guide content later, as long as the guides aren't wrong today.)

Thanks!

[gkalpak]

• I thought docs(service-worker): ... was accurate, since this is updating docs related to the SW.
• The example shown in the guide in indeed wrong. See docs(service-worker): use timer instead of interval #27332 (review) for more info.

[gkalpak]

Superceded by #28020.

[angular-automatic-lock-bot]

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