ayo/astro-sw
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore: update readme

Browse source
This commit is contained in:
Ayo Ayco 2024-08-08 21:36:01 +02:00
parent 8d847a5769
commit 3da39e28b4
1 changed files with 1 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -1,14 +1,10 @@
> **>>> TL;DR:** Simple Astro integration to use your own authored service worker; by default, devs retain full control as opposed to getting generated sw code
# Astro SW
[![Package information: NPM version](https://img.shields.io/npm/v/@ayco/astro-sw)](https://www.npmjs.com/package/@ayco/astro-sw)
[![Package information: NPM license](https://img.shields.io/npm/l/@ayco/astro-sw)](https://www.npmjs.com/package/@ayco/astro-sw)
[![Bundle Size](https://img.shields.io/bundlephobia/minzip/@ayco/astro-sw)](#library-size)
The integration accepts service worker path and automatically injects dynamic variables such as `__assets` generated by Astro for caching.
The main philosophy is to [invert the control](https://en.wikipedia.org/wiki/Inversion_of_control) compared to other integrations that generate the service worker for devs. The [service worker](https://web.dev/articles/offline-cookbook) API is such a powerful feature that developers need to be able to make decisions in using it.
The integration accepts path to your own authored [service worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) and automatically injects dynamic variables such as `__assets` generated by Astro for caching. The goal is to [invert the control](https://en.wikipedia.org/wiki/Inversion_of_control) (i.e., compared to generating the service worker script code), and let devs retain the flexibility for various [caching strategies](https://developer.chrome.com/docs/workbox/caching-strategies-overview/).
## Installation