Runtime caches about offline-plugin

[NekR]

Thinking more about it, it won't be possible to implement even runtime pattern matching for main and additional cache section since plugin simply do not know what to cache, i.e. it doesn't what means '/post/*'. To match pattern for assets, we have to do matching agains something, e.g. agains generated assets or URLs requested from page in runtime. Given that, pattern matching at runtime could be implemented only for optional cache section since it's to cache assets only when they were requested.

[NekR]

Hi and thanks, @tomatau

Yes, externals should have pattern matching, do not know why it's not there. I will add. By the way, using externals isn't mandatory, it just prevents warnings from being displayed in console. i.e. if some assets are not listed in externals and are listed in caches then they will be added to output anyway, just with warnings to console.

So you can probably use it as is right now and once I update offline-plugin then warnings will go away.

[tomatau]

Thanks for the reply NekR, I've just been listing them in externals anyway and the warnings are good to help catch assets that aren't being generated when you expect them.

[NekR]

Fixed in 2.1.0. Already on npm. Thanks for reporting this 👍

[NekR]

Oh, I just realized that you wanted pattern matching for externals inside caches section too.
This will require pattern matching at runtime, not done yet and probably will be done only in v3.

[tomatau]

That makes a lot of sense.
Is there no way main and additional can do a pattern match on activate or install based on the current window path?

[NekR]

They need to know what to download. Say you have 10 posts on a server and
use this pattern '/posts/*'. To match and download them, SW has to know
URLs to all posts on server to download them at install/activate time. In
other words, that is impossible.

What you need is a some custom they to handle it. E.g. make a request to
the server, get list of all posts you want to cache/match and then cache
them.

Unfortunately this isn't possible with this plugin, at least yet.
On Apr 3, 2016 11:46 AM, "Thomas" [email protected] wrote:

That makes a lot of sense.
Is there no way main and additional can do a pattern match on activate or
install based on the current window path?

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#26 (comment)

[tomatau]

I understand the need for a URL.

What I'm asking about is when an install / activate occurs, you can check against the current page URL (from window.location) and add the URL the cache if it's a match. The URLs can be added to the cache dynamically during these events. It wouldn't need to know them all on every install/activate -- just update the cache when it finds a match. You would only need the location.pathname.

[NekR]

Oh, I see now. Sounds interesting. Let me think about it a bit 👍

[NekR]

Here is possible API design for it: #117

Can you take a look? Would you be okay with it?