Now that we have tons of data about Pokemon (what they are, where they are, what’s their relationship, what they can transform into, which attacks they can perform, aso) we want to integrate it all into a comprehensive website. This website should contain sections about each Pokemon and its details. Additionally, the website should register the user’s location and tell the user how close is that the predicted pokemon to him/her. Additionally you will be incorporating the apps that were created by project B,C and D into the website. Your group will need to create automated builds and testing for this apps and use continuous integration to pull in new changes in the code repositories. Apps from projects B-D should be packaged and made available on NPM. Ideally when you completed these tasks the webapp component would integrate the apps by “requiring’ them. Here is a possible user story: when a user opens the website or the app the current location of the user will be shown. Additionally, the website/app will show automatically where the pokemons that are currently active are and where the pokemons that we predict to active in the nearest future (i.e. within half a day) will be located (all of this will be available from the app developed in project D). Hopefully, the website will be somewhat crowded by that data. Then, there needs to be a menu bar or something available (e.g. above the map or on the right side to it) that will list currently active or predicted pokemons. Clicking on one of them will make other pokemons on the map disappear, except of this clicked one. Separate web pages would allow the search and presentation of individual Pokemons and the information we gathered about them, including third party data (project A) and twitter analysis (project C)
There were a few things wrong with the current implementation of the service worker. This PR tries to fix these issues.
There used to be static CACHE_VERSION=1 in service-worker.js which no one every really bothered to update. This resulted in a cache returning old files. The new implementation updates the CACHE_VERSION on every build (it's set to the current timestamp). This will flush the cache entirely.
We are now more cautious about which requests to cache. Only certain file types are being cached. The old service implementation cached every possible request including web socket communication which seems very error prone at this stage of development.
Moved the service worker registration from the index file to a designated file.
Refactored the entire service-worker.js and added some debugging log output.
Disabled the maxage caching option for express. This setting only made sense when we were still using webpack because it appended a unique hashe to every bundle file name. With rollup the name of the bundles doesn't change between builds which is why we should not cache them for too long.
There were a few things wrong with the current implementation of the service worker. This PR tries to fix these issues.
CACHE_VERSION=1
in service-worker.js which no one every really bothered to update. This resulted in a cache returning old files. The new implementation updates theCACHE_VERSION
on every build (it's set to the current timestamp). This will flush the cache entirely.maxage
caching option for express. This setting only made sense when we were still using webpack because it appended a unique hashe to every bundle file name. With rollup the name of the bundles doesn't change between builds which is why we should not cache them for too long.