Data table record selection to edit form

This version introduces an 'edit' button to the data table and listens to 'record click' events within the table. Clicking on a record within the data table now loads the edit form for the record. While the edit form does not currently save any entries. The data table module has several events that we can listened to. The event we use in this app is the 'on:clickCell' event that is not documented by the developer but is one of the most useful features of this module.

API data and DFG configurations to indexedDb

This version introduces a more solid API data schema to test against and updated DFG (dynamically generated forms) configurations. The indexedDb table schema was reworked as well. API test data now includes UUID identifiers for records and the form configurations are sent along with the API data from the server and saved to indexedDb tables. The next release will seek to edit test records using our DFG.

Dynamic form generation

Going deeper into working with indexedDb and found what should be a useful module for dynamic form generation based on JSON configuration. The dynamic form generation should allow for the data forms to be defined along with data being retrieved from the server side to possibly prevent much hard-coding of forms within the front-end app.
The next iteration should include use of the dynamic forms and saving data retrieved from the server for editing in the app.

indexedDb framework

After some trial and error with indexedDb I found that setting up the database connection first thing when loading the app and saving the connection to the Svelte data store gave me something to work with. This release was a big win because indexedDb has a 'feature' where you cannot close a database connection and re-establish within the same session. Yes there is a db.close() method with indexedDb but I don't see the point of it since it does not serve a useful purpose. If you cannot re-establish a lost/corrupt connection within the same user origin session then why have the method to begin with? I also ditched the indexedDb wrapper plugins since they were causing more headaches than it was worth.

Fixed production build in the rollup

I had rewritten the rollup.config.js a version or two ago to handle caching and the build and remembered that I had changed the production build execution process to actually build to my local server (which was breaking my production builds on https://svelte2-cyan.now.sh/). This version corrects the rollup process.

Cache updating

This code release has service worker precache clearing built in. A localStorage key was added to compare previously installed code versions with the current version on the end-user side in order to clear the CacheStorage which is critical to the clearing the app cache.

Cache handling almost there

This code release was suppose to address some caching updates but there were some caching issues when offline that need to be resolved in the next release.

Cache handling (seems to be upating properly)

NOTE: This version was released on April 3, 2020 (if you downloaded v0.1.7 earlier than this data you will want to change to this one). I updated the release versions after finding critical issues in the previous code.

This version is a rewrite of the previous version that was missing essential pieces. This version seems to properly clear the CacheStorage and register an updated service worker when a new code version is pushed. I added extra checks to ensure that the code version is only checked while the user is online.

Cache release in progress

This version should help release the file cache when the fileVersion constant in the rollup.config.js script is updated, but it does not address the service worker cache in the browser CacheStorage.

Simple API test

A simple Laravel API data test was created and the UI simplified.