Workbox gebruiken zonder precaching,Workbox gebruiken zonder precaching

Tot nu toe was deze documentatie groot op het gebied van precaching, waarbij vaak de build-tools generateSW en injectManifest aan bod kwamen. Hoewel er genoeg goede redenen zijn om precaching-logica in uw service worker op te nemen, hoeft u precaching niet te gebruiken om Workbox te gebruiken.

Misschien heeft uw project alleen runtime-caching nodig, of misschien wilt u een schonere manier om service worker-API's te integreren, zoals web push . Dit zijn gevallen waarin u de buildtools van Workbox niet wilt gebruiken, en dat wordt in dit artikel behandeld.

Bij gebruik van een bundelaar

Bundlers zijn prominent aanwezig in het webontwikkelingslandschap en de kans is groot dat uw project er een gebruikt. Als dit het geval is, is het belangrijk om te weten dat u geen bundelplug-in (zoals workbox-webpack-plugin ) hoeft te gebruiken als u niets vooraf cachet. U behandelt uw servicemedewerker als een afzonderlijk toegangspunt in uw aanvraag.

In de hoofdmap van de bronmap van uw project maakt u een servicemedewerker aan en gebruikt u alle Workbox-modules die uw toepassing nodig heeft. Hier is een voorbeeld zonder precaching, waarmee cachingstrategieën worden ingesteld voor navigatie- en afbeeldingsverzoeken in afzonderlijke Cache instanties:

// sw.js
import {NetworkFirst, CacheFirst} from 'workbox-strategies';
import {registerRoute, NavigationRoute, Route} from 'workbox-routing';

const navigationRoute = new NavigationRoute(new NetworkFirst({
  cacheName: 'navigations'
}));

const imageAssetRoute = new Route(({request}) => {
  return request.destination === 'image';
}, new CacheFirst({
  cacheName: 'image-assets'
}));

registerRoute(navigationRoute);
registerRoute(imageAssetRoute);

Vanaf hier is het een kwestie van deze servicemedewerker opgeven als toegangspunt in de bundelaar van uw keuze. Hieronder vindt u enkele voorbeelden van hoe u dat kunt doen in een aantal populaire bundelaars.

webpakket

webpack accepteert entrypunten in zijn entry . Er zijn een aantal dingen waar u op moet letten als u deze aanpak gebruikt:

  1. Om ervoor te zorgen dat uw servicemedewerker een zo breed mogelijk bereik heeft, wilt u dat deze wordt uitgevoerd naar de hoofdmap van uw uitvoermap.
  2. U wilt niet dat de servicemedewerker een versienummer krijgt, omdat updates ervan nieuwe hashes genereren die ertoe kunnen leiden dat meerdere servicemedewerkers op uw website worden ingezet.

Om aan de bovenstaande voorwaarden te voldoen, kan een functie worden doorgegeven aan output.filename , die onderzoekt of het huidige ingangspunt dat wordt verwerkt, het ingangspunt van de servicemedewerker is. Anders worden versiebestanden naar hun normale bestemmingen geschreven.

// webpack.config.js
import process from 'process';

const isProd = process.env.NODE_ENV === 'production';

export default {
  mode: isProd ? 'production' : 'development',
  context: process.cwd(),
  entry: {
    // Service worker entry point:
    sw: './src/sw.js',
    // Application entry point:
    app: './src/index.js'
  },
  output: {
    filename: ({runtime}) => {
      // Check if the current filename is for the service worker:
      if (runtime === 'sw') {
        // Output a service worker in the root of the dist directory
        // Also, ensure the output file name doesn't have a hash in it
        return '[name].js';
      }

      // Otherwise, output files as normal
      return 'js/[name].[contenthash:8].js';
    },
    path: './dist',
    publicPath: '/',
    clean: true
  }
};

oprollen

Rollup is een vergelijkbare situatie als webpack, behalve dat meerdere toegangspunten worden gespecificeerd als afzonderlijke configuratieobjecten die in een array worden geëxporteerd:

// rollup.config.js
import { nodeResolve } from '@rollup/plugin-node-resolve';
import replace from '@rollup/plugin-replace';

// Plugins common to both entry points
const plugins = [
  nodeResolve(),
];

export default [
  // Application entry point
  {
    input: './src/index.js',
    output: {
      dir: './dist/js',
      format: 'esm'
    },
    plugins
  },
  // Service worker entry point
  {
    input: './src/sw.js',
    output: {
      file: './dist/sw.js',
      format: 'iife'
    },
    plugins: [
      ...plugins,
      // This @rollup/plugin-replace instance replaces process.env.NODE_ENV
      // statements in the Workbox libraries to match your current environment.
      // This changes whether logging is enabled ('development') or disabled ('production').
      replace({
        'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production')
      })
    ]
  }
];

esbouwen

esbuild biedt een eenvoudige opdrachtregelinterface:

npx esbuild ./src/sw.js --bundle --minify --outfile=./dist/sw.js

esbuild zorgt ervoor dat process.env.NODE_ENV standaard wordt vervangen door 'ontwikkeling', of door 'productie' als minificatie is ingeschakeld.

Zonder bundelaar met workbox-sw

Het kan zijn dat uw project niet eens een bundelprogramma gebruikt. workbox-sw kan de Workbox-runtime voor u laden vanaf een CDN binnen uw servicewerker en zonder een build-stap als u deze importeert met importScripts :

// sw.js

// Imports Workbox from the CDN. Note that "6.2.0" of the URL
// is the version of the Workbox runtime.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

const navigationRoute = new workbox.routing.NavigationRoute(new workbox.strategies.NetworkFirst({
  cacheName: 'navigations'
}));

const imageAssetRoute = new workbox.routing.Route(({request}) => {
  return request.destination === 'image';
}, new workbox.strategies.CacheFirst({
  cacheName: 'image-assets'
}));

workbox.routing.registerRoute(navigationRoute);
workbox.routing.registerRoute(staticAssetRoute);

Als het vooruitzicht om de Workbox-runtime van een CDN te laden niet groot lijkt, is het mogelijk om workbox-sw te gebruiken met lokale URL's .

Conclusie

Nu u weet hoe u Workbox kunt gebruiken zonder precaching, bent u niet langer gebonden aan een bepaalde bundel- of buildtool. Dit geeft u de flexibiliteit om een ​​servicemedewerker met de hand te maken met alleen de stukjes van Workbox's runtime cachingcode waarin u geïnteresseerd bent.

,

Tot nu toe was deze documentatie groot op het gebied van precaching, waarbij vaak de build-tools generateSW en injectManifest aan bod kwamen. Hoewel er genoeg goede redenen zijn om precaching-logica in uw service worker op te nemen, hoeft u precaching niet te gebruiken om Workbox te gebruiken.

Misschien heeft uw project alleen runtime-caching nodig, of misschien wilt u een schonere manier om service worker-API's te integreren, zoals web push . Dit zijn gevallen waarin u de buildtools van Workbox niet wilt gebruiken, en dat wordt in dit artikel behandeld.

Bij gebruik van een bundelaar

Bundlers zijn prominent aanwezig in het webontwikkelingslandschap en de kans is groot dat uw project er een gebruikt. Als dit het geval is, is het belangrijk om te weten dat u geen bundelplug-in (zoals workbox-webpack-plugin ) hoeft te gebruiken als u niets vooraf cachet. U behandelt uw servicemedewerker als een afzonderlijk toegangspunt in uw aanvraag.

In de hoofdmap van de bronmap van uw project maakt u een servicemedewerker aan en gebruikt u alle Workbox-modules die uw toepassing nodig heeft. Hier is een voorbeeld zonder precaching, waarmee cachingstrategieën worden ingesteld voor navigatie- en afbeeldingsverzoeken in afzonderlijke Cache instanties:

// sw.js
import {NetworkFirst, CacheFirst} from 'workbox-strategies';
import {registerRoute, NavigationRoute, Route} from 'workbox-routing';

const navigationRoute = new NavigationRoute(new NetworkFirst({
  cacheName: 'navigations'
}));

const imageAssetRoute = new Route(({request}) => {
  return request.destination === 'image';
}, new CacheFirst({
  cacheName: 'image-assets'
}));

registerRoute(navigationRoute);
registerRoute(imageAssetRoute);

Vanaf hier is het een kwestie van deze servicemedewerker opgeven als toegangspunt in de bundelaar van uw keuze. Hieronder vindt u enkele voorbeelden van hoe u dat kunt doen in een aantal populaire bundelaars.

webpakket

webpack accepteert entrypunten in zijn entry . Er zijn een aantal dingen waar u op moet letten als u deze aanpak gebruikt:

  1. Om ervoor te zorgen dat uw servicemedewerker een zo breed mogelijk bereik heeft, wilt u dat deze wordt uitgevoerd naar de hoofdmap van uw uitvoermap.
  2. U wilt niet dat de servicemedewerker een versienummer krijgt, omdat updates ervan nieuwe hashes genereren die ertoe kunnen leiden dat meerdere servicemedewerkers op uw website worden ingezet.

Om aan de bovenstaande voorwaarden te voldoen, kan een functie worden doorgegeven aan output.filename , die onderzoekt of het huidige ingangspunt dat wordt verwerkt, het ingangspunt van de servicemedewerker is. Anders worden versiebestanden naar hun normale bestemmingen geschreven.

// webpack.config.js
import process from 'process';

const isProd = process.env.NODE_ENV === 'production';

export default {
  mode: isProd ? 'production' : 'development',
  context: process.cwd(),
  entry: {
    // Service worker entry point:
    sw: './src/sw.js',
    // Application entry point:
    app: './src/index.js'
  },
  output: {
    filename: ({runtime}) => {
      // Check if the current filename is for the service worker:
      if (runtime === 'sw') {
        // Output a service worker in the root of the dist directory
        // Also, ensure the output file name doesn't have a hash in it
        return '[name].js';
      }

      // Otherwise, output files as normal
      return 'js/[name].[contenthash:8].js';
    },
    path: './dist',
    publicPath: '/',
    clean: true
  }
};

oprollen

Rollup is een vergelijkbare situatie als webpack, behalve dat meerdere toegangspunten worden gespecificeerd als afzonderlijke configuratieobjecten die in een array worden geëxporteerd:

// rollup.config.js
import { nodeResolve } from '@rollup/plugin-node-resolve';
import replace from '@rollup/plugin-replace';

// Plugins common to both entry points
const plugins = [
  nodeResolve(),
];

export default [
  // Application entry point
  {
    input: './src/index.js',
    output: {
      dir: './dist/js',
      format: 'esm'
    },
    plugins
  },
  // Service worker entry point
  {
    input: './src/sw.js',
    output: {
      file: './dist/sw.js',
      format: 'iife'
    },
    plugins: [
      ...plugins,
      // This @rollup/plugin-replace instance replaces process.env.NODE_ENV
      // statements in the Workbox libraries to match your current environment.
      // This changes whether logging is enabled ('development') or disabled ('production').
      replace({
        'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV || 'production')
      })
    ]
  }
];

esbouwen

esbuild biedt een eenvoudige opdrachtregelinterface:

npx esbuild ./src/sw.js --bundle --minify --outfile=./dist/sw.js

esbuild zorgt ervoor dat process.env.NODE_ENV standaard wordt vervangen door 'ontwikkeling', of door 'productie' als minificatie is ingeschakeld.

Zonder bundelaar met workbox-sw

Het kan zijn dat uw project niet eens een bundelprogramma gebruikt. workbox-sw kan de Workbox-runtime voor u laden vanaf een CDN binnen uw servicewerker en zonder een build-stap als u deze importeert met importScripts :

// sw.js

// Imports Workbox from the CDN. Note that "6.2.0" of the URL
// is the version of the Workbox runtime.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

const navigationRoute = new workbox.routing.NavigationRoute(new workbox.strategies.NetworkFirst({
  cacheName: 'navigations'
}));

const imageAssetRoute = new workbox.routing.Route(({request}) => {
  return request.destination === 'image';
}, new workbox.strategies.CacheFirst({
  cacheName: 'image-assets'
}));

workbox.routing.registerRoute(navigationRoute);
workbox.routing.registerRoute(staticAssetRoute);

Als het vooruitzicht om de Workbox-runtime van een CDN te laden niet groot lijkt, is het mogelijk om workbox-sw te gebruiken met lokale URL's .

Conclusie

Nu u weet hoe u Workbox kunt gebruiken zonder precaching, bent u niet langer gebonden aan een bepaalde bundel- of buildtool. Dit geeft u de flexibiliteit om een ​​servicemedewerker met de hand te maken met alleen de stukjes van Workbox's runtime cachingcode waarin u geïnteresseerd bent.