Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethink valid runtimeCaching.options #1096

Closed
jeffposnick opened this issue Dec 1, 2017 · 1 comment
Closed

Rethink valid runtimeCaching.options #1096

jeffposnick opened this issue Dec 1, 2017 · 1 comment
Assignees
Labels
Breaking Change Denotes a "major" semver change. workbox-build

Comments

@jeffposnick
Copy link
Contributor

Library Affected:
workbox-build

Working on #1095 made me realize that there's some cleanup to be done related to what we accept for runtimeCaching.options in v3. In v2, we basically supported the same set of options that sw-precache supported (plus a plugins property that could be used to provide additional lifecycle callback handlers).

As of what's checked in to the v3 branch today, our joi parameter validation looks like

options: joi.object().keys({
cacheName: joi.string(),
plugins: joi.array().items(joi.object()),
cacheExpiration: joi.object().keys({
maxEntries: joi.number().min(1),
maxAgeSeconds: joi.number().min(1),
}).or('maxEntries', 'maxAgeSeconds'),
cacheableResponse: joi.object().keys({
statuses: joi.array().items(joi.number().min(0).max(599)),
headers: joi.object(),
}).or('statuses', 'headers'),
}),

This is a departure from what we supported in v2/sw-precache, but there wasn't previously a breaking-change issue tracking that, so if nothing else, this serves to keep track of that.

But I realize that we could tweak things further in v3, by

  • supporting runtimeCaching.options.broadcastUpdate, which would configure a workbox.broadcastUpdate.Plugin instance.
  • renaming runtimeCaching.options.cacheExpiration to expiration, to reflect the fact that the module is exposed as workbox.expiration.
  • (Re-adding support for runtimeCaching.options.networkTimeoutSeconds, which I inadvertently removed from the joi config.)

So, I'm proposing that in v3 we'd support a full set of configuration that looked like:

runtimeCaching: [{
  urlPattern: /api/,
  handler: 'networkFirst',
  options: {
    networkTimeoutSeconds: 10,
    cacheName: 'my-api-cache',
    expiration: {
      maxEntries: 5,
      maxAgeSeconds: 60,
    },
    cacheableResponse: {
      statuses: [0, 200],
      headers: {'x-test': 'true'},
    },
    broadcastUpdate: {
      channelName: 'my-update-channel',
    },
    plugins: [
      {cacheDidUpdate: () => /* custom plugin code */}
    ],
  },
}],

Any concerns there?

@jeffposnick
Copy link
Contributor Author

I'm going to move ahead with this, targeted for the next v3 alpha release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Breaking Change Denotes a "major" semver change. workbox-build
Projects
None yet
Development

No branches or pull requests

1 participant