PWA Task Manager

A service worker is not just a place where you put a few files into cache. In a real PWA Task Manager, it controls how the app behaves when the network is fast, slow, unavailable, or unstable. A common mistake is caching everything with the same strategy. Static assets, HTML routes, API responses, icons, and task data should not all be handled the same way.

Problematic approach:

          self.addEventListener("fetch", (event) => {
            event.respondWith(
              caches.match(event.request).then((cachedResponse) => {
                return cachedResponse || fetch(event.request);
              })
            );
          });

This looks useful, but it is too generic. It may serve stale API data, fail on navigation requests, and make debugging difficult because every request goes through the same logic.

Better approach:

          const STATIC_CACHE = "task-manager-static-v1";
          const DATA_CACHE = "task-manager-data-v1";

          self.addEventListener("fetch", (event) => {
            const requestUrl = new URL(event.request.url);

            if (event.request.mode === "navigate") {
              event.respondWith(handleNavigationRequest(event.request));
              return;
            }

            if (requestUrl.pathname.startsWith("/api/tasks")) {
              event.respondWith(networkFirstForTasks(event.request));
              return;
            }

            event.respondWith(cacheFirstForStaticAssets(event.request));
          });

          async function cacheFirstForStaticAssets(request) {
            const cachedResponse = await caches.match(request);

            if (cachedResponse) {
              return cachedResponse;
            }

            const networkResponse = await fetch(request);
            const cache = await caches.open(STATIC_CACHE);

            cache.put(request, networkResponse.clone());

            return networkResponse;
          }

          async function networkFirstForTasks(request) {
            const cache = await caches.open(DATA_CACHE);

            try {
              const networkResponse = await fetch(request);
              cache.put(request, networkResponse.clone());

              return networkResponse;
            } catch (error) {
              const cachedResponse = await cache.match(request);

              return cachedResponse || new Response(JSON.stringify([]), {
                headers: { "Content-Type": "application/json" }
              });
            }
          }

Pay attention to: Use different caching strategies for different request types. App shell assets are usually good candidates for cache-first. Task data often needs network-first or stale-while-revalidate logic so the UI does not silently show outdated information forever.

localStorage is tempting because it is simple, but it is not a strong foundation for an offline-first task manager. It is synchronous, limited, blocks the main thread, and becomes awkward when you need indexes, queue records, sync statuses, timestamps, retries, or larger task payloads. For serious offline behavior, IndexedDB is a better choice.

Problematic code:

          function saveTask(task) {
            const tasks = JSON.parse(localStorage.getItem("tasks")) || [];

            tasks.push(task);

            localStorage.setItem("tasks", JSON.stringify(tasks));
          }

          function getTasks() {
            return JSON.parse(localStorage.getItem("tasks")) || [];
          }

This works for a small demo, but it does not scale well. It also mixes saved tasks, pending operations, sync state, and failed requests into one fragile storage approach.

Better approach:

          async function openTaskDatabase() {
            return new Promise((resolve, reject) => {
              const request = indexedDB.open("pwa-task-manager", 1);

              request.onupgradeneeded = () => {
                const db = request.result;

                if (!db.objectStoreNames.contains("tasks")) {
                  db.createObjectStore("tasks", { keyPath: "id" });
                }

                if (!db.objectStoreNames.contains("syncQueue")) {
                  db.createObjectStore("syncQueue", { keyPath: "operationId" });
                }
              };

              request.onsuccess = () => resolve(request.result);
              request.onerror = () => reject(request.error);
            });
          }

          async function saveTaskOffline(task) {
            const db = await openTaskDatabase();
            const transaction = db.transaction("tasks", "readwrite");
            const store = transaction.objectStore("tasks");

            store.put({
              ...task,
              syncStatus: "pending",
              updatedAt: Date.now()
            });
          }

Pay attention to: Keep task records and sync queue records separate. Tasks describe the current UI state. Queue records describe what still needs to be sent to the server when the connection returns.

Offline-first apps must replay user actions safely. If a user creates a task offline, edits it twice, completes it, and then reconnects, the app needs to know exactly which operations are waiting. A common mistake is sending the current task list to the server without tracking individual mutations. This can create duplicates, lost edits, and unpredictable conflict behavior.

Problematic approach:

          async function syncTasks() {
            const tasks = await getAllTasksFromIndexedDB();

            await fetch("/api/tasks/sync", {
              method: "POST",
              headers: {
                "Content-Type": "application/json"
              },
              body: JSON.stringify(tasks)
            });
          }

This sends the whole local task state, but it does not explain what happened. The server cannot reliably distinguish between created tasks, edited tasks, deleted tasks, and tasks that were already synced earlier.

Better approach:

          function createQueueItem(type, task) {
            return {
              operationId: crypto.randomUUID(),
              type,
              taskId: task.id,
              payload: task,
              createdAt: Date.now(),
              attempts: 0,
              status: "pending"
            };
          }

          async function queueTaskCreate(task) {
            await saveTaskOffline({
              ...task,
              syncStatus: "pending"
            });

            await saveQueueItem(createQueueItem("TASK_CREATE", task));
          }

          async function processSyncQueue() {
            const queueItems = await getPendingQueueItems();

            for (const item of queueItems) {
              try {
                await fetch("/api/sync", {
                  method: "POST",
                  headers: {
                    "Content-Type": "application/json",
                    "Idempotency-Key": item.operationId
                  },
                  body: JSON.stringify(item)
                });

                await markQueueItemAsSynced(item.operationId);
                await markTaskAsSynced(item.taskId);
              } catch (error) {
                await increaseQueueAttemptCount(item.operationId);
              }
            }
          }

Pay attention to: Every offline mutation should have a unique operation ID. This helps prevent duplicate creates, supports retries, and gives you a clear way to debug what happened during reconnect.

Push notifications can make a task manager more useful, but they can also make it feel intrusive. A frequent mistake is asking for notification permission immediately when the app loads. Users are more likely to deny the request because they do not yet understand why the app needs notifications.

Problematic code:

          window.addEventListener("load", async () => {
            const permission = await Notification.requestPermission();

            if (permission === "granted") {
              subscribeUserToPush();
            }
          });

This creates a poor permission flow. The user has not created a task, set a reminder, or shown any intent to receive alerts.

Better approach:

          async function enableTaskReminders() {
            if (!("Notification" in window)) {
              showMessage("Notifications are not supported in this browser.");
              return;
            }

            if (Notification.permission === "denied") {
              showMessage("Notifications are blocked. You can enable them in browser settings.");
              return;
            }

            const permission = await Notification.requestPermission();

            if (permission !== "granted") {
              showMessage("Reminders are turned off.");
              return;
            }

            await subscribeUserToPush();
            await saveNotificationPreference(true);

            showMessage("Task reminders are now enabled.");
          }

Better UI trigger:

          <button type="button" onclick="enableTaskReminders()">
            Enable reminders for my tasks
          </button>

Pay attention to: Ask for notification permission only after a meaningful user action. Add a settings control so users can turn reminders on or off. A good PWA respects the user instead of treating push notifications as a growth trick.

Service workers can make your app fast, but they can also trap users on old code if you do not handle updates carefully. A common mistake is creating versioned caches but never deleting old ones, or releasing a new build without giving users a clear way to refresh the app. This leads to confusing bugs where HTML, JavaScript, CSS, and cached data come from different app versions.

Problematic code:

          const CACHE_NAME = "task-manager-cache";

          self.addEventListener("install", (event) => {
            event.waitUntil(
              caches.open(CACHE_NAME).then((cache) => {
                return cache.addAll([
                  "/",
                  "/index.html",
                  "/app.js",
                  "/styles.css"
                ]);
              })
            );
          });

This cache name never changes. If files change, the browser may continue serving older cached assets longer than expected.

Better approach:

          const STATIC_CACHE = "task-manager-static-v3";
          const ALLOWED_CACHES = [STATIC_CACHE, "task-manager-data-v1"];

          self.addEventListener("install", (event) => {
            event.waitUntil(
              caches.open(STATIC_CACHE).then((cache) => {
                return cache.addAll([
                  "/",
                  "/index.html",
                  "/app.js",
                  "/styles.css",
                  "/manifest.webmanifest"
                ]);
              })
            );
          });

          self.addEventListener("activate", (event) => {
            event.waitUntil(
              caches.keys().then((cacheNames) => {
                return Promise.all(
                  cacheNames.map((cacheName) => {
                    if (!ALLOWED_CACHES.includes(cacheName)) {
                      return caches.delete(cacheName);
                    }
                  })
                );
              })
            );
          });

Update prompt example:

          navigator.serviceWorker.addEventListener("controllerchange", () => {
            showUpdateBanner({
              message: "A new version is available.",
              actionText: "Reload",
              onAction: () => window.location.reload()
            });
          });

Pay attention to: Version your caches, clean old caches during activation, and show an update message when a new service worker is ready. PWA reliability depends not only on offline support, but also on predictable updates.