Comment 17 for bug 1706107

Dan,

I tried to explain the reason behind using UpUp in IRC; I'm sorry I failed at that.

My decision to use UpUp instead of Workbox (or any other massive framework) came down to complexity. For what we need to accomplish in offline mode, the simplest possible thing that could work is preferable, IMO. All we need is to make sure that the HTML, CSS, and JS are available in a local cache that is not subject to the whims of a user that wants to clear the normal browser cache at arbitrary times. Using UpUp for what we need was (for me) an order of magnitude simpler than Workbox, based on the examples. Put plainly, using UpUp is exactly one self-explanatory JS command in one place.

We can change to loading it via npm, but I included it directly for a specific reason. UpUp currently uses the stable ServiceWorker API, and it works. For an interface that will be tested just about the least in practice, and used the most by staff that are under stress, I judged it wiser that the code should be as stable and predictable as possible. Based on that logic I decided that pinning it was best. I'm open to debate on that.

Now, with all that said, I have to ask: do we as a project have plans to add some sort of public offline functionality? I'm honestly not sure what the point of that would be, unless we wanted to rewrite the TPAC as a modern "app", optimize interfaces with SW caching, and go back to the conceptual model we had with the JSPAC of fetching the data with APIs -- basically, extend what we've done with the staff client to the OPAC. If we were to do that then whatever full SW framework we use can be a drop-in replacement for UpUp. But, until then, the time investment isn't (IMO) worth it -- there's no practical benefit.

If someone wants to put in the time and testing to replace UpUp, I certainly won't stop them, but I'd consider that wasted tuits, personally.