服务工作者在浏览器离线时保存表单数据

Question

我是Service Worker的新手，并且浏览了各种文档（Google，Mozilla，serviceworke.rs，Github，StackOverflow问题）。最有用的是ServiceWorkers食谱。

大多数文档似乎都指向缓存整个页面，以便该应用程序完全脱机工作，或者将用户重定向到脱机页面，直到浏览器可以重定向到Internet。

但是，我想做的是将表单数据存储在本地，以便我的Web应用程序可以在用户连接恢复后将其上传到服务器。我应该使用哪个“食谱”？我认为这是Request Deferrer。我是否需要其他任何东西来确保Request Deferrer可以正常工作（除了我网页中的Service Worker检测器脚本之外）？任何提示和技巧大加赞赏。

控制台错误

Request Deferrer配方和代码似乎不单独工作，因为它不包含文件缓存。我为服务工作者库文件添加了一些缓存，但是在脱机时提交表单时仍然出现此错误：

Console: {"lineNumber":0,"message":
"The FetchEvent for [the form URL] resulted in a network error response: 
the promise was rejected.","message_level":2,"sourceIdentifier":1,"sourceURL":""}

我的服务人员

/* eslint-env es6 */
/* eslint no-unused-vars: 0 */
/* global importScripts, ServiceWorkerWare, localforage */
importScripts('/js/lib/ServiceWorkerWare.js');
importScripts('/js/lib/localforage.js');

//Determine the root for the routes. I.e, if the Service Worker URL is http://example.com/path/to/sw.js, then the root is http://example.com/path/to/


var root = (function() {
  var tokens = (self.location + '').split('/');
  tokens[tokens.length - 1] = '';
  return tokens.join('/');
})();

//By using Mozilla’s ServiceWorkerWare we can quickly setup some routes for a virtual server. It is convenient you review the virtual server recipe before seeing this.


var worker = new ServiceWorkerWare();

//So here is the idea. We will check if we are online or not. In case we are not online, enqueue the request and provide a fake response. 
//Else, flush the queue and let the new request to reach the network.


//This function factory does exactly that.


function tryOrFallback(fakeResponse) {

//Return a handler that…


  return function(req, res) {

//If offline, enqueue and answer with the fake response.


    if (!navigator.onLine) {
      console.log('No network availability, enqueuing');
      return enqueue(req).then(function() {

//As the fake response will be reused but Response objects are one use only, we need to clone it each time we use it.


        return fakeResponse.clone();
});
}

//If online, flush the queue and answer from network.


    console.log('Network available! Flushing queue.');
    return flushQueue().then(function() {
      return fetch(req);
});
};
}

//A fake response with a joke for when there is no connection. A real implementation could have cached the last collection of updates and keep a local model. For simplicity, not implemented here.


worker.get(root + 'api/updates?*', tryOrFallback(new Response(
  JSON.stringify([{
    text: 'You are offline.',
    author: 'Oxford Brookes University',
    id: 1,
    isSticky: true
}]),
  { headers: { 'Content-Type': 'application/json' } }
)));

//For deletion, let’s simulate that all went OK. Notice we are omitting the body of the response. Trying to add a body with a 204, deleted, as status throws an error.


worker.delete(root + 'api/updates/:id?*', tryOrFallback(new Response({
    status: 204
})));

//Creation is another story. We can not reach the server so we can not get the id for the new updates. 
//No problem, just say we accept the creation and we will process it later, as soon as we recover connectivity.


worker.post(root + 'api/updates?*', tryOrFallback(new Response(null, {
    status: 202
})));

//Start the service worker.


worker.init();

//By using Mozilla’s localforage db wrapper, we can count on a fast setup for a versatile key-value database. We use it to store queue of deferred requests.


//Enqueue consists of adding a request to the list. Due to the limitations of IndexedDB, Request and Response objects can not be saved so we need an alternative representations. 
//This is why we call to serialize().`


function enqueue(request) {
  return serialize(request).then(function(serialized) {
    localforage.getItem('queue').then(function(queue) {
      /* eslint no-param-reassign: 0 */
      queue = queue || [];
      queue.push(serialized);
      return localforage.setItem('queue', queue).then(function() {
        console.log(serialized.method, serialized.url, 'enqueued!');
      });
    });
  });
}

//Flush is a little more complicated. It consists of getting the elements of the queue in order and sending each one, keeping track of not yet sent request. 
//Before sending a request we need to recreate it from the alternative representation stored in IndexedDB.


function flushQueue() {

//Get the queue


  return localforage.getItem('queue').then(function(queue) {
    /* eslint no-param-reassign: 0 */
    queue = queue || [];

//If empty, nothing to do!


    if (!queue.length) {
      return Promise.resolve();
    }

//Else, send the requests in order…


    console.log('Sending ', queue.length, ' requests...');
    return sendInOrder(queue).then(function() {

        //Requires error handling. Actually, this is assuming all the requests in queue are a success when reaching the Network. 
        //    So it should empty the queue step by step, only popping from the queue if the request completes with success.


      return localforage.setItem('queue', []);
    });
  });
}

//Send the requests inside the queue in order. Waiting for the current before sending the next one.


function sendInOrder(requests) {

//The reduce() chains one promise per serialized request, not allowing to progress to the next one until completing the current.


  var sending = requests.reduce(function(prevPromise, serialized) {
    console.log('Sending', serialized.method, serialized.url);
    return prevPromise.then(function() {
      return deserialize(serialized).then(function(request) {
        return fetch(request);
      });
    });
  }, Promise.resolve());
  return sending;
}

//Serialize is a little bit convolved due to headers is not a simple object.


function serialize(request) {
  var headers = {};

//for(... of ...) is ES6 notation but current browsers supporting SW, support this notation as well and this is the only way of retrieving all the headers.


  for (var entry of request.headers.entries()) {
    headers[entry[0]] = entry[1];
  }
  var serialized = {
    url: request.url,
    headers: headers,
    method: request.method,
    mode: request.mode,
    credentials: request.credentials,
    cache: request.cache,
    redirect: request.redirect,
    referrer: request.referrer
  };

//Only if method is not GET or HEAD is the request allowed to have body.


  if (request.method !== 'GET' && request.method !== 'HEAD') {
    return request.clone().text().then(function(body) {
      serialized.body = body;
      return Promise.resolve(serialized);
    });
  }
  return Promise.resolve(serialized);
}

//Compared, deserialize is pretty simple.


function deserialize(data) {
  return Promise.resolve(new Request(data.url, data));
}

var CACHE = 'cache-only';

// On install, cache some resources.
self.addEventListener('install', function(evt) {
    console.log('The service worker is being installed.');

    // Ask the service worker to keep installing until the returning promise
    // resolves.
    evt.waitUntil(precache());
});

// On fetch, use cache only strategy.
self.addEventListener('fetch', function(evt) {
    console.log('The service worker is serving the asset.');
    evt.respondWith(fromCache(evt.request));
});

// Open a cache and use `addAll()` with an array of assets to add all of them
// to the cache. Return a promise resolving when all the assets are added.
function precache() {
    return caches.open(CACHE).then(function (cache) {
        return cache.addAll([
          '/js/lib/ServiceWorkerWare.js',
          '/js/lib/localforage.js',
          '/js/settings.js'
        ]);
    });
}

// Open the cache where the assets were stored and search for the requested
// resource. Notice that in case of no matching, the promise still resolves
// but it does with `undefined` as value.
function fromCache(request) {
    return caches.open(CACHE).then(function (cache) {
        return cache.match(request).then(function (matching) {
            return matching || Promise.reject('no-match');
        });
    });
}

这是我离线时在Chrome中收到的错误消息：

（在Firefox中发生了类似的错误-它位于的第409行ServiceWorkerWare.js）

   ServiceWorkerWare.prototype.executeMiddleware = function (middleware, 
request) {
        var response = this.runMiddleware(middleware, 0, request, null);
        response.catch(function (error) { console.error(error); });
        return response;
    };

Answer 1

这比初学者水平要先进一些。但是您将需要检测何时离线或处于Li-Fi状态。除了将数据发布到API或端点之外，您还需要排队等待联机时同步的数据。这就是Background Sync API应该提供的帮助。但是，目前尚无全面支持。再加上Safari .........因此，也许一个好的策略是将您的数据保存在IndexedDB中，并且当您可以连接（后台同步为此触发事件）时，您便可以发布数据。对于不支持服务人员（Safari）或尚不具备Background Sync（即将淘汰）的浏览器，它会变得更加复杂。与往常一样，将代码设计为渐进式增强，这可能很棘手，但最终还是值得的。

Answer 2

Service Worker 倾向于缓存静态 HTML、CSS、JavaScript 和图像文件。

\n\n

我需要使用 PouchDB 并将其与 CouchDB 同步

\n\n

为什么选择 CouchDB？

\n\n

\n
• CouchDB 是一个 NoSQL 数据库，由许多使用 JSON 创建的文档组成。
\n
• 它具有版本控制（每个文档都有一个 _rev\n属性以及最后修改日期）
\n
• 它可以与 PouchDB 同步，PouchDB 是一个本地 JavaScript 应用程序，可使用 IndexedDB 通过浏览器将数据存储在本地存储中。这使我们能够创建\n离线应用程序。
\n
• 这两个数据库都是\xe2\x80\x9cmaster\xe2\x80\x9d 数据的副本。
\n

\n\n

PouchDB是 CouchDB 的本地 JavaScript 实现。

\n