- From: Jake Archibald <notifications@github.com>
- Date: Tue, 08 Jan 2019 08:59:48 +0000 (UTC)
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1373/452222806@github.com>
@shortercode You probably saw my reply on my blog, but I'll post it here for others: > I feel like not adding an additional Source type that utilises a callback is a missed opportunity I explored that idea, but here's the issue, (spooky music) the callback ceases to exist. It only ever exists when the install event callback is called. Then later, the service worker closes, the callback is gone. Even later, when the service worker is started again, the install event callback isn't called again, so the callback still doesn't exist (and even if we called that callback again, the callback would be a different instance). To overcome this, the callback would need to be somewhere where it'd exist every time the service worker runs, which pretty much means the top level. But how would the service worker be able to tell between two instances of the function (since a new instance is created each time the service worker is booted)? Ideally it'd be associated with something primitive, like a string. This is how events work, so you can see how I arrived at `RouterSourceFetchEvent` as the next best thing. > I think syntax wise I feel it reads better to have static methods on a RouterCondition/RouterSource class that instantiate the specific type I explored this too. What does `RouterCondition.startsWith("/avatars/")` return? Does that type have a constructor? That's how I landed at constructors. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1373#issuecomment-452222806
Received on Tuesday, 8 January 2019 09:00:12 UTC