@webqit/webflo 0.11.12 → 0.11.15

package/README.md

@@ -20,7 +20,6 @@ Ok, we've put all of that up for a straight read!
 + [Installation](#installation)
 + [Concepts](#concepts)
 + [Webflo Applications](#webflo-applications)
-+ [Workflow API](#workflow-api)
 + [Webflo Config](#webflo-config)
 + [Technology Stack](#technology-stack)
 + [Getting Started](#getting-started)
@@ -124,7 +123,7 @@ This and much more - ahead!
 </details>
 
 <details>
-<summary><b>Build <i>future-proof anything</i></b> by banking more on web standards and less on abstractions! Webflo <i>just follows</i> where a native feature, standard, or conventional HTML, CSS or JS <i>just works</i>!</summary>
+<summary><b>Build <i>future-proof anything</i></b> by banking more on web standards and less on abstractions! Webflo <i>just follows</i> where a native feature, standard, or conventional HTML, CSS or JS <i>already works</i>!</summary>
 
 Here's a glimpse of the standards-based stack you get of Webflo!
  
@@ -195,13 +194,13 @@ Other important definitions like project `name`, package `type`, and *aliases* f
 }
 ```
 
-All is now set! The commands `npm start` and `npm run generate` will be coming in often during development.
+And that gets it all ready! The commands `npm start` and `npm run generate` will be coming in often during development.
 
 ### "Hello World!"
 
 To be sure that Webflo is listening, run `npx webflo help` on the terminal. An overview of available commands should be shown.
 
-If you can't wait to say *Hello World!* 😅, you can have an HTML page say that right now!
+If you can't wait to say *Hello World!* 😅, you can have an HTML page say that right away!
 + Create an `index.html` file in a new subdirectory `public`.
   
   ```shell
@@ -225,7 +224,7 @@ If you can't wait to say *Hello World!* 😅, you can have an HTML page say that
 + Start the Webflo server and visit `http://localhost:3000` on your browser to see your page. 😃
 
   ```bash
-  $ npm start
+  npm start
   ```
 
 ## Concepts
@@ -241,6 +240,8 @@ If you can't wait to say *Hello World!* 😅, you can have an HTML page say that
 
 Whether building a *server-based*, *browser-based*, or *universal* application, Webflo gives you one consistent way to handle routing and navigation: using *handler functions*!
 
+You just define an `index.js` file with a function that gets called to handle a request! No setup!
+
 ```js
 /**
 [server|client|worker]
@@ -250,10 +251,13 @@ export default function(event, context, next) {
 }
 ```
 
-> **Note**
-> <br>Other [*method*](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods)-specific function names may be used: `get`, `post`, `put`, `patch`, `del` (for *delete*), `options`, `head`, etc.
+<details>
+<summary>More details...</summary>
 
-Each function receives an `event` object representing details - e.g. `event.request`, `event.url`, `event.session` - about the current request. ([Details ahead](#workflow-api).)
+> Function name may also be specific to a [*HTTP method*](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods): `get`, `post`, `put`, `patch`, `del` (for *delete*), `options`, `head`, etc.
+</details>
+
+Each function receives an `event` object representing details about the request - e.g. `event.request`, `event.url`, `event.session`. ([Details ahead](#workflow-api).)
 
 For *server-based* applications (e.g. traditional web apps and API backends), server-side handlers go into a directory named `server`.
 
@@ -270,8 +274,11 @@ export default function(event, context, next) {
 }
 ```
 
-> **Note**
-> <br>The above function responds on starting the server - `npm start` on your terminal - and visiting http://localhost:3000.
+<details>
+<summary>How it works...</summary>
+
+> The above function responds on starting the server - `npm start` on your terminal - and visiting http://localhost:3000.
+</details>
 
 For *browser-based* applications (e.g. Single Page Apps), client-side handlers go into a directory named `client`.
 
@@ -288,8 +295,11 @@ export default function(event, context, next) {
 }
 ```
 
-> **Note**
-> <br>The above function is built as part of your application's JS bundle on running the `npm run generate` command. (It is typically bundled to the file `./public/bundle.js`. And the `--auto-embed` flag in that command gets it automatically embedded on your `./public/index.html` page as `<script type="module" src="/bundle.js"></script>`.) Then it responds from right in the browser on visiting http://localhost:3000.
+<details>
+<summary>How it works...</summary>
+
+> The above function is built as part of your application's JS bundle on running the `npm run generate` command. (It is typically bundled to the file `./public/bundle.js`. And the `--auto-embed` flag in that command gets it automatically embedded on your `./public/index.html` page as `<script type="module" src="/bundle.js"></script>`.) Then it responds from right in the browser on visiting http://localhost:3000.
+</details>
 
 For *browser-based* applications that want to support offline usage via Service-Workers (e.g Progressive Web Apps), Webflo allows us to define equivalent handlers for requests hitting the Service Worker. These worker-based handlers go into a directory named `worker`.
 
@@ -306,10 +316,13 @@ export default function(event, context, next) {
 }
 ```
 
-> **Note**
-> <br>The above function is built as part of your application's Service Worker JS bundle on running the `npm run generate` command. (It is typically bundled to the file `./public/worker.js`, and the main application bundle automatically connects to it.) Then it responds from within the Service Worker on visiting http://localhost:3000. (More details [ahead](#service-workers).)
+<details>
+<summary>How it works...</summary>
+
+> The above function is built as part of your application's Service Worker JS bundle on running the `npm run generate` command. (It is typically bundled to the file `./public/worker.js`, and the main application bundle automatically connects to it.) Then it responds from within the Service Worker on visiting http://localhost:3000. (More details [ahead](#service-workers).)
+</details>
 
-So, depending on what's being built, an application's handler functions may take the following form (in part or in whole as with universal applications):
+So, depending on what's being built, an application's handler functions may take the following form (in part or in whole):
 
 ```shell
 client
@@ -344,7 +357,38 @@ server
         └── stickers/index.js ------------------ http://localhost:3000/products/stickers
 ```
 
-Each step calls a `next()` function to forward the current request to the next step (if any), is able to pass a `context` object along, and can *recompose* the return value.
+Each step calls a `next()` function to forward the current request to the next step.
+
+```js
+/**
+server
+ ├── index.js
+ */
+export default async function(event, context, next) {
+    if (next.stepname) {
+        return next();
+    }
+    return { title: 'Home | FluffyPets' };
+}
+```
+
+```js
+/**
+server
+ ├── products/index.js
+ */
+export default function(event, context, next) {
+    if (next.stepname) {
+        return next();
+    }
+    return { title: 'Products' };
+}
+```
+
+<details>
+<summary>More details...</summary>
+
+Each step can pass a `context` object to a child step, and can *recompose* its return value.
 
 ```js
 /**
@@ -361,18 +405,55 @@ export default async function(event, context, next) {
 }
 ```
 
+<details>
+<summary>Even more details...</summary>
+
+The `next()` function can be used to re-direct the current request to a different route - using a relative or absolute URL.
+
+```js
+/**
+server
+ ├── index.js
+ */
+export default async function(event, context, next) {
+    if (next.stepname === 'products') {
+        return next( context, '/api/products?params=allowed' ); // With an absolute URL
+    }
+    return { title: 'Home | FluffyPets' };
+}
+```
+
 ```js
 /**
 server
  ├── products/index.js
  */
-export default function(event, context, next) {
+export default async function(event, context, next) {
     if (next.stepname) {
         return next();
     }
-    return { title: 'Products' };
+    return next( context, '../api/products?params=allowed' ); // With a relative URL
+}
+```
+
+The `next()` function can also run as an independent request - using [the same parameters as with the WHATWG Request constructor](https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#parameters).
+
+```js
+/**
+server
+ ├── index.js
+ */
+export default async function(event, context, next) {
+    if (next.stepname === 'products') {
+        return next( context, '/api/products?params=allowed', {
+            method: 'get', { headers: { Authorization: 'djjdd' } } 
+        });
+    }
+    return { title: 'Home | FluffyPets' };
 }
 ```
+</details>
+</details>
 
 This step-based workflow helps to decomplicate routing and gets us scaling horizontally as our application grows larger.
 
@@ -394,6 +475,12 @@ export default function(event, context, next) {
 }
 ```
 
+<details>
+<summary>More details...</summary>
+
+> Every handler function has a `this.stepname` and `this.pathname` property. Server-side handlers have an extra `this.dirname` property.
+</details>
+
 Additionally, workflows may be designed with as many or as few step functions as necessary; the flow control parameters `next.stepname` and `next.pathname` can be used at any point to handle the rest of an URL that have no corresponding step functions.
 
 For example, it is possible to handle all URLs from the root handler alone.
@@ -469,7 +556,7 @@ export default async function(event, context, next) {
 }
 ```
 
-Now we get the following layout-to-URL mapping for our application:
+Now we get the following handler-to-URL mapping for our application:
 
 ```shell
 my-app
@@ -504,7 +591,7 @@ export default async function(event, context, next) {
 }
 ```
 
-Our overall layout-to-URL mapping for this application now becomes:
+Our overall handler-to-URL mapping for this application now becomes:
 
 ```shell
 my-app
@@ -560,18 +647,27 @@ my-app
 
 But, we can also access the route in a way that gets the data rendered into the automatically-paired `index.html` file for a dynamic page response. We'd simply set the [`Accept`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept) header of the request to match `text/html` - e.g. `text/html`, `text/*`, `*/html`, `*/*`, and Webflo will automatically perform [Server-Side Rendering](#client-and-server-side-rendering) to give a page response. (Automatic pairing works the same for nested routes! But top-level `index.html` files are implicitly inherited down the hierarchy.)
 
-> **Note**
-> <br>The `Accept` header hint is already how browsers make requests on every page load. So, it just works!
+<details>
+<summary>How it works...</summary>
+
+> The `Accept` header hint is already how browsers make requests on every page load. So, it just works!
+</details>
 
 Now, for Single Page Applications, subsequent navigations, after the initial page load, just ask for the data on destination URLs and perform [Client-Side Rendering](#client-and-server-side-rendering) on the same running document. Navigation is sleek and instant!
 
-> **Note**
-> <br>Unless disabled, [SPA Routing](#spa-routing) is automatically built into your app's JS bundle from the `npm run generate` command. So, it just works!
+<details>
+<summary>How it works...</summary>
+
+> Unless disabled, [SPA Routing](#spa-routing) is automatically built into your app's JS bundle from the `npm run generate` command. So, it just works!
+</details>
 
 With no extra work, your application can function as either a *Multi Page App (MPA)* or a *Single Page App (SPA)*!
 
-> **Note**
-> <br>In a Single Page Application, all pages are based off a single `index.html` document. In a Multi Page Application, pages are individual `index.html`  documents - ideally. But, Server-Side Rendering makes it possible to serve the same, but dynamically-rendered, `index.html` document across page loads - essentially an SPA architecture hiding on the server. But, here, lets take Multi Page Applications for an individual-page architecture.
+<details>
+<summary>Some disambiguation...</summary>
+
+> In a Single Page Application, all pages are based off a single `index.html` document. In a Multi Page Application, pages are individual `index.html`  documents - ideally. But, Server-Side Rendering makes it possible to serve the same, but dynamically-rendered, `index.html` document across page loads - essentially an SPA architecture hiding on the server. But, here, lets take Multi Page Applications for an individual-page architecture.
+</details>
 
 #### Layout and Templating Overview
 
@@ -587,7 +683,7 @@ my-app
       └── footer.html ------------------------------ <footer></footer> <!-- To appear at bottom of each index.html page -->
 ```
 
-In a Single Page Application, each page is the same `index.html` document, and it is often necessary to have the main page sections change on each route. These sections can be defined per-route and *imported* to the document on navigating to their respective URLs.
+In a Single Page Application, each page is the same `index.html` document, and it is often necessary to have the main page sections change on each route. These sections can be defined per-route and *imported* to the document on navigating to their respective route.
 
 ```html
 my-app
@@ -600,7 +696,7 @@ my-app
 
 This, in both cases, is templating - the ability to define HTML *partials* once, and have them reused multiple times. Webflo just concerns itself with templating, and the choice of a Multi Page Application or Single Page Application becomes yours! And heck, you can even have the best of both worlds in the same application - with an architecture we'll call [Multi SPA](#in-a-multi-spa-layout)! It's all a *layout* thing!
 
-Now, with pages in Webflo being [DOM-based](#overview) (both client-side and [server-side](#oohtml-ssr)), documents can be manipulated directly with DOM APIs, e.g. to replace or insert nodes, attributes, etc. But even better, templating in Webflo is based on the [HTML Modules](https://github.com/webqit/oohtml#html-modules) and [HTML Imports](https://github.com/webqit/oohtml#html-imports) features in [OOHTML](#oohtml) - unless disabled in config. These features provide a powerful declarative templating system on top of the standard [HTML `<template>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template) element - with a *module*, *export* and *import* paradigm.
+Now, with pages in Webflo being [DOM-based](#overview) (both client-side and [server-side](#oohtml-ssr)), documents can be manipulated directly with DOM APIs, e.g. to replace or insert nodes, attributes, etc. But even better, templating in Webflo is based on the [HTML Modules](https://github.com/webqit/oohtml#html-modules) and [HTML Imports](https://github.com/webqit/oohtml#html-imports) features in [OOHTML](#oohtml) - unless disabled in config. These features provide a powerful declarative templating system on top of the standard [HTML `<template>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template) element - all in a *module*, *export* and *import* paradigm.
 
 Here, you are able to define reusable contents in a `<template>` element...
 
@@ -622,7 +718,7 @@ Here, you are able to define reusable contents in a `<template>` element...
 </body>
 ```
 
-The *module* element - `<template name>` - is able to load its contents from a remote `.html` file that serves as a bundle:
+The *module* element - `<template>` - is able to load its contents from a remote `.html` file that serves as a bundle:
 
 ```html
 <!--
@@ -634,6 +730,10 @@ public
 ```
 
 ```html
+<!--
+public
+ ├── index.html
+-->
 <head>
     <template name="routes" src="/bundle.html"></template>
 </head>
@@ -643,7 +743,7 @@ What [we'll see shortly](#bundling) is how multiple standalone `.html` files - e
 
 #### In a Multi Page Layout
 
-In a Multi Page layout (as [above](#layout-and-templating-overview)), generic contents - e.g. header and footer sections, etc. - are typically bundled into one `bundle.html` file that can be embedded on each page of the application.
+In a Multi Page layout (as seen [earlier](#layout-and-templating-overview)), generic contents - e.g. header and footer sections, etc. - are typically bundled into one `bundle.html` file that can be embedded on each page of the application.
 
 ```html
 <!--
@@ -702,12 +802,15 @@ public/products
 </html>
 ```
 
-> **Note**
-> <br>In this architecture, navigation is traditional - a new page loads each time. The `bundle.js` script comes with the appropriate OOHTML support level required for the imports to function.
+<details>
+<summary>How it works...</summary>
+
+> In this architecture, navigation is traditional - a new page loads each time. The `bundle.js` script comes with the appropriate OOHTML support level required for the imports to function.
+</details>
 
 #### In a Single Page Layout
 
-In a Single Page layout (as seen [earlier](#layout-and-templating-overview)), page-specific contents - e.g. main sections - are typically bundled together into one `bundle.html` file that can be embedded on the document root. Nested routes end up as nested `<template>` elements that form the equivalent of thw application's URL structure.
+In a Single Page layout (as seen [earlier](#layout-and-templating-overview)), page-specific contents - e.g. main sections - are typically bundled together into one `bundle.html` file that can be embedded on the document root. Nested routes end up as nested `<template>` elements that form the equivalent of the application's URL structure.
 
 ```html
 <!--
@@ -723,7 +826,7 @@ public
 <main exportgroup="main.html">Welcome to our Home Page</main>
 ```
 
-Now, the `<main>` elements are each imported on navigating to their respective URLs. This time, Webflo takes care of setting the URL path as a global `template` attribute on the `<body>` element such that `<import>` elements that inherit this global attribute are resolved from its current value.
+Now, the `<main>` elements are each imported on navigating to their respective routes. This time, Webflo takes care of setting the URL path as a global `template` attribute on the `<body>` element such that `<import>` elements that inherit this global attribute are resolved from its current value.
 
 ```html
 <!--
@@ -744,8 +847,11 @@ public
 </html>
 ```
 
-> **Note**
-> <br>In this architecture, navigation is instant and sleek - Webflo prevents a full page reload, obtains and sets data at `document.state.data` for the new URL, then sets the `template` attribute on the `<body>` element to the new URL path. The `bundle.js` script comes with the appropriate OOHTML support level required for the imports to function.
+<details>
+<summary>How it works...</summary>
+
+> In this architecture, navigation is instant and sleek - Webflo prevents a full page reload, obtains and sets data at `document.state.data` for the new URL, then sets the `template` attribute on the `<body>` element to the new URL path. The `bundle.js` script comes with the appropriate OOHTML support level required for the imports to function.
+</details>
 
 #### In a Multi SPA Layout
 
@@ -765,7 +871,11 @@ my-app
       └── footer.html ------------------------------ <footer></footer> <!-- To appear at bottom of each document root -->
 ```
 
-The above gives us three document roots: `/index.html`, `/about/index.html`, `/prodcuts/index.html`. The `/prodcuts` route doubles as a Single Page Application such that visiting the `/prodcuts` route loads the document root `/prodcuts/index.html` and lets Webflo SPA routing determine which of `/prodcuts/main.html`, `/prodcuts/free/main.html`, `/prodcuts/paid/main.html` is imported on a given URL.
+<details>
+<summary>How it works...</summary>
+
+> The above gives us three document roots: `/index.html`, `/about/index.html`, `/prodcuts/index.html`. The `/prodcuts` route doubles as a Single Page Application such that visiting the `/prodcuts` route loads the document root `/prodcuts/index.html` and lets Webflo SPA routing determine which of `/prodcuts/main.html`, `/prodcuts/free/main.html`, `/prodcuts/paid/main.html` is imported on a given URL.
+</details>
 
 Webflo ensures that only the amount of JavaScript for a document root is actually loaded! So, above, a common JavaScript build is shared across the three document roots alongside an often tiny root-specific build.
 
@@ -777,7 +887,7 @@ public
 <!DOCTYPE html>
 <html>
     <head>
-        <script type="module" src="webflo.bundle.js"></script>
+        <script type="module" src="/webflo.bundle.js"></script>
         <script type="module" src="/products/bundle.js"></script>
         <template name="pages" src="/bundle.html"></template>
     </head>
@@ -793,7 +903,7 @@ public
 <!DOCTYPE html>
 <html>
     <head>
-        <script type="module" src="webflo.bundle.js"></script>
+        <script type="module" src="/webflo.bundle.js"></script>
         <script type="module" src="/about/bundle.js"></script>
         <template name="pages" src="/bundle.html"></template>
     </head>
@@ -809,7 +919,7 @@ public
 <!DOCTYPE html>
 <html>
     <head>
-        <script type="module" src="webflo.bundle.js"></script>
+        <script type="module" src="/webflo.bundle.js"></script>
         <script type="module" src="/bundle.js"></script>
         <template name="pages" src="/bundle.html"></template>
     </head>
@@ -908,8 +1018,11 @@ However, since the `document` objects in Webflo natively support [OOHTML](#oohtm
  </html>
 ```
 
-> **Note**
-> <br>Now, this comes logical since logic is the whole essence of the HTML `<script>` element, after all! Compared to other syntax alternatives, this uniquely enables us to do all things logic in the actual language for logic - JavaScript. Then, OOHTML gives us more by extending the regular `<script>` element with the `subscript` type which gets any JavaScript code to be *reactive*!
+<details>
+<summary>Re-introducing logic in the actual language for logic - JavaScript...</summary>
+
+> Now, this comes logical being that logic is the whole essence of the HTML `<script>` element after all! Compared to other syntax alternatives, this uniquely enables us to do all things logic in the actual language for logic - JavaScript. Then, OOHTML gives us more by extending the regular `<script>` element with the `subscript` type which gets any JavaScript code to be *reactive*!
+</details>
 
 Note that because these scripts are naturally reactive, we do not require any `setTimeout()` construct like we required earlier in the case of the classic `<script>` element. These expressions self-update as the values they depend on become available, removed, or updated - i.e. as `document.state` gets updated.
 
@@ -1064,15 +1177,22 @@ Observer.observe(state, propertyName, change => {
 
 This way, all the moving parts of your application remain coordinated, and can easily be rendered to reflect them on the UI!
 
-For all things application state, Webflo leverages the [State API](https://github.com/webqit/oohtml#state-api) that's natively available in OOHTML-based documents - both client-side and server-side. This API exposes an application-wide `document.state` object and a per-element `element.state` object. And these are *live* read/write objects that can be observed for property changes using the [Observer API](#the-observer-api). It comes off as the simplest approach to state and reactivity!
+Now, for all things application state, Webflo leverages the [State API](https://github.com/webqit/oohtml#state-api) that's natively available in OOHTML-based documents - both client-side and server-side. This API exposes an application-wide `document.state` object and a per-element `element.state` object. And these are *live* read/write objects that can be observed for property changes using the [Observer API](#the-observer-api). It comes off as the simplest approach to state and reactivity!
 
 > **Note**
-> <br>The State API is not available when the [OOHTML support level](#oohtml) in config is switched away from `full` and `scripting`.
+> <br>The State API is available as long as the [OOHTML support level](#oohtml) in config is left as `full`, or set to `scripting`.
 
 #### The `document.state.data` Object
 
 This property reperesents the application data at any point in time - obtained from route handers on each navigation. Webflo simply updates this property and lets the page's [rendering logic](#client-and-server-side-rendering), or other parts of the application, take over.
 
+```js
+console.log(document.state.data) // { title: 'Home | FluffyPets' }
+```
+
+<details>
+<summary>More examples...</summary>
+
 ```js
 Observer.observe(document.state, 'data', e => {
     console.log('Current page data is: ', e.value);
@@ -1085,6 +1205,7 @@ Observer.observe(document.state, 'data', e => {
  document.title = title;
 </script>
 ```
+</details>
 
 #### The `document.state.url` Object
 
@@ -1094,6 +1215,9 @@ This is a *live* object that reperesents the properties of the application URL a
 console.log(document.state.url) // { hash, host, hostname, href, origin, password, pathname, port, protocol, search, searchParams, username }
 ```
 
+<details>
+<summary>More examples...</summary>
+
 ```js
 Observer.observe(document.state.url, 'hash', e => {
     console.log(document.state.url.hash === e.value); // true
@@ -1132,6 +1256,7 @@ document.addEventListener('synthetic-navigation', e => {
  document.title = 'Login as ' + role;
 </script>
 ```
+</details>
 
 ### Requests and Responses
 
@@ -1199,6 +1324,9 @@ Where workflows throw an exception, an *error* status is implied.
 
 Handlers can set [response cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie) via the standard `Response` constructor, or using the standard `Headers.set()` method.
 
+<details>
+<summary>Examples...</summary>
+
 ```js
 let response = event.Response(data, { headers: { 'Set-Cookie': cookieString }});
 
@@ -1220,19 +1348,20 @@ response.headers.cookies = { 'Cookie-1': cookieObject };
 response.headers.cookies = { 'Cookie-2': cookie2Object };
 
 console.log(response.headers.cookies); // { 'Cookie-1': cookieObject, 'Cookie-2': cookie2Object };
-````
+```
 
 Set cookies are [accessed](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cookie) on the next request via request headers.
 
 ```js
 console.log(event.request.headers.get('Cookie')); // Cookie-1=cookie-val&Cookie-2=cookie2-val;
-````
+```
 
 Webflo also offers a *convenience* method.
 
 ```js
 console.log(event.request.headers.cookies); // { 'Cookie-1': 'cookie-val', 'Cookie-2': 'cookie2-val' };
 ```
+</details>
 
 ### Webflo Applications
 
@@ -1251,11 +1380,18 @@ On being loaded, the state of the application is initialized, or is restored thr
 
 ##### SPA Navigation
 
-Unless disabled in config, it is factored-in at build time for the application client JS to be able to automatially figure out when to intercept a navigation event and prevent a full page reload, and when not to. It follows the following rules:
+Unless disabled in config, it is factored-in at build time for the application client JS to be able to automatially figure out when to intercept a navigation event and prevent a full page reload, and when not to.
+
+<details>
+<summary>How it works...</summary>
+
+SPA Navigation follows the following rules:
+
 + When it ascertains that the destination URL is based on the current running `index.html` document in the browser (an SPA architecture), a full page reload is prevented for *soft* navigation. But where the destination URL points out of the current document root (a [Multi SPA](#in-a-multi-spa-layout) architecture), navigation is allowed as a normal page load, and a new page root is loaded.
 + If navigation is initiated with any of the following keys pressed: Meta Key, Alt Key, Shift Key, Ctrl Key, navigation is allowed to work the default way - regardless of the first rule above.
 + If navigation is initiated from a link element that has the `target` attribute, or the `download` attribute, navigation is allowed to work the default way - regardless of the first rule above.
 + If navigation is initiated from a form element that has the `target` attribute, navigation is allowed to work the default way - regardless of the first rule above.
+</details>
 
 <details>
 <summary>Config (Default)</summary>
@@ -1264,7 +1400,9 @@ Unless disabled in config, it is factored-in at build time for the application c
 { "spa_navigation": true }
 ```
 
-> File: `.webqit/webflo/client.json` | Command: `webflo config client spa_navigation=TRUE`
+> **File: `.webqit/webflo/client.json`**
+
+> **Command: `webflo config client spa_navigation=TRUE`**
 </details>
 
 ##### SPA State
@@ -1279,75 +1417,98 @@ This is a *live* object that exposes the network activity and network state of t
 console.log(document.state.network) // { requesting, remote, error, redirecting, connectivity, }
 ```
 
-+ **`network.requesting`: `null|Object`** - This property tells when a request is ongoing, in which case it exposes the `params` object used to initiate the request.
-  
-  On the UI, this could be used to hide a menu drawer that may have been open.
-  
-  ```html
-  <menu-drawer>
-      <script type="subscript">
-      let { network: { requesting } } = document.state;
-      if (requesting) {
-          $(this).attr('open', false);
-      }
-      </script>
-  </menu-drawer>
-  ```
-  
-+ **`network.remote`: `null|String`** - This property tells when a remote request is ongoing - usually the same navigation requests as at `network.requesting`, but when not handled by any client-side route handlers, or when `next()`ed to this point by route handlers. The `remote` property also goes live when a route handler calls the special `fetch()` function that they recieve on their fourth parameter.
-  
-  On the UI, this could be used to show/hide a spinner, or progress bar, to provide a visual cue.
-  
-  ```html
-  <progress-bar>
-      <script type="subscript">
-      let { network: { remote } } = document.state;
-      $(this).attr('hidden', !remote);
-      </script>
-  </progress-bar>
-  ```
-  
-+ **`network.error`: `null|Error`** - This property tells when a request is *errored* in which case it contains an `Error` instance of the error. For requests that can be retried, the `Error` instance also has a custom `retry()` method.
-  
-  On the UI, this could be used to show/hide cute error elements.
-  
-  ```html
-  <nice-error>
-      <script type="subscript">
-      let { network: { error } } = document.state;
-      $(this).attr('hidden', !error);
-      </script>
-  </nice-error>
-  ```
-  
-+ **`network.redirecting`: `null|String`** - This property tells when a client-side redirect is ongoing - see [Scenario 4: Single Page Navigation Requests and Responses](#scenario-4-single-page-navigation-requests-and-responses) - in which case it exposes the destination URL.
-  
-  On the UI, this could be used to prevent further interactions with the outgoing page.
-  
-  ```html
-  <body>
-      <script type="subscript">
-      let { network: { redirecting } } = document.state;
-      $(this).css(redirecting ? { pointerEvents: 'none', filter: 'blur(2)' } : { pointerEvents: 'auto', filter: 'blur(0)' });
-      </script>
-  </body>
-  ```
-  
-+ **`network.connectivity`: `String`** - This property tells of [the browser's ability to connect to the network](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine): `online`, `offline`.
-  
-  On the UI, this could be used to show/hide a connectivity status.
-  
-  ```html
-  <body>
-      <script type="subscript">
-      let { network: { connectivity } } = document.state;
-      $(this).attr( 'connectivity', connectivity });
-      </script>
-  </body>
-  ```
+<details>
+<summary>Property: <code>.network.requesting: null|Object</code></summary>
+
+This property tells when a request is ongoing, in which case it exposes the `params` object used to initiate the request.
+
+On the UI, this could be used to hide a menu drawer that may have been open.
+
+```html
+<menu-drawer>
+    <script type="subscript">
+    let { network: { requesting } } = document.state;
+    if (requesting) {
+        $(this).attr('open', false);
+    }
+    </script>
+</menu-drawer>
+```
+</details>
+
+<details>
+<summary>Property: <code>.network.remote: null|String</code></summary>
+
+ This property tells when a remote request is ongoing - usually the same navigation requests as at `network.requesting`, but when not handled by any client-side route handlers, or when `next()`ed to this point by route handlers. The `remote` property also goes live when a route handler calls the special `fetch()` function that they recieve on their fourth parameter.
+
+On the UI, this could be used to show/hide a spinner, or progress bar, to provide a visual cue.
+
+```html
+<progress-bar>
+    <script type="subscript">
+    let { network: { remote } } = document.state;
+    $(this).attr('hidden', !remote);
+    </script>
+</progress-bar>
+```
+</details>
+
+<details>
+<summary>Property: <code>.network.error: null|Error</code></summary>
+
+This property tells when a request is *errored* in which case it contains an `Error` instance of the error. For requests that can be retried, the `Error` instance also has a custom `retry()` method.
+
+On the UI, this could be used to show/hide cute error elements.
+
+```html
+<nice-error>
+    <script type="subscript">
+    let { network: { error } } = document.state;
+    $(this).attr('hidden', !error);
+    </script>
+</nice-error>
+```
+</details>
+
+<details>
+<summary>Property: <code>.network.redirecting: null|String</code></summary>
+
+This property tells when a client-side redirect is ongoing - see [Scenario 4: Single Page Navigation Requests and Responses](#scenario-4-single-page-navigation-requests-and-responses) - in which case it exposes the destination URL.
+
+On the UI, this could be used to prevent further interactions with the outgoing page.
+
+```html
+<body>
+    <script type="subscript">
+    let { network: { redirecting } } = document.state;
+    $(this).css(redirecting ? { pointerEvents: 'none', filter: 'blur(2)' } : { pointerEvents: 'auto', filter: 'blur(0)' });
+    </script>
+</body>
+```
+</details>
+
+<details>
+<summary>Property: <code>.network.connectivity: String</code></summary>
+
+This property tells of [the browser's ability to connect to the network](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine): `online`, `offline`.
+
+On the UI, this could be used to show/hide a connectivity status.
+
+```html
+<body>
+    <script type="subscript">
+    let { network: { connectivity } } = document.state;
+    $(this).attr( 'connectivity', connectivity });
+    </script>
+</body>
+```
+</details>
   
 Here are some additional examples with the [Observer API](#the-observer-api).
 
+<details>
+<summary>Visualize the network state...</summary>
+
 ```js
 // Visualize the network state
 let onlineVisualizer = changes => {
@@ -1358,6 +1519,10 @@ let onlineVisualizer = changes => {
 Observer.observe(document.state.network, onlineVisualizer);
 // Or: Observer.observe(document, [ ['state', 'network'] ], onlineVisualizer, { subtree: true });
 ```
+</details>
+
+<details>
+<summary>Visualize "connectivity"...</summary>
 
 ```js
 // Visualize the 'connectivity' property
@@ -1367,6 +1532,10 @@ let connectivityVisualizer = e => {
 Observer.observe(document.state.network, 'connectivity', connectivityVisualizer);
 // Or: Observer.observe(document.state, [ ['network', 'connectivity'] ], connectivityeVisualizer);
 ```
+</details>
+
+<details>
+<summary>Catch request errors; attempt a retry...</summary>
 
 ```js
 // Catch request errors; attempt a retry
@@ -1379,6 +1548,7 @@ Observer.observe(document.state.network, 'error', e => {
     }
 });
 ```
+</details>
 
 ##### Form Actions
 
@@ -1412,216 +1582,298 @@ Webflo client-side applications are intended to provide an app-like-first experi
 { "service_worker_support": true }
 ```
 
-> File: `.webqit/webflo/client.json` | Command: `webflo config client service_worker_support=TRUE`
+> **File: `.webqit/webflo/client.json`**
+
+> **Command: `webflo config client service_worker_support=TRUE`**
 </details>
 
 ##### Fetching Strategy
 
-+ **Network First** - This strategy tells the Service Worker to always attempt fetching from the network first for given resources, before fetching from the cache. On every successful network fetch, a copy of the response is saved to the cache for next time. (This is good for resources that need to be fresh to the user on a "best effort" basis.) Unless changed, this is Webflo's default fetching strategy. When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
-    
-    <details>
-    <summary>Config (Default)</summary>
+<details>
+<summary>Network First</summary>
+
+This strategy tells the Service Worker to always attempt fetching from the network first for given resources, before fetching from the cache. On every successful network fetch, a copy of the response is saved to the cache for next time. (This is good for resources that need to be fresh to the user on a "best effort" basis.) Unless changed, this is Webflo's default fetching strategy. When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
+
+<details>
+<summary>Config (Default)</summary>
 
-    ```json
-    { "default_fetching_strategy": "network-first" }
-    ```
+```json
+{ "default_fetching_strategy": "network-first" }
+```
 
-    *To list specific URLs...*
+*To list specific URLs...*
 
-    ```json
-    { "network_first_urls": [ "/logo.png" ] }
-    ```
+```json
+{ "network_first_urls": [ "/logo.png" ] }
+```
 
-    > File: `.webqit/webflo/worker.json` | Command: `webflo config worker default_fetching_strategy=network-first`
-    </details>
+> **File: `.webqit/webflo/worker.json`**
 
-+ **Cache First** - This strategy tells the Service Worker to always attempt fetching from the cache first for given resources, before fetching from the network. After serving a cached response, or where not found in cache, a network fetch happens and a copy of the response is saved to the cache for next time. (This is good for resources that do not critially need to be fresh to the user.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
-    
-    <details>
-    <summary>Config (Alternative)</summary>
+> **Command: `webflo config worker default_fetching_strategy=network-first`**
+</details>
+</details>
 
-    ```json
-    { "default_fetching_strategy": "cache-first" }
-    ```
+<details>
+<summary>Cache First</summary>
 
-    *To list specific URLs...*
+This strategy tells the Service Worker to always attempt fetching from the cache first for given resources, before fetching from the network. After serving a cached response, or where not found in cache, a network fetch happens and a copy of the response is saved to the cache for next time. (This is good for resources that do not critially need to be fresh to the user.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
 
-    ```json
-    { "cache_first_urls": [ "/logo.png" ] }
-    ```
+<details>
+<summary>Config</summary>
 
-    > File: `.webqit/webflo/worker.json` | Command: `webflo config worker default_fetching_strategy=cache-first`
-    </details>
+```json
+{ "default_fetching_strategy": "cache-first" }
+```
 
-+ **Network Only** - This strategy tells the Service Worker to always fetch given resources from the network only. They are simply not available when offline. (This is good for resources that critially need to be fresh to the user.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
-    
-    <details>
-    <summary>Config (Alternative)</summary>
+*To list specific URLs...*
 
-    ```json
-    { "default_fetching_strategy": "network-only" }
-    ```
+```json
+{ "cache_first_urls": [ "/logo.png" ] }
+```
+
+> **File: `.webqit/webflo/worker.json`**
+
+> **Command: `webflo config worker default_fetching_strategy=cache-first`**
+</details>
+</details>
+
+<details>
+<summary>Network Only</summary>
+
+This strategy tells the Service Worker to always fetch given resources from the network only. They are simply not available when offline. (This is good for resources that critially need to be fresh to the user.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured.
+
+<details>
+<summary>Config</summary>
+
+```json
+{ "default_fetching_strategy": "network-only" }
+```
 
-    *To list specific URLs...*
+*To list specific URLs...*
 
-    ```json
-    { "network_only_urls": [ "/logo.png" ] }
-    ```
+```json
+{ "network_only_urls": [ "/logo.png" ] }
+```
 
-    > File: `.webqit/webflo/worker.json` | Command: `webflo config worker default_fetching_strategy=network-only`
-    </details>
+> **File: `.webqit/webflo/worker.json`**
 
-+ **Cache Only** - This strategy tells the Service Worker to always fetch given resources from the cache only. (This is good for resources that do not change often.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured. The listed resources are pre-cached ahead of when they'll be needed - and are served from the cache each time. (Pre-caching happens on the one-time `install` event of the Service Worker.)
+> **Command: `webflo config worker default_fetching_strategy=network-only`**
+</details>
+</details>
+
+<details>
+<summary>Cache Only</summary>
+
+This strategy tells the Service Worker to always fetch given resources from the cache only. (This is good for resources that do not change often.) When not the default strategy, a list of specific URLs that should be fetched this way can be configured. The listed resources are pre-cached ahead of when they'll be needed - and are served from the cache each time. (Pre-caching happens on the one-time `install` event of the Service Worker.)
+
+<details>
+<summary>Config</summary>
+
+```json
+{ "default_fetching_strategy": "cache-only" }
+```
 
-    <details>
-    <summary>Config (Alternative)</summary>
+*To list specific URLs...*
 
-    ```json
-    { "default_fetching_strategy": "cache-only" }
-    ```
+```json
+{ "cache_only_urls": [ "/logo.png" ] }
+```
 
-    *To list specific URLs...*
+> **File: `.webqit/webflo/worker.json`**
 
-    ```json
-    { "cache_only_urls": [ "/logo.png" ] }
-    ```
+> **Command: `webflo config worker default_fetching_strategy=cache-only`**
+</details>
+</details>
 
-    > File: `.webqit/webflo/worker.json` | Command: `webflo config worker default_fetching_strategy=cache-only`
-    </details>
+In all cases above, the convention for specifying URLs for a strategy accepts an [URL patterns](https://developer.mozilla.org/en-US/docs/Web/API/URLPattern) - against which URLs can be matched on the fly. For example, to place all files in an `/image` directory (and subdirectories) on the *Cache First* strategy, the pattern `/image/*` can be used. To place all `.svg` files in an `/icons` directory (including subdirectories) on the *Cache Only* strategy, the pattern `/icons/*.svg` can be used. (Specifically for the *Cache Only* strategy, patterns are resolved at Service Worker build-time, and each pattern must match, at least, a file.)
 
-In all cases above, the convention for specifying URLs for a strategy accepts [URL patterns](https://developer.mozilla.org/en-US/docs/Web/API/URLPattern) - against which URLs can be matched on the fly. For example, to place all files in an `/image` directory (and subdirectories) on the *Cache First* strategy, the pattern `/image/*` can be used. To place all `.svg` files in an `/icons` directory (including subdirectories) on the *Cache Only* strategy, the pattern `/icons/*.svg` can be used. (Specifically for the *Cache Only* strategy, patterns are resolved at Service Worker build-time, and each pattern must match, at least, a file.)
+<details>
+<summary>Example...</summary>
 
 ```json
 { "cache_only_urls": [ "/icons/*.svg" ] }
 ```
+</details>
 
 ##### Cross-Thread Communications
 
 A couple APIs exists in browsers for establishing a two-way communication channel between a page and its Service Worker, for firing UI Notifications from either ends, and for implementing Push Notifications. Webflo offers to simply this with a unifying set of conventions:
 
-+ The `workport` API - an object with simple methods for working with *cross-thread* messages, UI and Push Notifications.
-  
-  On both the client and worker side of your application, the `workport` object is accessible from route handlers as `this.runtime.workport`.
-  
-  ```js
-  /**
-  [client|worker]
-   ├── index.js
-   */
-  export default async function(event, context, next) {
-      let { workport } = this.runtime;
-      workport.messaging.post({ ... });
-      return { ... };
-  }
-  ```
+###### The `workport` API
 
-  For cross-thread messaging, both sides of the API exposes the following methods:
-  
-  + **`.messaging.post()`** - for sending arbitrary data to the other side. E.g. `workport.messaging.post({ type: 'TEST' })`.
-  + **`.messaging.listen()`** - for listening to `message` event from the other side. E.g. `workport.messaging.listen(event => console.log(event.data.type))`. (See [`window: onmessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/message_event), [`worker: onmessage`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/message_event).)
-  + **`.messaging.request()`** - for sending *replyable* messages to the other side, using the [MessageChannel](https://developer.mozilla.org/docs/Web/API/MessageChannel/MessageChannel) API.
-    
-    ```js
-    // On the worker side
-    workport.messaging.listen(event => {
-        console.log(event.data);
-        if (event.ports[0]) {
-            event.ports[0].postMessage({ type: 'WORKS' });
-        }
-    });
-    ```
-    
-    ```js
-    // On the client side
-    let response = await workport.messaging.request({ type: 'TEST' });
-    console.log(response); // { type: 'WORKS' }
-    ```
-    
-  + **`.messaging.channel()`** - for sending *broadcast* messages to the other side - including all other browsing contents that live on the same origin, using the [Broadcast Channel](https://developer.mozilla.org/docs/Web/API/Broadcast_Channel_API) API.
-    
-    ```js
-    // On the worker side
-    let channelId = 'channel-1';
-    workport.messaging.channel(channelId).listen(event => {
-        console.log(event.data);
-    });
-    ```
-    
-    ```js
-    // On the client side
-    let channelId = 'channel-1';
-    workport.messaging.channel(channelId).broadcast({ type: 'TEST' });
-    ```
-  
-  For [UI Nofitications](https://developer.mozilla.org/en-US/docs/Web/API/notification), both sides of the API exposes the following methods:
-  
-  + **`.nofitications.fire()`** - for firing up a UI notification. This uses the [`Nofitications constructor`](https://developer.mozilla.org/en-US/docs/Web/API/Notification/Notification), and thus, accepts the same arguments as the constructor. But it returns a `Promise` that resolves when the notification is *clicked* or *closed*, but rejects when the notification encounters an error, or when the application isn't granted the [notification permission](https://developer.mozilla.org/en-US/docs/Web/API/Notification/requestPermission).
-    
-    ```js
-    let title = 'Test Nofitication';
-    let options = { body: '...', icon: '...', actions: [ ... ] };
-    workport.nofitications.fire(title, options).then(event => {
-        console.log(event.action);
-    });
-    ```
-  
-  + **`.nofitications.listen()`** - (in Service-Workers) for listening to [`notificationclick`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/notificationclick_event) events. (Handlers are called each time a notification is clicked.)
-    
-    ```js
-    workport.nofitications.listen(event => {
-        console.log(event.action);
-    });
-    ```
-    
-  For [Push Nofitications](https://developer.mozilla.org/en-US/docs/Web/API/Push_API), the client-side of the API exposes the following methods:
-  
-  + **`.push.subscribe()`** - the equivalent of the [`PushManager.subscribe()`](https://developer.mozilla.org/en-US/docs/Web/API/PushManager/subscribe) method. (But this can also take the *applicationServerKey* as a first argument, and other options as a second argument, in which case it automatically runs the key through an `urlBase64ToUint8Array()` function.)
-  + **`.push.unsubscribe()`** - the equivalent of the [`PushSubscription.unsubscribe()`](https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription/unsubscribe) method.
-  + **`.push.getSubscription()`** - the equivalent of the [`PushManager.getSubscription()`](https://developer.mozilla.org/en-US/docs/Web/API/PushManager/getSubscription) method.
+This is an object with simple methods for working with *cross-thread* messages, UI and Push Notifications.
 
-  The worker-side of the API exposes the following methods:
-  
-  + **`.push.listen()`** - for listening to the [`push`](https://developer.mozilla.org/en-US/docs/Web/API/PushEvent) from within Service Workers. E.g. `workport.push.listen(event => console.log(event.data.type))`.
+On both the client and worker side of your application, the `workport` object is accessible from route handlers as `this.runtime.workport`.
 
-+ Route *events* - simple route events that fire when messaging and notification events happen.
+```js
+/**
+ [client|worker]
+├── index.js
+*/
+export default async function(event, context, next) {
+    let { workport } = this.runtime;
+    workport.messaging.post({ ... });
+    return { ... };
+}
+```
+
+For cross-thread messaging, both sides of the API exposes the following methods:
+
+<details>
+<summary>Method: <code>.messaging.post()</code></summary>
+
+The `.messaging.post()` method is used for sending any arbitrary data to the other side. E.g. `workport.messaging.post({ type: 'TEST' })`.
+</details>
+
+<details>
+<summary>Method: <code>.messaging.listen()</code></summary>
+
+The `.messaging.listen()` method is used for registering a listener to the `message` event from the other side. E.g. `workport.messaging.listen(event => console.log(event.data.type))`. (See [`window: onmessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/message_event), [`worker: onmessage`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/message_event).)
+</details>
+
+<details>
+<summary>Method: <code>.messaging.request()</code></summary>
+
+The `.messaging.request()` method is used for sending a message to the other side and obtaing a response, using the [MessageChannel](https://developer.mozilla.org/docs/Web/API/MessageChannel/MessageChannel) API.
+
+```js
+// On the worker side
+workport.messaging.listen(event => {
+console.log(event.data);
+    if (event.ports[0]) {
+        event.ports[0].postMessage({ type: 'WORKS' });
+    }
+});
+```
+
+```js
+// On the client side
+let response = await workport.messaging.request({ type: 'TEST' });
+console.log(response); // { type: 'WORKS' }
+```
+</details>
+
+<details>
+<summary>Method: <code>.messaging.channel()</code></summary>
+
+The `.messaging.channel()` method is used for sending *broadcast* messages to the other side - including all other browsing contents that live on the same origin, using the [Broadcast Channel](https://developer.mozilla.org/docs/Web/API/Broadcast_Channel_API) API.
+
+```js
+// On the worker side
+let channelId = 'channel-1';
+workport.messaging.channel(channelId).listen(event => {
+    console.log(event.data);
+});
+```
+
+```js
+// On the client side
+let channelId = 'channel-1';
+workport.messaging.channel(channelId).broadcast({ type: 'TEST' });
+```
+</details>
+
+For [UI Nofitications](https://developer.mozilla.org/en-US/docs/Web/API/notification), both sides of the API exposes the following methods:
+
+<details>
+<summary>Method: <code>.nofitications.fire()</code></summary>
+
+The `.nofitications.fire()` method is used for firing up a UI notification. This uses the [`Nofitications constructor`](https://developer.mozilla.org/en-US/docs/Web/API/Notification/Notification), and thus, accepts the same arguments as the constructor. But it returns a `Promise` that resolves when the notification is *clicked* or *closed*, but rejects when the notification encounters an error, or when the application isn't granted the [notification permission](https://developer.mozilla.org/en-US/docs/Web/API/Notification/requestPermission).
+
+```js
+let title = 'Test Nofitication';
+let options = { body: '...', icon: '...', actions: [ ... ] };
+workport.nofitications.fire(title, options).then(event => {
+    console.log(event.action);
+});
+```
+</details>
+
+<details>
+<summary>Method: <code>.nofitications.listen()</code></summary>
+
+The `.nofitications.listen()` method (in Service-Workers) is used for listening to [`notificationclick`](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/notificationclick_event) events. (Handlers are called each time a notification is clicked.)
+
+```js
+workport.nofitications.listen(event => {
+    console.log(event.action);
+});
+```
+</details>
+
+For [Push Nofitications](https://developer.mozilla.org/en-US/docs/Web/API/Push_API), the client-side of the API exposes the following methods:
+
+<details>
+<summary>Method: <code>.push.subscribe()</code></summary>
+
+The `.push.subscribe()` method is the equivalent of the [`PushManager.subscribe()`](https://developer.mozilla.org/en-US/docs/Web/API/PushManager/subscribe) method. (But this can also take the *applicationServerKey* as a first argument, and other options as a second argument, in which case it automatically runs the key through an `urlBase64ToUint8Array()` function.)
+</details>
+
+<details>
+<summary>Method: <code>.push.unsubscribe()</code></summary>
+
+The `.push.unsubscribe()` method is the equivalent of the [`PushSubscription.unsubscribe()`](https://developer.mozilla.org/en-US/docs/Web/API/PushSubscription/unsubscribe) method.
+</details>
+
+<details>
+<summary>Method: <code>.push.getSubscription()</code></summary>
+
+The `.push.getSubscription()` method is the equivalent of the [`PushManager.getSubscription()`](https://developer.mozilla.org/en-US/docs/Web/API/PushManager/getSubscription) method.
+</details>
+
+The worker-side of the API exposes the following methods:
+
+<details>
+<summary>Method: <code>.push.listen()</code></summary>
+
+The `.push.listen()` method is for listening to the [`push`](https://developer.mozilla.org/en-US/docs/Web/API/PushEvent) from within Service Workers. E.g. `workport.push.listen(event => console.log(event.data.type))`.
+</details>
+
+###### Route *events*
+
+These are simple route events that fire when messaging and notification events happen.
+
+On both the client and worker side of your application, you can define an event listener alongside your *root* route handler. The event listener is called to handle all messaging and notification events that happen.
+
+```js
+/**
+ [client|worker]
+├── index.js
+*/
+export default async function(event, context, next) {
+    return { ... };
+}
+export async function alert(event, context, next) {
+    return { ... };
+}
+```
+
+The event type is given in the `event.type` property. This could be:
+
++ **`message`** - both client and worker side. For *replyable* messages, the event handler's return value is automatically sent back as response.
++ **`notificationclick`** - worker side.
++ **`push`** - worker side.
+
+<details>
+<summary>Advanced...</summary>
+
+The `next()` function could be used to delegate the handling of an event to step handlers where defined. This time, the path name must be given as a second argument to the call.
+
+```js
+/**
+ worker
+├── index.js
+*/
+export async function alert(event, context, next) {
+    if (event.type === 'push') {
+        await next(context, '/services/push');
+        return;
+    }
+    console.log(event.type);
+}
+```
+</details>
 
-  On both the client and worker side of your application, you can define an event listener alongside your *root* route handler. The event listener is called to handle all messaging and notification events that happen.
-  
-  ```js
-  /**
-  [client|worker]
-   ├── index.js
-   */
-  export default async function(event, context, next) {
-      return { ... };
-  }
-  export async function alert(event, context, next) {
-      return { ... };
-  }
-  ```
-  
-  The event type is given in the `event.type` property. This could be:
-  
-  + **`message`** - both client and worker side. For *replyable* messages, the event handler's return value is automatically sent back as response.
-  + **`notificationclick`** - worker side.
-  + **`push`** - worker side.
-  
-  The `next()` function could be used to delegate the handling of an event to step handlers where defined. This time, the path name must be given as a second argument to the call.
-  
-  ```js
-  /**
-  worker
-   ├── index.js
-   */
-  export async function alert(event, context, next) {
-      if (event.type === 'push') {
-          await next(context, '/services/push');
-          return;
-      }
-      console.log(event.type);
-  }
-  ```
-  
 #### API Backends
 
 In Webflo, an API backend is what you, in essence, come off with with your server-side routes.
@@ -1694,16 +1946,15 @@ A simple tool, like [`staticgen`](https://github.com/tj/staticgen), or the basic
 }
 ```
 
-> **Note**
-> <br>Above, we used the `-P` flag to specify the output directory as `public`, the `-nv` flag to opt into “non-verbose” mode which outputs less information, the `-r` flag to get it to crawl and download recursively, and the `-E` flag to get it to add the `.html` extension to generated files.
-
-You have a static site!
+<details>
+<summary>How it works...</summary>
 
-### Workflow API
+> Above, we used the `-P` flag to specify the output directory as `public`, the `-nv` flag to opt into “non-verbose” mode which outputs less information, the `-r` flag to get it to crawl and download recursively, and the `-E` flag to get it to add the `.html` extension to generated files.
+</details>
 
-> TODO
+*Happy static!*
 
-### Webflo Config
+## Webflo Config
 
 Webflo comes *convention-first*! But it is entirely configurable for when you need it! The easiest way to do this is to run the command `webflo config` and follow the walkthrough. To simply get an overview, use the command `webflo config help`, and all commands and their description are shown.
 
@@ -1713,7 +1964,7 @@ Webflo applications are often built on/with the following technologies.
 
 ### OOHTML
 
-[OOHTML](https://github.com/webqit/oohtml) is a proposed set of new features for HTML that makes it fun to hand-author your UI! Within OOHTML are [HTML Modules](https://github.com/webqit/oohtml#html-modules) and [HTML Imports](https://github.com/webqit/oohtml#html-imports), [Reactive Scripts](https://github.com/webqit/oohtml#subscript) and more!
+[OOHTML](https://github.com/webqit/oohtml) is a proposed set of new features for HTML that makes it fun to hand-author your HTML documents! Within OOHTML are [HTML Modules](https://github.com/webqit/oohtml#html-modules) and [HTML Imports](https://github.com/webqit/oohtml#html-imports), [Reactive Scripts](https://github.com/webqit/oohtml#subscript) and more!
 
 Webflo natively supports OOHTML in full! But it is also possible to switch this to none, or to partial support - when specific features aren't needed anywhere in your application. Server-side and client-side support for OOHTML exist independently. This is good when, for example, your application places more importance on SSR, and less on CSR, in which case a reduced support for OOHTML can reduce the overall client JS bundle size.
 
@@ -1726,7 +1977,9 @@ Webflo natively supports OOHTML in full! But it is also possible to switch this
 
 *Values: `full`, `namespacing`, `scripting`, `templating`, `none` - See [details at OOHTML SSR](https://github.com/webqit/oohtml-ssr#options)*
 
-> File: `.webqit/webflo/client.json` | Command: `webflo config client oohtml_support=full`
+> **File: `.webqit/webflo/client.json`**
+
+> **Command: `webflo config client oohtml_support=full`**
 
 > File: `.webqit/webflo/server.json` | Command: `webflo config server oohtml_support=full`
 </details>

package/package.json

@@ -12,7 +12,7 @@
     "vanila-javascript"
   ],
   "homepage": "https://webqit.io/tooling/webflo",
-  "version": "0.11.12",
+  "version": "0.11.15",
   "license": "MIT",
   "repository": {
     "type": "git",