Add PWA Support to ignite-element

[0xjcf]

[Feature Request] PWA Integration Hooks for ignite-element

---

Description

This feature request proposes adding PWA integration hooks to ignite-element, enabling applications built on ignite to integrate with offline-first, persistence, and push-capable Progressive Web App features without ignite-element implementing those features directly.

ignite-element should remain a runtime + projection layer, not a service worker or storage framework. Its role is to:

• Expose lifecycle signals relevant to PWA environments
• Define adapter-level persistence and rehydration contracts
• Enable external PWA infrastructure (service workers, IndexedDB, push) to integrate cleanly with ignite-based apps

---

Goals

ignite-element should:

1. Provide lifecycle hooks that reflect browser / OS behavior relevant to PWAs
2. Allow adapters and actors to persist and rehydrate state via well-defined contracts
3. Enable applications to integrate with service workers and offline modes
4. Remain framework-agnostic and build-tool-agnostic

ignite-element should not implement service workers, caching strategies, push APIs, or manifests itself.

---

Non-Goals (Explicit)

ignite-element will not:

• Register or manage service workers
• Define cache strategies (network-first, cache-first, etc.)
• Generate or manage manifest.json
• Implement push notification APIs
• Own IndexedDB or storage implementations
• Become a PWA framework or build tool

These concerns belong to the application layer or optional helper packages.

---

Proposed Scope

1. Lifecycle Signals (Core Responsibility)

Expose runtime signals relevant to PWA environments, including:

• Page visibility changes
• Page hide / unload semantics (including bfcache awareness)
• Online / offline status
• Suspend vs stop semantics (already in progress)

These signals should be consumable by:

• state machines
• adapters
• persistence layers

---

2. Adapter Persistence Contracts

Define an optional persistence interface for adapters and sources, for example:

• rehydrate(snapshot)
• persist(snapshot)
• clear()

ignite-element should:

• Call these hooks at appropriate lifecycle boundaries
• Remain storage-agnostic
• Never assume a specific backend (IndexedDB, localStorage, etc.)

---

3. Service Worker Awareness (Not Implementation)

ignite-element may:

• Detect service worker presence
• Expose SW-related signals to adapters or machines

ignite-element must not:

• Register service workers
• Control caching
• Handle SW lifecycle logic internally

---

Documentation

• Add a “PWA Integration” section explaining:

  • What ignite-element supports
  • What it deliberately does not support
  • How to integrate with service workers and storage externally

• Provide examples showing:

  • ignite-query offline usage
  • ignite-websocket reconnection
  • Web3 rehydration flows

---

Dependencies

• Lifecycle & cleanup refactor in igniteCore
• Adapter contract stabilization

---

Milestones

Phase 1: Lifecycle Signals

• Visibility / pagehide integration
• Online / offline awareness
• bfcache-safe semantics

Phase 2: Persistence Contracts

• Adapter persistence interface
• Rehydration hooks
• Documentation + examples

Phase 3: Integration Examples

• Offline data example with ignite-query
• Realtime reconnection example with ignite-websocket
• Wallet rehydration example with ignite-web3

---

Priority

Medium–High (Foundational)

This work enables offline-first and PWA-capable apps without expanding ignite-element’s scope beyond its core responsibility.

---

Summary

ignite-element should integrate with PWA capabilities, not implement them.

This feature formalizes that boundary.