Movement Challenge Calculator

This is an offline-enabled PWA hosted on Rendor at https://movement-challenge-calculator.onrender.com.

Indiana Sports Corp holds a virtual Movement Challenge for 10 days every summer leading into their Corporate Challenge event. They send out a PDF that helps participants convert time spent doing various activities (basketball, running, gardening, etc.) or steps to "virtual miles". This app is a simple standalone calculator that helps participants easily calculate their "virtual miles" without having to reference the PDF. RunSignup is where "virtual miles" are officially logged for this Movement Challenge. Unfortunately, there is no way to directly link to that mileage-entry page from our calculator, and there is no way to link from RunSignup to our calculator (unless the Corp Challenge folks make that happen). Ideally, a user could click a button in the calculator that would send you straight to the mileage-entry page on RunSignup with the mileage and activity pre-filled....but it's not possible as of now. The closest we could get was linking to a user's RunSignup Profile page (in the footer of this app), which has a "Submit Virtual Results" link.

Dev

Prerequisites

• NodeJS

Scripts

• npm start
  • Fires up a dev server at localhost:8000.
  • Because this is a PWA, to see app changes every time the page is manually refreshed, configure browser DevTools as follows:
    • Go to Application => Service Workers
    • Check boxes:
      • Update on reload
      • Bypass for network
• npm test
  • Loads test.html, which runs all tests. The service worker is not active when on this page.

Releases

• Each time a commit is pushed to the main branch, Rendor redeploys the updates.
• Because the app contains a service worker, the CACHE_VERSION in sw.js needs manually updated for each new release. For users that have previously been to the site (thus installed the previous version of the service worker), updating sw.js causes the browser to install and activate the new service worker next time they load or refresh the page. Because CACHE_VERSION is updated, the new service worker will clear all previously cached resources, download replacements, and refresh the page.
  • Here is a timeline of the events that take place:
    1. User navigates to site for the first time.
    2. Service worker installs and caches resources (index.html, app.js, etc.).
    3. Subsequent loads of the site fetch resources from the cache.
    4. New version of the app is deployed (including update to CACHE_VERSION in sw.js).
    5. User again navigates to site (or refreshes the page).
    6. Browser notices new service worker, installs it, activates it, creates new cache with new copies of resources, deletes old cache, and reloads page.