Question

我是Service Workers的新手，已经查看了各种文档（Google，Mozilla，serviceworke.rs，Github，{{3} }）。最有帮助的是StackOverflow questions。

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

然而，我想要做的是在本地存储我的表单数据，以便我的Web应用程序可以在用户的连接恢复时将其上载到服务器。我应该使用哪种“食谱”？我认为这是ServiceWorkers cookbook。我还需要其他任何东西来确保Request Deferrer能够正常工作（除了我的网页中的服务工作者检测器脚本）吗？任何提示和技巧都非常赞赏。

控制台错误

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中收到的错误消息：

Request Deferrer

（Firefox中出现了类似的错误 - 它在ServiceWorkerWare.js的第409行落后）

   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中，当您可以连接时（后台同步为此触发事件），然后您将POST数据。对于不支持服务工作者（Safari）或者还没有后台同步（很快就会升级）的浏览器，它会变得有点复杂。一如既往地将您的代码设计为渐进增强，这可能很棘手，但最终还是值得的。

Answer 2

服务工作者倾向于缓存静态HTML，CSS，JavaScript和图像文件。

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

为何选择CouchDB？

CouchDB是一个由许多文档组成的NoSQL数据库用JSON创建。
它有版本控制（每个文档都有_rev 具有上次修改日期的财产）
可与之同步 PouchDB，一种本地JavaScript应用程序，用于在本地存储数据使用IndexedDB通过浏览器进行存储。这允许我们创造离线申请。
这两个数据库都是“主”副本数据。

PouchDB 是CouchDB的本地JavaScript实现。

Answer 3

我仍需要一个比解决方案的部分说明更好的答案！

是的，这种类型的服务工作者是用于离线保存表单数据的正确工具。

我现在已经对它进行了编辑并更好地理解了它。它缓存表单数据，并将其加载到页面上，以便用户查看他们输入的内容。

值得注意的是，库文件的路径需要编辑以反映您的本地目录结构，例如：在我的设置中：

importScripts('/js/lib/ServiceWorkerWare.js');
importScripts('/js/lib/localforage.js');

但是，脱机时脚本仍然失败，因为它没有缓存库文件。（当我想出缓存时更新以遵循）

刚刚为服务工作者（除了控制台）发现了一个额外的调试工具：chrome://serviceworker-internals/。在此，您可以启动或停止服务工作者，查看控制台消息以及服务工作者使用的资源。

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

3 个答案: