Service workers can pre-populate their cache on install (MDN docs. It would be nice if Radish generated a service worker that pre-cached entire pages and their assets, controlled by the user. One possible API would be something like radish build --offline "/foo" --offline "/bar", where /foo and /bar are paths generated. Radish could look at the esbuild metafile to see which assets corresponded to those pages and cache them all on install.
The obstacle to this is that the content on each page isn't known when bundling — Radish imports all of it and pages can filter it in JavaScript when rendering the component. This is fine for text that gets included in the HTML, but any assets such as images would be missing.
One possible solution is to overload the import in order to make the content known statically. For example, import posts from "content/blog/*"; could import all blog posts and associated assets, which would allow esbuild to associate them with the given entry point. There are a couple issues, though — it's less flexible than getting all content in a big JS object that you can do whatever you want with, and it feels a bit too far removed from normal ES module imports.
Service workers can pre-populate their cache on install (MDN docs. It would be nice if Radish generated a service worker that pre-cached entire pages and their assets, controlled by the user. One possible API would be something like
radish build --offline "/foo" --offline "/bar", where/fooand/barare paths generated. Radish could look at the esbuild metafile to see which assets corresponded to those pages and cache them all on install.The obstacle to this is that the content on each page isn't known when bundling — Radish imports all of it and pages can filter it in JavaScript when rendering the component. This is fine for text that gets included in the HTML, but any assets such as images would be missing.
One possible solution is to overload the import in order to make the content known statically. For example,
import posts from "content/blog/*";could import all blog posts and associated assets, which would allow esbuild to associate them with the given entry point. There are a couple issues, though — it's less flexible than getting all content in a big JS object that you can do whatever you want with, and it feels a bit too far removed from normal ES module imports.