@rivium/push-web 0.1.7 → 0.1.9

package/README.md

@@ -50,6 +50,25 @@ cp node_modules/@rivium/push-web/service-worker.js public/rivium-push-sw.js
 curl -o public/rivium-push-sw.js https://unpkg.com/@rivium/push-web/service-worker.js
 ```
 
+Let the SDK register it (`init()` does this for you). It registers the worker
+with its API key and device id on the URL, and mirrors the same values into
+IndexedDB under `rivium-push` / `config`.
+
+The worker needs those two values to confirm delivery and to re-register a
+subscription the browser replaces. It reads the URL first and falls back to
+storage, so it keeps working even when something else registered
+`/rivium-push-sw.js` without the query string - your own
+`navigator.serviceWorker.register` call, another library, or a hot reload in
+development. Nothing secret is stored: the API key is public and already in
+your page.
+
+Where IndexedDB is unavailable (private windows, blocked site data), only the
+URL is used, exactly as before. A worker with neither says so in the console:
+
+```
+[RiviumPush SW] Delivery ack skipped - no SDK config in the worker URL or in storage
+```
+
 ## Quick Start
 
 ```typescript

package/dist/index.d.ts

@@ -582,6 +582,15 @@ declare class RiviumPush {
     private handleVisibilityChange;
     private checkInitialMessage;
     private registerServiceWorker;
+    /**
+     * Keeps `rivium-push` / `config` up to date for the service worker.
+     *
+     * Rewritten on every load, so a device id or server URL that changed does
+     * not leave a stale record behind. Best-effort: private browsing and
+     * blocked site data make IndexedDB unavailable, and the worker then falls
+     * back to its URL exactly as before.
+     */
+    private storeServiceWorkerConfig;
     private requestNotificationPermission;
     /**
      * Whether an existing subscription was created with the given VAPID key.
@@ -640,6 +649,19 @@ declare class RiviumPush {
     private showRichNotification;
     private updateFaviconBadge;
     private setConnectionState;
+    /**
+     * The id the BACKEND uses in MQTT topics: the first 16 characters of the
+     * project id, returned as `appId` by /devices/register.
+     *
+     * Channels were built from the API key prefix instead, so every channel this
+     * SDK streamed from was one nothing is ever published to - the real-time
+     * path silently delivered nothing on web, from 0.1.0 until 0.1.9. It went
+     * unnoticed because Web Push carried every message on its own.
+     *
+     * The API key prefix stays as the fallback for a backend old enough not to
+     * return `appId`; the native SDKs do exactly the same.
+     */
+    private topicAppId;
     private getOrCreateDeviceId;
     private generateUUID;
     private urlBase64ToUint8Array;