Configuración de Service Worker en Ruby on Rails

Los webworkers son el futuro más prometedor de HTML5; prepare su aplicación Rails.

Un "service worker" es un script que su navegador ejecuta en segundo plano, separado de una página web, abriendo la puerta a funcionalidades que no necesitan una página web ni interacción del usuario.

Los "service workers" son hilos de navegador aislados que se ejecutan en segundo plano, en un contexto completamente diferente al de la página web y, por lo tanto, no tienen acceso al DOM, a la ventana o al objeto documento.

Hemos estado utilizando Service Workers en las aplicaciones de Pasilobus desde hace algún tiempo. Utilizando "service workers", podemos interceptar las solicitudes realizadas por el servidor a nivel del navegador y activar diferentes acciones o incluso servir una versión en caché de su aplicación para que los usuarios nunca se desconecten.

Los "service workers" también permiten la sincronización en segundo plano, de modo que, incluso si se pierde la conexión a Internet, su aplicación puede seguir procesando los datos y sincronizarlos con el servidor tan pronto como se restablezca la conexión.

Añadir un "service worker" a una aplicación Rails es fácil. Empiece por crear un controlador para ello:

class ServiceworkerController < ApplicationController
  layout false

  def service_worker
  end
end

Ahora, agreguemos una ruta para nuestro "service worker":

# Service Worker
get '/service-worker.js' => "serviceworker#service_worker"

Para llamar al "service worker", necesitamos añadir un script al "asset pipeline"; si está usando Rails 6, esto debe ir a la carpeta de webpack y javascript:

# javascript/src/service_worker.js

// Use feature-detection to check for ES6 support.
function browserSupportsES6() {
  try { eval("var foo = (x)=>x+1"); }
  catch (e) { return false; }
  return true;
}

// Use service workers only if the browser supports ES6,
// the Cache API and of course Service Workers themselves.
if (browserSupportsES6() && ('caches' in window) && ('serviceWorker' in navigator)) {
  navigator.serviceWorker.register('/service-worker.js', { scope: '/' })
  .then(function(reg) {
     //console.log('Service worker registration succeeded!');
  }).catch(function(error) {
     //console.log('Service worker registration failed: ' + error);
  });
}

# javascript/packs/application.js

import "src/service_worker.js"

Esto registrará nuestro "service worker" tan pronto como el usuario abra la aplicación en el navegador.

Y, por supuesto, cree un archivo de vista para el "worker" real.

# views/serviceworker/service_worker.js.erb

var CACHE_VERSION = 'v1';
var CACHE_NAME = CACHE_VERSION + ':sw-cache-APPNAME';


function onInstall(event) {
  // console.log('[Serviceworker]', "Installing!", event);
  event.waitUntil(
    caches.open(CACHE_NAME).then(function prefill(cache) {
      return cache.addAll([
        '<%= asset_pack_path 'application.js' %>',
        '<%= asset_pack_path 'application.css' %>',
        '/offline.html'
      ]);
    })
  );
}

self.addEventListener('install', onInstall);

Nuestro "worker" simple contiene una función que se activa en el evento de instalación, y le dice al navegador que almacene en caché los activos y la página de ejemplo offline.html que se servirán al usuario cuando se pierda la conexión.

Vamos a añadir también nuestro archivo offline.html

# views/errors/offline.html.erb

<h1>Hey I am page served by service worker.js<h1>

Los "service workers" caducan después de un período de tiempo, por lo tanto, si alguna vez cambia el archivo, los navegadores actualizarán el "service worker" automáticamente.

Al desarrollar con "service workers", recuerde deshabilitarlos en el navegador para que no interfieran con su trabajo.

Y eso es todo. Empiece a usar "workers" y muestre una página de advertencia personalizada sin conexión para sus usuarios.