New post ready 🚀

Author: chicio

_drafts/2019-03-15-github-pages-progressive-web-app.md

@@ -3,7 +3,7 @@ layout: post
 title: "Transform your Github Pages blog into a Progressive Web App"
 description: "In this post I will talk about how I transformed my blog on Github Pages and Jekyll into a PWA."
 date: 2019-03-15
-image: /assets/images/posts/XXXXXXXX
+image: /assets/images/posts/pwa-logo.jpg
 tags: [pwa, web development, javascript],
 comments: true
 seo:
@@ -32,7 +32,7 @@ What does basically means? PWAs are web application that combine the best of the
 
 Soooo I started to think: "Whoah, I can modify my blog/website to become a PWA, so that I can explore this new technology and I can also have something that 'feels like an app' for my blog!!!".  
 So how is it possible to transform a site build with Jekyll and published on Github Pages in a basic PWA? In this post I will show you how I did it (and this article is part of the PWA described here).  
-To create a basic PWA we need 3 things:
+To create a basic PWA I need 3 things:
 
 * publish the site on HTTPS
 * a [web app manifest](https://developers.google.com/web/fundamentals/web-app-manifest/ "web app manifest")
@@ -46,7 +46,7 @@ To have https on my github pages site I had to do...nothing!!!:tada::tada::tada:
 
 #### Web App Manifest
 
-The [web app manifest](https://developers.google.com/web/fundamentals/web-app-manifest/ "web app manifest") is a JSON file that must be deployed in the root of you we application. This JSON is used by user browser about to get some information about your web application and how it should behave when 'installed' on the user's mobile device or desktop. This manifest is required by Chrome to show the Add to Home Screen prompt.
+The [web app manifest](https://developers.google.com/web/fundamentals/web-app-manifest/ "web app manifest") is a JSON file that must be deployed in the root of you web application. This JSON is used by user browser about to get some information about your web application and how it should behave when 'installed' on the user's mobile device or desktop. This manifest is required by Chrome to show the Add to Home Screen prompt.
 
 A typical manifest file includes the following informations:
 
@@ -134,10 +134,102 @@ A service worker is the heart of a Progressive Web App. Let's see the definition
 
 >A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don't need a web page or user interaction. Today, they already include features like push notifications and background sync. In the future, service workers might support other things like periodic sync or geofencing. ... is the ability to intercept and handle network requests, including programmatically managing a cache of responses.
 
-Whoooaaa!!! :open_mouth: Basically service worker let you web app inherit some features that are tipically found only in a native mobile app:
+Whoooaaa!!! :open_mouth: Basically service workers let your web app inherit some features that are tipically found only in a native mobile app:
 
 * push notification
 * offline support
 * background sync
 
-.... (https://developers.google.com/web/fundamentals/primers/service-workers/)
+Anyway, there are some particular features of a service worker you must be aware of in order to fully understand how they works:
+
+* you can't access the DOM directly. In order to be able to manipulate the page content, you need to use the worker [postMessage](https://html.spec.whatwg.org/multipage/workers.html#dom-worker-postmessage "worker post message") api and then manipulate the page change the content if needed (using javascript).
+* service workers are a programmable network proxy, allowing you to control how network requests from your page are handled.
+* service worker don't have a global state, so on each invocation a service worker will not be aware of anything of the previous one (to share data between sessions, you need to use the [IndexedDB API](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API))
+
+So how do I created the service worker for my blog? I started by adding a `sw.js` file to the root of project. This is the standard position for a service worker source code. Then I added the registration script before the end of the body of my pages. Below you can find the registration script.
+
+```javascript
+<script>
+  if('serviceWorker' in navigator) {
+    navigator.serviceWorker
+             .register('/sw.js')
+             .then(function() { console.log("Service Worker Registered"); });
+  } else {
+    console.log('error register service worker')
+  }
+</script>
+```
+
+Then I started to write my service worker. To do that, first I studied the lifecycle of a service worker, composed by the following main events:
+
+* `install`, launched when the service worker will be installed
+* `activate`, launched just after the installation process has been completed correctly.
+* `fetch`, launched on each fetch request executed inside the page
+
+So in the install event I followed the standard approach:
+
+* I opened the cache for my blog pwa with name `chicioCodingCache{% include version.txt %}`, where version.txt is a file that is automatically filled with the latest tag number on each `npm version` execution.
+* I added to the cache the files needed to make my pwa works (css and js of the site, and in the future also a HTML scaffolding structure :stuck_out_tongue_winking_eye:).
+
+In the activate event I added a strategy to manage the old caches: I just delete them and I kept only the new one created during the install phase.
+Then in the fetch event I decided the cache strategy for all the network request made inside my pages. What I chose is basically to return immediately the element if it is present in the cache while at the same time try to update it in the cache. So the next time the user will see the content updated.  
+To manage the fact that not all the browsers implement the entire [Service Worker Cache API](https://w3c.github.io/ServiceWorker/#cache-objects "service worker cache api"), I added a polyfill to manage this inconsistency and imported it with the [WebWorker importScripts() api](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts "webworker import scripts api").  
+One last note: I had to put the frontmatter header inside the service worker source code file to let jekyll understand that the file that contains the service worker must be processed. Jekyll in this way will add:
+
+* the cache version number as explained above (`version.txt` include file)
+* the list of js and css urls to be cached in the install events (I generate this urls lists with a script that extracts them from other Jekyll template files and put them inside `service-worker-home-urls.js`, `service-worker-blog-urls.js` and `service-worker-css-urls.js`)
+
+Below you can find the complete implementation of the service worker.
+
+```javascript
+---
+---
+importScripts('/cache-polyfill.js');
+
+const siteCacheName = 'chicioCodingCache{% include version.txt %}';
+const dependenciesUrls = [
+  "/favicon.ico",
+  {% include service-worker-home-urls.js %}
+  {% include service-worker-blog-urls.js %}
+  {% include service-worker-css-urls.js %}
+]
+
+self.addEventListener('install', (event) => {
+  event.waitUntil(
+    caches.open(siteCacheName).then((cache) => {
+      return cache.addAll(dependenciesUrls);
+    })
+  );
+});
+
+self.addEventListener('activate', (event) => {
+  event.waitUntil(
+    caches.keys().then((cacheNames) => {
+      return Promise.all(
+        cacheNames.filter((cacheName) => {
+          return cacheName !== siteCacheName
+        }).map((cacheName) => {
+          return caches.delete(cacheName);
+        })
+      );
+    })
+  );
+});
+
+self.addEventListener('fetch', (event) => {
+  event.respondWith(
+    caches.open(siteCacheName).then(async (cache) => {
+      return cache.match(event.request).then((response) => {
+        return response || fetch(event.request).then((response) => {
+          cache.put(event.request, response.clone());
+          return response;
+        });
+      });
+    })
+  );
+});
+```
+
+#### Conclusion
+By adding all the above implementation my blog is now a Progrssive Web App (that's right, the article you're reading part of a PWA :smirk:). If you want to see the entire source code of my website/blog discussed here you can have a look at [this repository](https://github.com/chicio/chicio.github.io "chicio coding repository").  
+So now it's time to start to develop you first PWA or transform you website/ web application in PWA. If you want, you could share your experience with me in the comments below :two_hearts:.