Create Database

To create an IndexedDB database, a web app must execute the following code:

Click here to view code image

var theDB = window.indexedDB.open(DATABASE_NAME, 1);

This creates a theDB object pointing to an open database. If the database doesn’t exist when this code executes, the browser creates the database. Service workers don’t have access to the browser’s window object, so to create/open an IndexedDB database, use the following code:

Click here to view code image

var theDB = self.indexedDB.open(DATABASE_NAME, 1);

We want code that runs in both locations, because both the web app and the service worker must open the database, so we’ll use the latter example for the PWA News app.

Remember, there are no promises here, so to report or act on database operation success or failure, you must create callback functions. For IndexedDB operations, the two you’ll care the most about are the onsuccess and onerror callbacks:

Click here to view code image

theDB.onsuccess = function (event) {
  console.log('Open Success');
  // get a handle to the database
  let db = event.target.result;

};
theDB.onerror = function (event) {
  console.log('Open Error');

};

The onsuccess callback gets an event object you can use to get a handle to the database object, as shown in the example. If you keep a reference to the theDB object, you can also access the database later from

let db = theDB.result;

The database object also supports other callback options:

Click here to view code image

theDB.onclose = function (event) {
  console.log('Closing database');

}

theDB.abort = function (event) {
  console.log('Aborting...');

}

You may have noticed that I passed a number to the call to the IndexedDB open method. That parameter specifies the version number for the database. When you open an IndexedDB database, the browser checks the version number you provided against an existing database; if they’re different, as will be the case when you create a new database, the browser fires the onupgradeneeded callback. This callback gives the app an opportunity to make any database changes required by the new version.

Click here to view code image

theDB.onupgradeneeded = function (event) {
  console.log('Database upgrade needed');
  // do something interesting

}

Create Store

IndexedDB groups related data into stores;⁸ you’ll need at least one store to manage data for an application. The database’s onupgradeneeded callback is the perfect place to create it:

8. https://developer.mozilla.org/en-US/docs/Web/API/IDBObjectStore

Click here to view code image

const STORE_NAME = 'my-store';
theDB.onupgradeneeded = function (event) {
  console.log('Database upgrade needed');
  // does the store already exist?
  if (!db.objectStoreNames.contains(STORE_NAME)) {
    // no? Then create it
    console.log('creating store');
    var storeOptions = { keyPath: "idx", autoIncrement: true };
    var theStore = db.createObjectStore(STORE_NAME, storeOptions);
  } else {
    console.log('Store already exists');
  }
}

As you can probably tell from the name, IndexedDB is an indexed database, so you can create multiple indexes in a store and use them to more easily locate objects in the store. In this example, I simply created an index called idx that the IndexedDB engine automatically increments for me. This gives the app a unique identifier it can use to locate and work with every object in the store.

Add Data

Using the previous examples as a base, an app adds a data object to a store by executing the following code:

Click here to view code image

// get a handle to the db
let db = theDB.result;
let transaction = db.transaction([STORE_NAME], "readonly");
// get a handle to the store
let store = transaction.objectStore(STORE_NAME);
// finally, add the record
let request = add({ key1: 'value1', key2: 'value2' });

That’s a lot of intermediate variables, right? Well, you can simplify this using the following:

Click here to view code image

// get a handle to the db
let db = theDB.result;
let request = db.transaction([STORE_NAME], "readwrite")
  .objectStore(STORE_NAME)
  .add({ key1: 'value1', key2: 'value2' });

request.onsuccess = function (event) {
  console.log('Add successful');

};
request.onerror = function (event) {
  console.error('Add failure');

}

And, of course, we have the standard callback functions for success and failure.

IndexedDB is a transactional database system, so an app must make database updates through transactions that you can later abort using the transaction object’s abort method. IndexedDB is also an indexed object store, so in this last example, the code added an object to the store.

To see the results of this code, you must use the browser’s developer tools, as shown in Figure 5.4. In this figure, I opened the developer tools, then selected the Application tab across the top. Next, I expanded the IndexedDB option in the left navigator. Chrome doesn’t automatically refresh the contents of this pane, so I had to right-click on IndexedDB and select Refresh IndexedDB before I could see my database and store.

In the figure, you can see the generated key plus the data object associated with the key. Notice that the code didn’t include the idx object in the call to add, but IndexedDB added it there automatically for you.

Delete Objects

To delete an object from an IndexedDB store, an app needs the index for the object and the following code:

Click here to view code image

// get a handle to the db
let db = theDB.result;
let idx = 3;

let request = db.transaction([STORE_NAME], "readwrite")
  .objectStore(STORE_NAME)
  .delete(idx);

// success!
request.onsuccess = function (event) {
  console.log('Item ${idx} deleted');

}

// ugh, error
request.onerror = function (event) {
  console.log('Unable to delete item ${idx}');

}

Iterating through Data Using Cursors

To loop through objects in a store, IndexedDB uses cursors. A web app opens a cursor and, if the cursor is not null, uses it to retrieve the data object from the store:

Click here to view code image

// get a handle to the db
let db = theDB.result;
var request = db.transaction([STORE_NAME], "readonly")
  .objectStore(STORE_NAME)
  .openCursor();

// success!
request.onsuccess = function (event) {
  // get a handle to the cursor
  var cursor = event.target.result;
  // do we have a valid cursor?
  if (cursor) {
    // get the object value from the cursor
    item = cursor.value;
    // do something with the item's data

    // Move onto the next item in the object store
    cursor.continue();
  } else {
    // no valid cursor, so must be at the end
  }
};

// ugh, error
request.onerror = function (event) {
  console.error(request.error);
  // do something with the error

}

In the example, item points to the object {key1: "value1", key2: "value2", idx: 1}. The app accesses object values through item.key1, item.key2, and item.idx.

When the app’s done processing the data accessible through the cursor, it makes a call to cursor.continue, which moves the cursor to the next object in the store. This creates a loop where the cursor moves through all the store objects until it’s done, at which point the code drops into the else clause to wrap up the process.

This is basically everything you need to know about IndexedDB to add background sync to the PWA News app. In the following sections, we’ll take the PWA News app’s existing process of directly POSTing user sentiment data to the server and update it to use service worker background sync instead. I’ll fill in all the details about how background sync works through the code we add to the PWA News app.

Preparing the Service Worker for Background Sync

Start by opening the project’s publicsw.js file; the service worker doesn’t know anything about sync events, so we’re going to fix that first. At the bottom of the file, add the following code:

Click here to view code image

self.addEventListener('sync', event => {
  // process the Submit Feedback action items
  if (event.tag == 'feedback') {
    console.log('SW: Processing Feedback sync');

  } else {
    console.log(`SW: Unrecognized sync event: (${event.tag})`);
  }
});

This code registers the event listener for the sync event discussed earlier in the chapter. It doesn’t do anything right now except log the event; we’ll add code later to act on feedback requests. For now, we just need a place in the service worker to validate the changes we’ll make next in the feedback page.

Updating the Web App to Use Background Sync

Now we need to implement changes to the web app’s Feedback page so it uses background sync to upload visitor sentiment to the server.

Open the project’s publicjsfeedback.js file. If you look toward the bottom of the file, you’ll find the following code:

Click here to view code image

function submitFeedback(event) {
  console.log('submitFeedback()');
  // get the selected item from the form
  var theSelect = document.getElementById("sentiment");
  let selectedSentiment = theSelect.options[theSelect.selectedIndex].value;
  console.log(`Selected Sentiment: ${selectedSentiment}`);
  // do we have a sentiment value? We should.
  if (selectedSentiment) {
    // post it to the server using fetch
    postFeedback(selectedSentiment);
  }
}

This is the function that starts the process of sending visitor feedback to the server. The code checks to see that there’s a sentiment value selected on the page, then calls the file’s postFeedback function to POST it to the server using fetch. There should always be one value selected on the form, but I prefer to make few assumptions when it comes to user input.

Now, replace the call to postFeedback with the following code:

Click here to view code image

if ('serviceWorker' in navigator && 'SyncManager' in window) {
  // yes, save the feedback to the database

  } else {
  // service worker or background sync not supported
  // so we'll do this the old-fashioned way
  postFeedback(selectedSentiment);
}

This is an if statement that checks to see if the browser supports service workers and the SyncManager. If they are supported, IndexedDB should be available as well, and we can create a database and use background sync to submit visitor sentiment to the server. You could also check for indexedDB if you wanted to be completely thorough.

This code moves the call to postFeedback to the else clause of the if statement. It is our fallback to regular operation when a visitor uses a browser that doesn’t support service workers. If you omit this fallback, users on older browsers will curse you because their sentiment never seems to make it to the server no matter how many times they click the button.

The last piece of this is to add the code that opens the local IndexedDB database and writes the selected sentiment value to the store. Now, the code we’re about to add refers to functions that don’t exist yet, so don’t panic when your integrated development environment (IDE) or editor starts to complain about some of the code. Add the following code inside the if clause of the if/then statement we just added a minute ago; I’m hoping it’s clear what the code does, but I’ll explain it anyway on the other side.

Click here to view code image

openIDB()
  .then(db => {
    queueFeedback(db, selectedSentiment)
      .then(() => {
        console.log('submitFeedback: Successfully queued feedback');
      })
      .catch(error => {
        console.error(error);
        Swal.fire('Sync Error', error, 'error');
      })
  })

All right, what’s happening here is that we’re calling a function called openIDB (which we haven’t written yet), and when the promise it returns resolves, we’re calling another function called queueFeedback (another function we haven’t written yet) that adds the selected sentiment value to the database we just opened. Both functions return promises, so that’s why there are so many thens and catches in the code. The call to openIDB returns a handle to the database that was just created or opened. The code then passes that value to the call to queueFeedback so it doesn’t have to figure out where it’s writing its stuff.

Here’s the complete listing for the new submitFeedback function:

Click here to view code image

function submitFeedback() {
  // the user tapped the Share Sentiment button
  console.log('submitFeedback()');
  // get the selected item from the form
  var theSelect = document.getElementById("sentiment");
  let selectedSentiment = theSelect.options[theSelect.selectedIndex].value;
  // do we have a sentiment selected? we should
  if (selectedSentiment) {
    console.log(`submitFeedback: '${selectedSentiment}' selected`);
    // is IndexedDB supported?
    if ('serviceWorker' in navigator && 'SyncManager' in window) {
      // yes, save the feedback to the database
       openIDB()
        .then(db => {
          queueFeedback(db, selectedSentiment)
            .then(() => {
              console.log('submitFeedback: Successfully queued feedback');
            })
            .catch(error => {
              console.error(error);
              Swal.fire('Sync Error', error, 'error');
            })
        })
    } else {
      // service worker or sync not supported
      // so do this the old-fashioned way
      postFeedback(selectedSentiment);
    }
  }
};

The call to Swal refers to SweetAlert2,⁹ an open source library for generating visually pleasant alert dialogs in web apps. The first quoted string is the title for the alert dialog. The second parameter (error) is the error message returned from the call to queueFeedback, and the final 'error' tells SweetAlert2 to display an error dialog.

9. https://sweetalert2.github.io/

The complete feedback code for this example is in the project folder’s publicchapter-codefeedback-5.js file.

With that code in place, it’s time to start writing the code that interacts with the local IndexedDB database. If you remember the description of how the sync process works, both the web app and the service worker access the database at different times. The web app accesses the database with write capabilities when it queues up the sentiment value for processing. The service worker accesses the database with read and write capabilities when it processes the queue of sentiment data. The service worker requires read and write access because it uses read to read the data from the store and write when it deletes the value after successful processing.

If you’re thinking the way I do about the code I just described, you probably realized that both processes probably run some of the same code to do what they do. To minimize typing the same code in both the web app and service worker, we’re going to put all of it in the same file and access it from both processes. Add a new file to the project called publicjsdb.js, then open it for editing.

At the top of the file, add the following constants:

Click here to view code image

// IndexedDB DB and Store Properties
const DB_NAME = 'pwa-news';
const DB_VERSION = 1;
const STORE_NAME = 'feedback-store';

The module code references the store name in several places, so I moved the value into a constant so I wouldn’t have to type it everywhere. I pulled the database version into a constant here because I may change this value with every app version, and I wanted the value in an easy place to find later. It’s used only once, but putting it at the top of the file makes it very easy to change later. Finally, I moved the database name into a constant here just because; I had everything else here, so it made sense to have the database name here as well.

Next, add the openIDB function, shown next, to the new file. The function uses the concepts described earlier in the chapter to open the IndexedDB database and return the database object to the calling function so it can use it later to interact with the open database.

Click here to view code image

function openIDB() {
  // open the indexedDB database used by the app
  return new Promise((resolve, reject) => {
    // open the feedback database
    var theDB = self.indexedDB.open(DB_NAME, DB_VERSION);

    // success, callback
    theDB.onsuccess = function (event) {
      console.log('openIDB: Successfully opened database');
      // success, return the db object result
      resolve(event.target.result);
    };

    // define the database error callback
    theDB.onerror = function (event) {
      let msg = `Database error ${theDB.error}`;
      console.error(`openIDB: ${msg}`);
      Swal.fire('Database Error', msg, 'error');
      // reject the promise, we failed
      // include the error message with the failure
      reject(msg);
    };

    theDB.onupgradeneeded = function (event) {
      console.log('openIDB: Database upgrade needed');
      // get a handle to the database
      var db = event.target.result;
      // does the store already exist?
      if (!db.objectStoreNames.contains(STORE_NAME)) {
        // no? Then create it
        console.log(`openIDB: Creating store ${STORE_NAME}`);
        // first create the configuration options for the store
        var storeOptions = { keyPath: "idx", autoIncrement: true };
        // then create the store
        var theStore = db.createObjectStore(STORE_NAME, storeOptions);
      };
    };
  });
};

When you open an IndexedDB database, and it doesn’t already exist, the act of opening it creates it for you.

In the onupgradeneeded callback, the code checks to see if the store we need already exists and creates it if it’s not already there.

The last piece of this is the code that follows. It takes the selected sentiment and stores it in the database inside the feedback-store store. Like the generic example shown earlier, this function adds a data object (in this case, { timestamp: Date.now(), sentiment: feedback }) to the store, then registers the sync event that tells the service worker there’s data there for it to process. I added a timestamp to the data object thinking I might display the submission date in the console as the service worker processed each queued feedback item. I never got around to doing that, but if you want, it’s there for you to use in your version of the app.

Add the following function to the project’s db.js file:

Click here to view code image

function queueFeedback(db, feedback) {
  console.log('queueFeedback()');
  return new Promise((resolve, reject) => {
    let request = db.transaction([STORE_NAME], "readwrite")
      .objectStore(STORE_NAME)
      .add({ timestamp: Date.now(), sentiment: feedback });

    request.onsuccess = function (event) {
      console.log('queueFeedback: Successfully added feedback');
      navigator.serviceWorker.ready.then(reg => {
        console.log('queueFeedback: Registering sync event');
        // fire off the sync request
        // to the service worker
        reg.sync.register('feedback')
          .then(() => {
            // tell the user
            Swal.fire({
              type: 'info',
              title: 'Request Queued',
              text: 'Your sentiment rating was queued for ' +
                'submission to the server.',
              footer: 'Please refresh the page.'
            });
            // and resolve the promise
            resolve();
          })
          .catch(() => {
            // I can't think of why this would happen
            reject();
          })
      });
    };
    request.onerror = function (event) {
      // unable to create transaction
      reject(db.error);
    };
  });
};

The complete service worker code for this example is in the project folder’s publicchapter-codedb.js file.

Finally, we need the Feedback page to load this new JavaScript file. Open the project’s publicfeedback.html and add the following lines to the bottom of the page’s body section, along with the other script tags.

Click here to view code image

<!-- Add the indexedDB module -->
<script src='js/db.js'></script>

Save your changes to both files and refresh the Home page, then switch to the Feedback page. Remember, the service worker loads from the project’s index.html file but reigns over all pages of the app. You must refresh the Home page to load the updates to the service worker, then switch to the Feedback page to load the other half of our code changes.

Select one of the sentiments from the dropdown field and click the Share Sentiment button. The app should immediately display the queue dialog shown in Figure 5.5. At this point, we think we queued some data for processing by the service worker—let’s check.

Open the browser’s developer tools and switch to the Application tab. In the left navigator, expand the IndexedDB option and refresh the content. You should see the feedback data queued up, as shown in Figure 5.6.

The data is still there because we haven’t added any code to the service worker to process it; we’ll do that in the next section.

Finishing the Service Worker

Our final step is to complete the enhancements to the service worker so it knows how to process the feedback queue. In this section, we

• Add a reference to the new db.js file in the service worker.

• Finish the code in the service worker’s sync event listener.

• Add two functions to the project’s db.js file.

Open the project’s publicsw.js file and add the following lines of code to the top of the file:

Click here to view code image

// the server feedback API endpoint
const FEEDBACK_URL = `${self.location.origin}/api/sentiment`;

This service worker will use this constant to connect to the server when processing feedback.

Next, add the following line to the install event listener before the call to skipWaiting():

self.importScripts('./js/db.js');

Remember, the service worker runs in a separate process from the web application, so it doesn’t know you’ve already loaded the database library in the feedback page. You must explicitly load it in the service worker as well.

The result should look like this:

Click here to view code image

self.addEventListener('install', event => {
  // fires when the browser installs the app
  // here we're just logging the event and the contents
  // of the object passed to the event. the purpose of this event
  // is to give the service worker a place to set up the local
  // environment after the installation completes.
  console.log(`SW: Event fired: ${event.type}`);
  console.dir(event);
  self.importScripts('./js/db.js');
  // Force service worker activation
  self.skipWaiting();
});

All right, now it’s time to tell the service worker how to process the queued feedback. The code we’re about to work through is probably the most complicated code we’ve looked at so far. To explain it as cleanly as I can, I’ve identified the high-level steps in Table 5.1.

Everything the service worker does here is asynchronous, so I’m using promises everywhere. Update the existing sync event listener in the project’s service worker; I’ll explain the code after you’re done reading it:

Click here to view code image

self.addEventListener('sync', event => {
  console.log('SW: Sync event fired');
  if (event.tag === 'feedback') {
    console.log('SW: Processing Feedback sync');
    event.waitUntil(
      getFeedbackItems()
        .then(data => {
          return Promise.all(
            // loop through the items array
            data.items.map(function (feedbackItem) {
              // update the server if you can
              return fetch(FEEDBACK_URL, {
                method: 'post',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({
                  sentiment: feedbackItem.sentiment
                })
              })
                .then(() => {
                  // successfully posted,
                  // so whack the record at idx
                  return deleteFeedback(data.db, feedbackItem.idx)
                })
                .catch(error => {
                  // ruh roh, something went wrong
                  console.error(`SW: Sync Error: ${error}`);
                })
            })
          );
        }));
  } else {
    // this should never happen
    console.log(`SW: Unrecognized sync event (${event.tag})`);
  }
});

Here’s what the code does:

• We don’t want the browser to shut down the service worker until it’s done processing the queue, so the code starts with a call to event.waitUntil() that instructs the browser’s SyncManager to wait until we’re done.

• waitUntil expects a promise, so getFeedbackItems creates one (we’ll add that code in a minute) then gets to work.

• getFeedbackItems connects to the database and builds an array of all the feedback items, then returns it as the result of the promise.

• The code loops through the feedback item array. It uses Promise.all() to say it’s about to make a bunch of promises, and it will resolve (success) if they all succeed or reject (failure) if one fails.

• Inside that Promise.all(), it uses the array.map() method to execute a function against each element in the array.

• The map method makes a call to fetch() to POST the data to the server for each item in the array. The fetch method returns a promise, so that makes Promise.all() happy.

• When the POST completes successfully, the code calls deleteFeedback(), which deletes the processed item from the store (we’ll add that code in a minute). Oh, and deleteFeedback returns a promise too.

The result is that if the feedback item is successfully uploaded to the server (using fetch), the processed item is deleted from the store. That was a lot of code to accomplish that simple act, wasn’t it?

The reason promises are so important here is because promises give the code an easy way to filter results back up through the cascading method calls I just explained. If just one part of the process fails, for whatever reason, we want everything left in place for the next time the service worker wakes up to process the queue. Promises give us an easy way to manage that.

The complete service worker code for this example is in the project folder’s publicchapter-codesw-5.js file.

Most browser developer tools provide a way to send sync messages to a service worker directly from the browser (rather than having to do it via code). In Google’s Chrome browser, open the developer tools, switch to the Application tab, then select the Service worker panel, as shown in Figure 5.7. Look for the Sync input field highlighted in the figure. Enter the sync tag, then click the Sync button to send the tag to the sync event listener in the service worker.

With the service worker all sorted out, open the project’s public/js/db.js file. At the bottom of the file, add the following function:

Click here to view code image

function getFeedbackItems() {
  console.log('DB: getFeedbackItems()');

  // will hold the array of feedback items
  let items = [];

  return new Promise((resolve, reject) => {
    // yes, save the feedback to the database
    openIDB()
      .then(db => {
        let request = db.transaction([STORE_NAME], "readonly")
          .objectStore(STORE_NAME)
          .openCursor();

        // success!
        request.onsuccess = function (event) {
          // get a handle to the cursor
          var cursor = event.target.result;
          // do we have a valid cursor?
          if (cursor) {
            // add the feedback item to the array
            items.push(cursor.value);
            // move onto the next item in the object store
            cursor.continue();
          } else {
            // no valid cursor, so must be at the end
            resolve({ db: db, items: items });
          }
        };

        // ugh, error
        request.onerror = function (event) {
          console.error(request.error);
          reject(request.error);
        }
      })  // openIDB()
      .catch(error => {
        console.error(request.error);
        reject(request.error);
      }); // openIDB()
  });
};

The getFeedbackItems function

• Creates a promise (of course).

• Opens the IndexedDB database.

• Opens a cursor in the feedback-store store.

• Loops through each object in the store using the cursor.

• Adds each object to the items array.

• Returns the database object and items array.

The code returns the database object so the next function we’ll add can use it. It simplifies the code by not forcing me to create an ugly global variable to hold the database object.

Finally, add the following function to the bottom of the db.js file:

Click here to view code image

function deleteFeedback(db, idx) {
  console.log(`DB: deleteFeedback: Processing index ${idx}`);

  return new Promise((resolve, reject) => {
    // create a transaction
    let request = db.transaction([STORE_NAME], "readwrite")
      .objectStore(STORE_NAME)
      .delete(idx);

    // success!
    request.onsuccess = function (event) {
      console.log(`DB: deleteFeedback: Item ${idx} deleted`);
      resolve(idx);
    }
    // ugh, error
    request.onerror = function (event) {
      console.log(`DB: deleteFeedback: Unable to delete item ${idx}`);
      console.error(transaction.error);
      reject(transaction.error);
    }
  });
};

The deleteFeedback function

• Gets the database object and the index of the feedback item being deleted as parameters passed to the function.

• Creates a promise (of course).

• Using the database object, creates a transaction for managing the changes to the data store.

• Deletes the selected item (using its index as a pointer to the feedback item being deleted).

The complete service worker code for this example is in the project folder’s publicchapter-codedb.js file.

At this point, we’re done with code changes. Save all the changes to the files, switch to the browser, and refresh the Home page. Remember, the service worker loads from the project’s index.html file but reigns over all pages of the app. You must refresh the Home page to load the updates to the service worker, then switch to the Feedback page to load the other half of our code changes.

Go ahead and submit a new feedback, then switch to the Developer Tools console page. You should see your queued-up feedback items processing, as shown in Figure 5.8.

Try taking the application offline and submitting some feedback. When you turn the network connection back on, the service worker should wake up and immediately process the queued items.

We just went through a lot of code and generated a lot of promises, but we now have a version of the PWA News site that works as expected online or offline.

Dealing with Last Chances

Early on, I mentioned that if background sync fails, then the browser will retry it again later. What I didn’t say, and what is not documented, is how many times the browser will retry until it gets it right. I heard somewhere that browsers use an internal exponential backoff algorithm to control how frequently they retry. Looking around to understand this better, I came across an article titled Chrome, the Background Sync API and Exponential Backoff, which looks at this specific question.

Thinking about this problem, you’d think the browser would retry 5, 10, or 20 times before abandoning a sync event, but it turns out that browsers such as Chrome retry the sync only twice before abandoning it. To quote a line from Kevin Kline’s character in A Fish Called Wanda: “Disappointed!”

For our simple PWA News Feedback page, trying to deliver the data only three times isn’t a big deal. For a more transactional app such as a chat app or banking app, I really want more. The good news is that the browser’s SyncManager at least tells you when it’s about to abandon your request. The following listing contains a quick copy and paste of the event object passed to the service worker’s sync event listener. In there you should see the lastChance property. It’s false now, because it was grabbed from a first pass at processing the sync event.

Click here to view code image

bubbles: false
cancelBubble: false
cancelable: false
composed: false
currentTarget: ServiceWorkerGlobalScope {clients: Clients, registration:
  ServiceWorkerRegistration, onactivate: null, onfetch: null, oninstall: null, ...}
defaultPrevented: false
eventPhase: 0
isTrusted: true
lastChance: false
path: []
returnValue: true
srcElement: ServiceWorkerGlobalScope {clients: Clients, registration:
  ServiceWorkerRegistration, onactivate: null, onfetch: null, oninstall: null, ...}
tag: "feedback"
target: ServiceWorkerGlobalScope {clients: Clients, registration:
  ServiceWorkerRegistration, onactivate: null, onfetch: null, oninstall: null, ...}
timeStamp: 0
type: "sync"
_ _proto_ _: SyncEvent

When the browser’s SyncManager has had enough with this sync event, it switches lastChance to true so you’ll know what’s coming next and can act the way that makes the most sense for your app.

In the service worker, you could do something like this:

Click here to view code image

// is this the last time the browser will
// process this event?
if (event.lastChance) {
  console.warn(`SW: ${event.tag.toUpperCase()} sync last chance`);
}

This just throws a warning to the console, but the user will never see that, and it doesn’t actually do anything. Do you remember earlier when I mentioned that you could register a sync event inside of the service worker? Well, that is one way to keep this sync event alive. If your code learns that the SyncManager is about to abandon this sync event and there’s still data to process, simply resubmit the background sync using

Click here to view code image

self.registration.sync.register('feedback')

This is a little dangerous in that it forces the service worker to process the event forever, but hey, it works.

So, in our current service worker example, the preceding code would go into the sync event listener:

Click here to view code image

self.addEventListener('sync', event => {
  console.log('SW: Sync event fired');
  // is this the last time the browser will
  // process this event?
  if (event.lastChance) {
    console.warn(`SW: ${event.tag.toUpperCase()} sync last chance`);
  }
  if (event.tag === 'feedback') {
    console.log('SW: Processing Feedback sync');
    event.waitUntil(
      getFeedbackItems()
        .then(data => {
          return Promise.all(
            // loop through the items array
            data.items.map(function (feedbackItem) {
              // update the server if you can
              return fetch(FEEDBACK_URL, {
                method: 'post',
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({
                  sentiment: feedbackItem.sentiment
                })
              })
                .then(() => {
                  // successfully posted,
                  // so whack the record at idx
                  return deleteFeedback(data.db, feedbackItem.idx)
                })
                .catch(error => {
                  // ruh roh, something went wrong
                  console.error(`SW: Sync Error: ${error}`);
                  if (event.lastChance) {
                    // do something to handle the last event
                    // warn the user, submit the event again
                    self.registration.sync.register('feedback');
                  }
                })
            })
          );
        }));
  } else {
    // this should never happen
    console.log(`SW: Unrecognized sync event (${event.tag})`);
  }
});

All right, back to this exponential fallback algorithm. Because the referenced article was a little old, I thought things might have changed in the browser, so using the article’s code as a starting point, I embellished it a bit and ran it in the browser to see how the browser manages fallback. Trust, but verify, right? You can find my complete code listing in learning-pwa-codechapter-05fallback-test.

What I did to test this code was load it in the browser, then stop the server process running in the terminal window. What I learned is highlighted in Figure 5.9.

When the SyncManager detects that it can’t complete processing a sync event, it waits 5 minutes and tries again. If the retry fails, the SyncManager waits 15 minutes and tries it again, but this time it switches the lastChance property from false to true. That’s not a very sophisticated algorithm; I can’t imagine a PhD over at Google spent a lot of time on that one.

Anyway, that’s a limitation of background sync you must be aware of and accommodate in your apps. If the data is important, you’re going to have to force the browser to retry the sync more than twice using the strategy I presented in this section.