enable control of cache behavior for source and query APIs

[zbigg]

Add cache control parameters to sources and query API.

• detect caching from HTTP headers.
• allow selecting cache behavior as well as providing custom cache storage

Usage example:

  // for new users: will obey standard HTTP Control-Cache
  const myCache = new Map()
  const widgetSource = new vectorQuerySource({
    sqlQuery: 'select * from ...',
    // disable local cache, note browser and proxy cache can still cache something
    localCache: { cacheControl: 'no-cache' }
    // to completly prevent caching you must *also* set headers
    headers: { 'Cache-Control: no-cache' },
    // use specific map for cache cache
    localCache: { cache: myCache }
  });
  
  something.onClick() = {
    // clear cache before in context let's say - refresh action
    myCache.clear()
    rerenderLayers()
  }

[zbigg]

This very raw proposal that solves problem of cache control in most minimalistic way

• fixes behavior for old-clients that wanted already tried to control cache with headers
• allows to explictly control local cache behavior

I still left Cache-Control intepretation in this proposal as this was my first attempt. Now i see this may be too far-fetched and too complex and buggy (there are more APIs to control). We should probably remove it and rely only on explict props.

On the other hand current behavior is simply wrong. People may pass Cache-control: no-cache ... and find that request is cached anyway ... Leaving it for consideration.

[donmccurdy]

I'm tempted to stop inspecting headers to determine the local cache settings, and let that be based on the localCache prop alone. Do you think that would be OK? Presumably this would land in deck.gl v9.1.

It is nice that users who need to explicitly clear the cache can now do:

const cache = new Map()
const widgetSource = new WidgetQuerySource({localCache: { cache }, ... });

...

cache.clear();

[donmccurdy]

Assuming we plan to respect the definitions of HTTP CacheControl headers, do we want to borrow their API too? This could be...

export type LocalCacheOptions = {
  cache?: Map<string, Promise<unknown>>;
  cacheControl?: ('no-cache' | 'no-store')[]
}

... which is nice because external users can find existing API documentation easily.

[felixpalmer]

Once we are down to two options, I wouldn't use a nested cache object and instead just provide these options directly

[zbigg]

Honestly, i would go in other direction.

We clearly have "domain" options (url params, post params) and meta params: cache, max url length, context, signal in near future hopefully.

I would separate those "meta" params into one object, so it's easy to pass it around between layers. Those spread operators tend to be tedious when you have to repeat them with more than handful of values in many places.
(look at old react-widgets model props).

[felixpalmer]

Fair enough

[donmccurdy]

Looks good to me, thanks!