export fetchAndCache so it can be used by user code

[markbrocato]

I think it would be helpful to expose helpers.fetchAndCache so that users that implement their own handlers can use it. It would also be nice to expose the entire helpers module, but perhaps that's a bridge too far?

[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).

:memo: 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.

[jeffposnick]

I'm wary of going too far down the road of allowing folks to pick and choose what they use from sw-toolbox, because I think we have a cleaner approach to modular reuse that we're working on described in https://github.com/GoogleChrome/sw-helpers/issues/44

@markbrocato, if you take a look at what we're planning on there (apologies as it's a long thread, but the bits towards the end should be the current thinking), would it meet your use case? It means waiting a bit until it's all implemented, but it would be a more future-looking approach.

[markbrocato]

I would benefit from a more modular approach because what I'm doing is trying to create handlers that target a specific framework (Sencha's Ext JS). I'd love to be able to access sw-toolbox's caching and expiration functionality, but need to tweak the way some of handlers work given the assumptions I can make about the way Ext JS makes AJAX requests. Specifically, what I want to implement is this:

Ext JS automatically appends a cache busting query param ?dc=(timestamp) to each AJAX request. I'd love to use the networkFirst handler, but since it uses the full url as the cache key, the presence of the cache bust will always result in a cache miss. What I need is a way to control how matching is done (or how the cache key is generated).

My first attempt was this:

function stripNoCache(request) {
    var url = request.url.replace(/_dc=\d+&?/, '');
    return new Request(url, request);
}
toolbox.networkFirst = function (request, values, options) {
    return toolbox.networkOnly(request, values, options)
        .then(function(response) {
            var cacheName = (options.cache && options.cache.name) || toolbox.options.cache.name;
            // cache response with _dc removed
            caches.open(cacheName).then(function(cache) {
                cache.put(stripNoCache(request), response)
            });
            return response.clone();
        })
        .catch(function(err) {
            return caches.match(stripNoCache(request))
        });
};

The problem is that ignores the options object. So things like options: { cache: { maxEntries } no longer work unless I reimplement them with my own code. Perhaps you can suggest a better approach? Or perhaps the api could be expanded to support this use case by allowing developers to customize how cache matching is implemented for specific routes?

[jeffposnick]

We're sufficiently far enough along with a combination of

https://github.com/GoogleChrome/sw-helpers/tree/master/packages/sw-runtime-caching https://github.com/GoogleChrome/sw-helpers/tree/master/packages/sw-cache-expiration

that you could give those a try. They're still an alpha release, and feedback is welcome.

I'm reluctant to change sw-toolbox to accommodate this use case given that the new libraries should address what you're trying to do.