Service Worker 在浏览器离线时保存表单数据

2024-02-27

我是 Service Workers 的新手,并且已经浏览了各种文档(Google https://developers.google.com/web/fundamentals/getting-started/primers/service-workers, Mozilla https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API, 服务人员 https://serviceworke.rs/, Github https://github.com/w3c/ServiceWorker/blob/master/explainer.md, StackOverflow 问题 https://stackoverflow.com/questions/tagged/service-worker)。最有帮助的是ServiceWorkers 食谱 https://serviceworke.rs/.

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

然而,我想要做的是将表单数据存储在本地,以便我的网络应用程序可以在用户连接恢复时将其上传到服务器。我应该使用哪个“食谱”?我觉得是这样的请求延迟者 https://serviceworke.rs/request-deferrer.html。我是否需要其他任何东西来确保 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;
    };

这比初学者水平更高级一些。但您需要检测您何时处于离线状态或处于 Li-Fi 状态。您不需要将数据发布到 API 或端点,而是需要对该数据进行排队,以便在您重新上线时进行同步。 这正是后台同步 API 应该提供帮助的地方。然而,它尚未得到全面支持。加上野生动物园...... 因此,也许一个好的策略是将数据保存在 IndexedDB 中,当您可以连接时(后台同步为此触发一个事件),您将发布数据。对于不支持服务工作人员 (Safari) 或尚未具备后台同步功能(很快就会稳定下来)的浏览器,情况会变得更加复杂。 与往常一样,将代码设计为渐进增强,这可能很棘手,但最终是值得的。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Service Worker 在浏览器离线时保存表单数据 的相关文章

随机推荐