Contexto do fetch no service workers #1070

sbvorpagel · 2018-05-08T16:32:04Z

sbvorpagel
May 8, 2018

Pessoal, fiz alguns testes com service workers, e não entendi muito bem o contexto que o fetch atua. No chrome o código abaixo não funciona, já no firefox sim.
Gostaria de saber se estou fazendo algo errado ou é um bug na implementação do chrome.
A ideia é registrar o service worker na raiz, e disparar um fetch em uma url qualquer apartir da raiz, no exemplo, '/api/users'. Acredito que dessa forma, o onfetch deveria detectar essa tentantiva de GET e interceptar, porém, isso apenas ocorre no firefox.

Clicar no botão para fazer a request

Index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>Service worker</title>
</head>
<body>
    <p>Sou uma pagina!</p>
    <input type="button" onclick="getAll()" value="get"/>
</body>
<script>
    if ('serviceWorker' in navigator) {
        navigator.serviceWorker.register('sw.js')
            .then(() => console.log('Registrado!'))
            .catch((error) => console.error(error));
    }
    const getAll = () => {
        console.log('teste');
        fetch('/api/users', {method: 'GET'}).then(reponse => {
            console.log('Veio uma response');
            return response.json().then(r => {
                return r;
            });
        });
    }
</script>
</html>

sw.js

const users = {
    all: () => {
        return [
            {id: 0, name:  'Samuel'},
        ]
    }
}

const off = ['/'];

this.oninstall = (event) => {
    event.waitUntil(
        caches.open('v1::offline').then((cache) => {
            cache.addAll(off);
        })
    );
}

this.onfetch = (event) => {
    //Se colocar um break aqui,  verá que não para no chrome.
    const request = event.request;
    console.log(users.all());
    if (request.method !== 'GET') {
        event.respondWith(fetch(request)); 
        return;
    }
    event.respondWith(
        fetch(request)
            .then(response => response)
            .catch(() => caches.match(request).then((response) => {
                return response || event.default();
            }))
    )
    return;
};

felipefialho · 2018-05-08T16:54:40Z

felipefialho
May 8, 2018
Maintainer

@willianjusten

0 replies

sbvorpagel · 2018-05-08T17:17:16Z

sbvorpagel
May 8, 2018
Author

@wmartins Essa sua solução foi minha primeira implementação, porém, vi essa outra forma e achei mais elegante. Para o problema, ambas tiveram o mesmo efeito.

0 replies

wmartins · 2018-05-08T18:19:32Z

wmartins
May 8, 2018

@sbvorpagel removi meus comentários anteriores só pra não ficar uma solução incorreta. Estou investigando mais e te dou uma ajuda quando eu conseguir parar para debugar. :)

0 replies

leandroruel · 2018-05-08T19:01:23Z

leandroruel
May 8, 2018

lá no index.html esse trecho aqui tem um erro de digitação no parâmetro "reponse" que deveria ser response

fetch('/api/users', {method: 'GET'}).then(reponse => {
            console.log('Veio uma response');
            return response.json().then(r => {
       return r;
});

0 replies

wmartins · 2018-05-08T19:46:49Z

wmartins
May 8, 2018

@sbvorpagel, acho que descobri o problema. Primeiro, eu fiz o ajuste que o @leandroruel apontou, realmente tem um typo ali.

Segundo, enquanto estava testando, eu percebi que, ao atualizar a página, o evento de fetch passava a ser chamado. Depois de algumas pesquisas, caí na seguinte solução:

Fonte: https://stackoverflow.com/a/42371369
Referência: https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#clientsclaim

Adicionar no sw.js:

this.onactivate = () => {
  this.clients.claim();
}

Talvez tenha alguma coisa a ver com o ciclo de vida dos ServiceWorkers.

Vê se isso resolve o teu problema. É algo "estranho", mas talvez faça um pouco de sentido, olhando a documentação:

Once your service worker is ready to control clients and handle functional events like push and sync,
you'll get an activate event. But that doesn't mean the page that called .register() will be controlled.

The first time you load the demo, even though dog.svg is requested long after the service worker
activates, it doesn't handle the request, and you still see the image of the dog. The default is
consistency, if your page loads without a service worker, neither will its subresources. If you load the
demo a second time (in other words, refresh the page), it'll be controlled. Both the page and the image
will go through fetch events, and you'll see a cat instead.

0 replies

willianjusten · 2018-05-09T01:27:59Z

willianjusten
May 9, 2018
Maintainer

Opa, uma coisa, há alguma razão para usar o this e handlers dessa forma?

Eu tenho um post onde explico a base do service worker e mostro sobre o ciclo de vida.

https://willianjusten.com.br/como-fazer-seu-site-funcionar-offline-com-pwa/#o-que-e-service-worker

Minha dica é usar dessa forma:

this.addEventListener("fetch", event => {})

0 replies

sbvorpagel · 2018-05-09T16:38:17Z

sbvorpagel
May 9, 2018
Author

@willianjusten Vi em um posto do Sergio Lopez dessa forma e achei mais elegante, mas pelo que entendi, funciona da mesma forma.

@wmartins Dessa com esse this.onactivate, deu certo, o motivo, não entendi direito.
Muito obrigado pela ajuda.

@leandroruel Realmente comi uma letra na hora de digitar 😄

0 replies

wmartins · 2018-05-09T18:25:57Z

wmartins
May 9, 2018

@sbvorpagel, também fiquei "encucado" com isso. Pelo que entendi, é necessário ter um evento de navegação para ServiceWorker possa ter controle sobre a página.

TL;DR

By default, a page's fetches won't go through a service worker unless the page request itself went through a service worker. So you'll need to refresh the page to see the effects of the service worker.

clients.claim() can override this default, and take control of non-controlled pages.

Detalhe

https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle?hl=en-us

In brief:

The install event is the first event a service worker gets, and it only happens once.

A promise passed to installEvent.waitUntil() signals the duration and success or failure of your install.

A service worker won't receive events like fetch and push until it successfully finishes installing and becomes "active".

By default, a page's fetches won't go through a service worker unless the page request itself went through a service worker. So you'll need to refresh the page to see the effects of the service worker.

clients.claim() can override this default, and take control of non-controlled pages.

https://googlechrome.github.io/samples/service-worker/immediate-control/

clients.claim(): Causes the activated service worker to take control over all open pages under the scope immediately, rather than taking control only after the next navigation.

https://stackoverflow.com/a/44626554

Service worker takes controls from the next page-reload after its registration. By using self.skipWaiting() and self.clients.claim(), you can ask the client to take control over service worker on the first load itself.the first load itself.

https://github.com/mozilla/serviceworker-cookbook/tree/7537424dc61b404205ef0c385b497933f5c3b2b9/immediate-claim

Basic service worker registration requires a navigation event to occur before the service worker starts working. This recipe illustrates a trick you can use for the service worker to immediately start working upon install.

Espero que isso tenha sanado a dúvida. Eu também não sabia que isso acontecia, bem interessante/estranho.

0 replies

Contexto do fetch no service workers #1070

Uh oh!

Uh oh!

sbvorpagel May 8, 2018

Replies: 8 comments

Uh oh!

felipefialho May 8, 2018 Maintainer

Uh oh!

sbvorpagel May 8, 2018 Author

Uh oh!

wmartins May 8, 2018

Uh oh!

leandroruel May 8, 2018

Uh oh!

wmartins May 8, 2018

Uh oh!

willianjusten May 9, 2018 Maintainer

Uh oh!

Uh oh!

sbvorpagel May 9, 2018 Author

Uh oh!

wmartins May 9, 2018

TL;DR

Detalhe

sbvorpagel
May 8, 2018

felipefialho
May 8, 2018
Maintainer

sbvorpagel
May 8, 2018
Author

wmartins
May 8, 2018

leandroruel
May 8, 2018

wmartins
May 8, 2018

willianjusten
May 9, 2018
Maintainer

sbvorpagel
May 9, 2018
Author

wmartins
May 9, 2018