added: ability to supply html string as dependency for dynamicUrlToDependencies

[HenrikJoreteg]

First off thanks @jeffposnick and co for your work on this awesome lib!

This PR addresses the use-case I mentioned here: #156 (comment)

To summarize, we have a scenario where we don't have a static "base" html file or even a template file that changes each time the cached "dynamicUrl" should be considered changed. Instead, our dependency is really the resulting HTML string that we generate for that environment. The / dynamic route that we're trying to precache is the result of an aggregated environment-specific config object and an HTML template. I could list out a set of config files that is used to aggregate that config, but doing so would be brittle and error prone. Instead, this suggested change enables passing the contents of the file itself as a dependency for the dynamicUrlToDependencies option.

So if the sw-precache library gets a string instead of an array it will use that to generate a hash, and add it to the total size.

This PR represents the change I've made locally to make this work for us. So far it's working well for us and I'd love to see this adopted upsteam. If this looks/sounds reasonable to you, I'll tack on some updates to the docs as well. I just wanted to float the idea first before I spend time on that.

Please let me know what you think when you have a sec. Thanks!

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[HenrikJoreteg]

I signed it!

[googlebot]

CLAs look good, thanks!

[gauntface]

The changes seem sane to me. Not sure about the "cumulativeSize" change largely because I don't know how that value is used.

[HenrikJoreteg]

@gauntface cool! The cumulativeSize change seems to be used primarily to provide useful output when in verbose mode.

Judging by the comment in the snippet below and how it currently builds cumulativeSize when it gets an array of dependencies, it seems like it's just a loose estimate as CLI output to show roughly how big your total precache will be:

(snippet from here: https://github.com/GoogleChrome/sw-precache/blob/master/lib/sw-precache.js#L220-L221)

      filesAndSizesAndHashes.forEach(function(fileAndSizeAndHash) {
        // Let's assume that the response size of a server-generated page is roughly equal to the
        // total size of all its components.
        cumulativeSize += fileAndSizeAndHash.size;
        concatenatedHashes += fileAndSizeAndHash.hash;
      });

[HenrikJoreteg]

Also, @gauntface, i saw your tweet about sw-helpers which looks cool. The only thing is, as far as I can tell, using that would require switching mechanisms for all this stuff entirely and we've already got sw-precache baked in and working well. This tweak just fixes this one little snag we ran into. Ultimately I like the look of the sw-helpers stuff, though. But right now I just wanna get our app shipped.

[jeffposnick]

Thanks for the submission, @HenrikJoreteg! This seems like a use case that's worthwhile and straightforward to support, and I'll give the PR a review in the near future.

[jeffposnick]

I'll update the documentation, and cut a new minor release that includes this change (also in the near future).

[HenrikJoreteg]

sweet, thanks @jeffposnick

[jeffposnick]

@HenrikJoreteg, it's been published as 5.1.0.

[HenrikJoreteg]

@jeffposnick 🎉