Service Worker in Ruby on Rails einrichten

Webworker sind die vielversprechendste Zukunft von HTML5. Bereiten Sie Ihre Rails-App vor.

Ein Service Worker ist ein Skript, das Ihr Browser unabhängig von einer Webseite im Hintergrund ausführt und die Tür zu Funktionen öffnet, die keine Webseite oder Benutzerinteraktion erfordern.

Service Worker sind isolierte Browser-Threads, die im Hintergrund in einem völlig anderen Kontext als der Webseite laufen und daher keinen Zugriff auf das DOM, das Fenster oder das Dokumentobjekt haben.

Wir nutzen Service Worker bereits seit einiger Zeit für Pasilobus-Apps. Mithilfe von Servicemitarbeitern können wir Serveranfragen auf Browserebene abfangen und verschiedene Aktionen auslösen oder sogar eine zwischengespeicherte Version Ihrer App bereitstellen, ohne dass die Verbindung der Benutzer unterbrochen wird.

Servicemitarbeiter ermöglichen auch eine Hintergrundsynchronisierung, sodass Ihre App mithilfe von Servicemitarbeitern die Daten weiterhin verarbeiten und wieder mit dem Server synchronisieren kann, wenn die Internetverbindung unterbrochen wird, sobald die Verbindung wiederhergestellt ist.

Das Hinzufügen eines Servicemitarbeiters zu einer Rails-App ist einfach. Beginnen Sie mit der Herstellung eines Controllers dafür

 class ServiceworkerController < ApplicationController
 layout false

 def service_worker
 end
 end

Dann fügen wir eine Route für unseren Servicemitarbeiter hinzu

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

Um den Service Worker aufzurufen, müssen wir der Asset-Pipeline ein Skript hinzufügen. Wenn Sie Rails 6 verwenden, sollte dieses in den Webpack- und Javascript-Ordner gehen:

 # 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; 
}

 // Service Worker nur verwenden, wenn der Browser ES6 unterstützt,
 // die Cache-API und natürlich die Servicemitarbeiter selbst.
 if (browserSupportsES6() && ('caches' in window) && ('serviceWorker' in navigator)) {
 navigator.serviceWorker.register('/service-worker.js', { Scope: '/' })
 .then(function(reg) {
 //console.log('Service-Worker-Registrierung erfolgreich!');
 }).catch(function(error) { 
//console.log('Service-Worker-Registrierung fehlgeschlagen: ' + Fehler);
 });
 }
 

 # javascript/packs/application.js

 import "src/service_worker.js"

Dadurch wird unser Servicemitarbeiter registriert, sobald der Benutzer die App im Browser öffnet.

Und natürlich eine Ansichtsdatei für den eigentlichen Arbeiter erstellen

 # views/serviceworker/service_worker.js.erb

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


 Funktion 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);

Unser einfacher Worker enthält eine Funktion, die bei einem Installationsereignis ausgelöst wird und den Browser anweist, Assets und die Offline.html-Beispielseite zwischenzuspeichern, die dem Benutzer angezeigt wird, wenn die Verbindung unterbrochen wird.

Fügen wir auch unsere offline.html-Datei hinzu

 # views/errors/offline.html.erb
 
<h1>Hey, ich bin eine Seite, die von service worker.js<h1> bereitgestellt wird

Service-Worker laufen nach einer gewissen Zeit ab. Wenn Sie also die Datei jemals ändern, aktualisieren Browser den Service-Worker automatisch.

Bei der Entwicklung mit Servicemitarbeitern. Denken Sie daran, sie im Browser zu deaktivieren, damit sie Ihre Arbeit nicht beeinträchtigen.

Und das ist alles. Beginnen Sie mit den Mitarbeitern und stellen Sie Ihren Benutzern eine benutzerdefinierte Offline-Warnseite zur Verfügung.