cc @addyosmani @wibblymat @jeffposnick
At the moment the precache API allows strings, arrays and promises.
I would like to propose the following:
Change precache to accept only an array, this will cause:
toolbox.precache('/single-asset);
to be written as:
toolbox.precache(['/single-asset']);
Secondly remove support for nested arrays. This would require the developer to flatten the arrays and means the API wouldn't need to have some arbitrary limit on the number of nests.
toolbox.precache(['/single-asset', ['/asset-nested', '/asset-nested-2']]);
becomes:
toolbox.precache(['/single-asset', '/asset-nested', '/asset-nested-2']);
I don't feel like asking dev to do this is too much of an ask (lodash has a deepflatten method if consumers of the library wanted a quick solution).
I feel like the majority of users will want several assets cached rather than a single asset for the majority of the time.
I'm struggling what a good reasoning for promises in precache. I can see some value in being able to get an asset list, are there other use cases?
The main reason I see it as being beneficial is largely because the precache method abstracts away the ability to use event.waitUntil , so this support is your only option to perform some async action.
Ideally I'd like to see either precache take a single promise i this scenario and expect consumers of the library to make user of Promise.all or whatever means to manage logic required OR make it such that toolbox caching can be done from within the install step.
For the single promise approach the expectation of this would be to return an array of strings to cache. This would ideally be named something differently to avoid overloading the precache method.
This would result in an API surface of something along the lines of:
toolbox.precache();
toolboxprecacheAsync();