PWA v4.1.6 - Sophia - Deprecated Technical Documentation

Overview

PWA v4.1.6 was the Progressive Web App layer active on Wholesale Dito Store before the v6 rewrite. It provided offline caching, a basic product fallback, and a catalog sync that ran on install and on demand.

The version was built around a smaller set of constraints than v6. It prioritized minimal code size over resilience. It did not include circuit breakers, multi-tab locking, or detailed error telemetry.

The service worker did not use generative AI. All caching, syncing, and fallback behavior was deterministic code.

What changed in v6

The v6 rewrite added several capabilities that were not present in v4.1.6. This table summarizes the difference between the two versions.

Architecture (v4.1.6)

The v4.1.6 service worker was organized into four layers:

Unlike v6, there was no separate routing layer. Each handler was called directly from a chain of if checks inside the fetch event. This was simpler but harder to extend.

Storage locations

Cache Storage

IndexedDB

Configuration constants

Configuration was defined inline as top-level constants. There was no CONFIG object.

Caching strategy by route

Compared to v6, v4.1.6 did not use stale-while-revalidate for navigation. It served from cache if present, otherwise fetched. This made cache misses slower but reduced background work.

Offline behavior

When the user is online

The service worker served cached content if available. If not cached, it fetched from the network and cached the response.

When the user goes offline

Cached pages loaded from cache. Product pages fell back to catalog data stored in IndexedDB. Uncached navigation routes fell back to /offline.html. Images that were not cached fell back to a placeholder image, then to an inline SVG.

Limitations

• No stale-while-revalidate. Cached pages did not update in the background.
• No offline badge on cached product pages rendered from the catalog.
• No "Back to Last Page" behavior. The offline page used browser history only.
• No cross-tab safety. Opening the site in multiple tabs during a version change could cause the older tab to lose its database connection without warning.

Catalog sync

The offline catalog was synced from /sophia/api/offline-catalog.php. The response format matched the shape used by v6:

  {
 "products": [ ... ],
 "synced_at": "2026-...",
 "total_count": 2000
 } 

Each product had these fields:

Sync triggers

Catalog sync ran on:

• The activate event, once per service worker installation.
• The sync event with the tag catalog-sync.
• The SYNC_CATALOG message from a client.

Sync rate limits

• Minimum 10 minutes between successful syncs.
• No failure backoff. A failing endpoint was retried on each trigger.
• No stuck detection. If a sync hung, isSyncing stayed true until the worker restarted.

Telemetry

Telemetry tracked five counters:

Telemetry was held in memory and flushed to IndexedDB on a 10-second timer, or on the PAGE_HIDDEN message. Unlike v6, it was not persisted on every counter change, so a service worker crash could lose up to 10 seconds of counters.

Known issues in v4.1.6

The following issues were present in v4.1.6 and were addressed in v6:

Verifying v4.1.6 (historical)

To verify that v4.1.6 was active, these were the checks:

In the browser console

  Catalog synced: 2000
 Service Worker v4.1.6 initialized  

In DevTools

Application, Service Workers:

• Status showed "activated and is running"
• Scope was https://www.wholesaledito.store/

Application, Cache Storage:

• Three caches ending in -v4.1.6 were present

Application, IndexedDB:

• Three databases ending in -v4.1.6 were present
• The catalog database held products after the first sync

Migration from v4.1.6 to v6.0.0

Upgrading from v4.1.6 to v6.0.0 required no user action. The v6 service worker handled the upgrade in its install and activate events.

What happened during migration:

1. The browser detected the new service-worker.js file.
2. The v6 install event ran: it opened three new IndexedDB databases with -v6.0.0 suffixes.
3. The v6 activate event deleted all caches whose names started with wholesaledito- but were not in the current valid set. This removed the -v4.1.6 caches.
4. Old IndexedDB databases from v4.1.6 were orphaned. They were not deleted automatically by v4.1.6 but were cleaned up by the v6 migration routine.
5. The v6 service worker ran its precache and took control of open clients.

Any user who had the site open during the version change was migrated on their next page load, or when the tab was closed and reopened.

What this documentation does not cover

• How the v4.1.6 registration script handled feature detection (it did not)
• How the v4.1.6 offline page stored the last visited URL (it did not)
• How the v4.1.6 catalog endpoint differed from v6
• Any behavior that was added after v4.1.6 and before v6.0.0

This document describes only what v4.1.6 contained. For the current implementation, see the v6.0.0 documentation.

Revision history

Contact

For questions about this archived documentation, contact the developer at Clickerwayne Zelle Solutions Inc.