CODEWITHSUNDEEP
javascriptcachingofflineservice-worker
Ryan Griggs
Ryan Griggs

Reputation: 2758

Force Service Worker to only return cached responses when specific page is open

I have built a portal which provides access to several features, including trouble ticket functionality.

The client has asked me to make trouble ticket functionality available offline. They want to be able to "check out" specific existing tickets while online, which are then accessible (view/edit) while the user's device is out-of-range of any internet connection. Also, they want the ability to create new tickets while offline. Then, when the connection is available, they will check in the changed/newly created tickets.

I have been tinkering with Service Workers and reviewing some good documentation on them, and I feel I have a basic understanding of how to cache the data.

However, since I only want to make the Ticketing portion of the portal available offline, I don't want the service worker caching or returning cached data when any other page of the portal is being accessed. All pages are in the same directory, so the service worker, once loaded, would by default intercept all requests from all pages in the portal.

How can I set up the service worker to only respond with cached data when the Tickets page is open?

Do I have to manually check the window.location value when fetch events occur? For example, 

if (window.location == 'https://www.myurl.com/tickets')
{
    // try to get the request from network. If successful, cache the result.
    // If not successful, try returning the request from the cache.
}
else
{
    // only try the network, and don't cache the result.
}

There are many supporting files that need to be loaded for the page (i.e. css files, js files, etc.) so it's not enough to simply check the request.url for the page name. Will 'window.location' be accessible in the service worker event, and is this a reasonable way to accomplish this?

Upvotes: 1

Views: 73

Answers (1)

Jeff Posnick
Jeff Posnick

Reputation: 56144

Use service worker scoping

I know that you mentioned that you currently have all pages served from the same directory... but if you have any flexibility over your web app's URL structure at all, then the cleanest approach would be to serve your ticket functionality from URLs that begin with a unique path prefix (like /tickets/) and then host your service worker from /tickets/service-worker.js. The effort to reorganize your URLs may be worthwhile if it means being able to take advantage of the default service worker scoping and just not have to worry about pages outside of /tickets/ being controlled by a service worker.

Infer the referrer

There's information in this answer about determining what the referring window client URL is from within your service worker's fetch handler. You can combine that with an initial check in the fetch handler to see if it's a navigation request and use that to exit early.

const TICKETS = '/tickets';
self.addEventListener('fetch', event => {
  const requestUrl = new URL(event.request.url);
  if (event.request.mode === 'navigate' && requestUrl.pathname !== TICKETS) {
    return;
  }

  const referrerUrl = ...; // See https://stackoverflow.com/questions/50045641
  if (referrerUrl.pathname !== TICKETS) {
    return;
  }

  // At this point, you know that it's either a navigation for /tickets,
  // or a request for a subresource from /tickets.
});

Upvotes: 2

Related Questions