Represent "store that wraps existing store" in the type system to encourage Store composition / "middleware" store implementations

[keller-mark]

Zarr-python has WrapperStore https://github.com/zarr-developers/zarr-python/blob/25ee087e8f408a7f883c25709c6bb9013348c64c/src/zarr/storage/_wrapper.py#L19

I think it would be good to encourage such stores in Zarrita.js with a type such as WrapperAsyncReadable, whose constructor takes an existing AsyncReadable.

export class MyWrapperStore implements WrapperAsyncReadable<{ signal: AbortSignal }> {
  constructor(internal_store: AsyncReadable) {
    this.#internal_store = internal_store;
  }

  static async fromStore(internal_store: AsyncReadable): Promise<MyWrapperStore> {
    // Note: not awaiting anything here, but it may be needed in certain cases.
    return new MyWrapperStore(internal_store);
  }
}

I have found this pattern to be useful in places like https://github.com/keller-mark/hdf5-as-virtual-zarr.js/blob/b83cb5e731f5e62f763c8bc43d0c262a0f3ade07/src/hdf-store.ts#L6

Adding this to Zarrita as an exported type would encourage this pattern over one where a custom store only supports a fromUrl initialization pattern, despite the internals not being specific to HTTP-fetched data.

[manzt]

Want to have a look at #384 ?

With this, caching could be implemented as:

import * as zarr from "zarrita";

const withCaching = zarr.wrapStore(
  (store, opts: { maxSize?: number }) => {
    let cache = new Map();
    return {
      async get(key, options) {
        let hit = cache.get(key);
        if (hit) return hit;
        let result = await store.get(key, options);
        if (result) cache.set(key, result);
        return result;
      },
      clear() { cache.clear(); },
    };
  },
);


const store = zarr.createStore(
  new FetchStore("..."),
  withCaching({ maxSize: 10 }),
);

store.clear() // from caching middleware

[manzt]

I'm closing with plan outlined in #394, and several PRs.