bindings/service_workers library

Service Workers Nightly

https://w3c.github.io/ServiceWorker/

Classes

Cache
The interface provides a persistent storage mechanism for [Request] / [Response] object pairs that are cached in long lived memory. How long a Cache lives is browser dependent, but a single origin's scripts can typically rely on the presence of a previously populated Cache. Note that the interface is exposed to windowed scopes as well as workers. You don't have to use it in conjunction with service workers, even though it is defined in the service worker spec. An origin can have multiple, named objects. You are responsible for implementing how your script (e.g. in a ServiceWorker) handles updates. Items in a do not get updated unless explicitly requested; they don’t expire unless deleted. Use CacheStorage.open() to open a specific named object and then call any of the methods to maintain the . You are also responsible for periodically purging cache entries. Each browser has a hard limit on the amount of cache storage that a given origin can use. Cache quota usage estimates are available via the StorageManager.estimate() method. The browser does its best to manage disk space, but it may delete the Cache storage for an origin. The browser will generally delete all of the data for an origin or none of the data for an origin. Make sure to version caches by name and use the caches only from the version of the script that they can safely operate on. See Deleting old caches for more information.
CacheQueryOptions
CacheStorage
The interface represents the storage for Cache objects. The interface:
Client
The interface represents an executable context such as a Worker, or a SharedWorker. Window clients are represented by the more-specific WindowClient. You can get /WindowClient objects from methods such as Clients.matchAll() and Clients.get().
ClientQueryOptions
Clients
The interface provides access to Client objects. Access it via [self.clients] within a service worker.
ExtendableEvent
The interface extends the lifetime of the install and activate events dispatched on the global scope as part of the service worker lifecycle. This ensures that any functional events (like FetchEvent) are not dispatched until it upgrades database schemas and deletes the outdated cache entries. If waitUntil() is called outside of the handler, the browser should throw an InvalidStateError; note also that multiple calls will stack up, and the resulting promises will be added to the list of extend lifetime promises.
ExtendableEventInit
ExtendableMessageEvent
The interface of the Service Worker API represents the event object of a message event fired on a service worker (when a message is received on the ServiceWorkerGlobalScope from another context) — extends the lifetime of such events. This interface inherits from the ExtendableEvent interface.
ExtendableMessageEventInit
FetchEvent
This is the event type for fetch events dispatched on the service worker global scope. It contains information about the fetch, including the request and how the receiver will treat the response. It provides the event.respondWith() method, which allows us to provide a response to this fetch.
FetchEventInit
MultiCacheQueryOptions
The interface of the Service Worker API provides methods for managing the preloading of resources with a service worker.
RegistrationOptions
ServiceWorker
Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers. The interface of the Service Worker API provides a reference to a service worker. Multiple browsing contexts (e.g. pages, workers, etc.) can be associated with the same service worker, each through a unique object. A object is available in the ServiceWorkerRegistration.active property, and the ServiceWorkerContainer.controller property — this is a service worker that has been activated and is controlling the page (the service worker has been successfully registered, and the controlled page has been reloaded.) The interface is dispatched a set of lifecycle events — install and activate — and functional events including fetch. A object has an associated ServiceWorker.state, related to its lifecycle.
ServiceWorkerContainer
The interface of the Service Worker API provides an object representing the service worker as an overall unit in the network ecosystem, including facilities to register, unregister and update service workers, and access the state of service workers and their registrations. Most importantly, it exposes the ServiceWorkerContainer.register() method used to register service workers, and the ServiceWorkerContainer.controller property used to determine whether or not the current page is actively controlled.
ServiceWorkerGlobalScope
The interface of the Service Worker API represents the global execution context of a service worker. Developers should keep in mind that the ServiceWorker state is not persisted across the termination/restart cycle, so each event handler should assume it's being invoked with a bare, default global state. Once successfully registered, a service worker can and will be terminated when idle to conserve memory and processor power. An active service worker is automatically restarted to respond to events, such as ServiceWorkerGlobalScope.onfetch or ServiceWorkerGlobalScope.onmessage. Additionally, synchronous requests are not allowed from within a service worker — only asynchronous requests, like those initiated via the fetch() method, can be used. This interface inherits from the WorkerGlobalScope interface, and its parent EventTarget.
ServiceWorkerRegistration
The interface of the Service Worker API represents the service worker registration. You register a service worker to control one or more pages that share the same origin. The lifetime of a service worker registration is beyond that of the objects that represent them within the lifetime of their corresponding service worker clients. The browser maintains a persistent list of active objects.
WindowClient
The interface of the ServiceWorker API represents the scope of a service worker client that is a document in a browsing context, controlled by an active worker. The service worker client independently selects and uses a service worker for its own loading and sub-resources.