Added Request Parameter

The request object now includes the path of the request. Below is an example of a request:

{
	type: "GET",
	path: "#/custom/Custom%20Text%20Here"
	referrer: "#/",
	data: {
		text: "Custom Text Here"
	}
}

Add Cache Skipper

Now, there is an option in get to skip the cache. The second parameter of get is a boolean starting as false, but when true, bypasses the cache, makes the fetch request, and then returns the result without caching. If the developer wants to get from the cache only or set to the cache only, they need to use the getCachedPage and setCachedPage methods according to the standard defined in get, as the use-case for this degree of cache selectivity is extremely rare.

Route Parameters

In this release, tApp now supports URL parameters within the route. When a route URL contains <parameter>, for example #/custom/<text> or #/custom/<text>/subpage, the text variable is passed as a parameter by the URL (so a visit to #/custom/helloworld will trigger the #/custom/<text> route). Variables can be accessed through the request parameter of the route function as request.data.parameter (so for our example, request.data.text).

Fix Caching Bug

With caching new assets, tApp was converting the assets to text and then rebuilding the response object from the text and response data. Now, tApp stores an array buffer, so responses can be reconstructed by new Response(cachedPage.data, cachedPage.response).

Update Fetch/Cache

In this release, fetching using tApp.get(path) now returns a full response object (instead of just the text), and there is caching support for other content types besides HTML (through the new cache parameter cachedPage.response, which when combined with cachedPage.data, can be used to reconstruct the response with new Response(new Blob([cachedPage.data]), cachedPage.response)).

Periodic Cache Updates

Through specifying a number of milliseconds in the periodicUpdate parameter of caching in the configure, the tApp will automatically recache assets periodically to keep them up to date.

Fix Bug with Service Worker

Fixes bug affecting the edge case of ignoring non-GET requests, added more comments for pointers on modifying the service worker.

Template Escape Characters

Templates with {\{ varName }} render to {{ varName }} instead of replacing with the value of varName.

Fix Caching Bug

Initially, caching was handled solely in the tApp.js script. However, when the tApp is installed using tApp-service-worker.js, the service worker would cache urls for any requests (including requests that did not go through tApp.js). Both scripts would write to the cache at different times, causing the cache to be stuck on a specific version of the file and never update (tApp-service-worker.js would intercept request from tApp.js, return cached, and then fetch from network if possible and update the cache, however, tApp.js would update the cache after "fetching", which in the case of using the intercepting service worker would actually come from the cache instead of the network as intended, potentially overwriting the new file from the service worker).

This bug has now been fixed by having the service worker ignore the cache and fetch from the network if the request originated from tApp.js with the header tApp-Ignore-Cache: Ignore-Cache (automatically added by tApp.js) to allow tApp.js to handle caching, and if no header of this kind is present, use the normal caching structure in the service worker (to handle requests not sent through tApp.js).

Basic Templating

tApp now supports template files. Through the renderTemplate(path, options) and renderTemplateHTML(html, options) render functions, an object of options can be passed for rendering. Variables can be stored in the template as {{ varName }} (spaces optional), and in options, {varName: value}. Templates also support nested variables ({{ varName.nested1.nested2 }} in template and {varName: {nested1: {nested2: value}}} in options) and arrays ({{ varName.0 }} in template and {varName: [values]} in options).