Background
I'm new to service workers but working on a library that is intended to become "offline-first" (really, almost "offline-only") (FWIW, the intent is to allow consumers of the library to provide JSON config representing tabular multilinear texts and get in return an app which allows their users to browse these texts in a highly customizable manner by paragraph/verse ranges.)
Other projects are to install the library as a dependency and then supply information via our JavaScript API such as the path of a JSON config file indicating the files that our app will consume to produce an (offline) app for them.
While I know we could do any of the following:
- require users provide a hard-coded path from which our service worker's
install
script could usewaitUntil
with its own JSON request to retrieve the user's necessary files - skip the service worker's
install
step of the service worker for the JSON file, and rely onfetch
events to update the cache, providing a fallback display if the user completed the install and went offline before the fetches could occur. - Post some state info from our main script to a server which the service worker, once registered, would query before completing its
install
event.
...but all choices seems less than ideal because, respectively:
- Our library's consumers may prefer to be able to designate their own location for their JSON config.
- Given that the JSON config designates files critical to showing their users anything useful, I'd rather not allow an install to complete only to say that the user has to go back online to get the rest of the files if they were not able to remain online after the
install
event to see all the required fetches occur. - Besides wanting to avoid more trips to the server and extra code, I'd prefer for our code to be so offline-oriented as to be able to work entirely on mere static file servers.
Question:
Is there some way to pass a message or state information into a service worker before the install
event occurs, whether as part of the query string of the service worker URL, or through a messaging event? The messaging event could even technically arrive after the install
event begins as long as it can occur before a waitUntil
within the install
is complete.
I know I could test this myself, but I'd like to know what best practices might be anyways when the critical app files must themselves be dynamically obtained as in such libraries as ours.
I'm guessing indexedDB
might be the sole alternative here (i.e., saving the config info or path of the JSON config to indexedDB, registering a service worker, and retrieving the indexedDB data from within the install
event)? Even this would not be ideal as I'm letting users define a namespace for their storage, but I need a way for it too to be passed into the worker, or otherwise, multiple such apps on the origin could clash.