Commit Graph

8 Commits

Author SHA1 Message Date
Alex Eagle cbbad1b791 refactor(ivy): pre-factor: set explicit type parameters for ModuleWithProviders (#25970)
Ivy depends on having the generic type token later when reading the ModuleWithProviders from a .d.ts file.

PR Close #25970
2018-09-18 13:28:44 -07:00
Heo Sangmin 0bdd30e34f fix(service-worker): check platformBrowser before accessing navigator.serviceWorker (#21231)
PR Close #21231
2018-05-22 15:09:31 -04:00
Igor Minar b43f8bc7d3 feat(core): upgrade rxjs to 6.0.0-alpha.4 (#22573)
PR Close #22573
2018-03-19 21:51:51 -07:00
Fabian Wiles 7cabaa0ae7 fix(service-worker): ensure initialised in browser only (#20782)
closes #20360

PR Close #20782
2017-12-06 06:55:33 -08:00
Alex Rickabaugh 3fbcde9048 fix(service-worker): send initialization signal from the application
The Service Worker contains a mechanism by which it will postMessage
itself a signal to initialize its caches. Through this mechanism,
initialization happens asynchronously while keeping the SW process
alive.

Unfortunately in Firefox, the SW does not have the ability to
postMessage itself during the activation event. This prevents the
above mechanism from working, and the SW initializes on the next
fetch event, which is often too late.

Therefore, this change has the application wait for SW changes and
tells each new SW to initialize itself. This happens in addition to
the self-signal that the SW attempts to send (as self-signaling is
more reliable). That way even on browsers such as Firefox,
initialization happens eagerly.
2017-12-01 14:21:07 -08:00
Alex Rickabaugh 65f4fad801 fix(service-worker): allow disabling SW while still using services
Currently, the way to not use the SW is to not install its module.
However, this means that you can't inject any of its services.

This change adds a ServiceWorkerModule.disabled() MWP, that still
registers all of the right providers but acts as if the browser does
not support Service Workers.
2017-12-01 14:18:16 -08:00
Alex Rickabaugh 17142a778a fix(service-worker): don't block initialization on registration (#19936)
Importing ServiceWorkerModule.register() will schedule registration of
the Service Worker inside an APP_INITIALIZER. Previously, the Promise
returned by navigator.serviceWorker.register() was returned from the
initializer function. This has the unwanted side effect of blocking
initialization until the SW is registered. Even worse, if the SW script
fails to load, this can cause the app initialization to fail.

The solution is to not return the registration promise from the
initializer function, essentially decoupling registration from the rest
of the initialization flow.

This change is not unit testable as there are no mocks/adapters yet for
navigator.serviceWorker. A future integration test should cover this case
with better fidelity.

PR Close #19936
2017-10-26 16:05:07 -04:00
Alex Rickabaugh d442b6855f feat(service-worker): introduce the @angular/service-worker package (#19274)
This service worker is a conceptual derivative of the existing @angular/service-worker maintained at github.com/angular/mobile-toolkit, but has been rewritten to support use across a much wider variety of applications.

Entrypoints include:

@angular/service-worker: a library for use within Angular client apps to communicate with the service worker.
@angular/service-worker/gen: a library for generating ngsw.json files from glob-based SW config files.
@angular/service-worker/ngsw-worker.js: the bundled service worker script itself.
@angular/service-worker/ngsw-cli.js: a CLI tool for generating ngsw.json files from glob-based SW config files.
2017-09-28 16:18:12 -07:00