Support loading Parquet data via `sdata_store`

[keller-mark]

Currently, the widget just hangs when the JS code tries to load Parquet data across the _zarr_get function

vitessce-python/src/vitessce/widget.py

Line 845 in adb066c

def _zarr_get(self, params, buffers):

Our code on the JS side is designed to support this

https://github.com/vitessce/vitessce/blob/376ab6d74695d07ee9213882923e3024e180a29b/packages/file-types/spatial-zarr/src/SpatialDataTableSource.js#L236

Perhaps Zarr does not recognize the parquet relative path as a valid key. I seem to remember seeing a zarr issue about this (either a proposal or an issue/PR in one of the zarr implementations) about ignoring/excluding/erroring for non-zarr data contained in a zarr store/directory. For the life of me i cannot find the issue now. A quick look at the current Store.get methods in zarr-python make it seem like they don't check the returned data, so a closer look is needed.

[keller-mark]

Upon second look, it could be due to the lack of getRange support on the widget side. We only have _zarr_get in python

vitessce-python/src/vitessce/widget.py

Line 845 in adb066c

def _zarr_get(self, params, buffers):

which corresponds to the get function here

vitessce-python/src/vitessce/widget.py

Line 428 in adb066c

async get(key) {

But the parquet loading logic on the JS side relies on .getRange

https://github.com/vitessce/vitessce/blob/376ab6d74695d07ee9213882923e3024e180a29b/packages/file-types/spatial-zarr/src/SpatialDataTableSource.js#L320

An alternative to implementing getRange here would be to implement a blanket getRange in the vitessce JS package (i.e., the else clause of the if(store.getRange) linked above)

Kind of related to my comment here manzt/zarrita.js#319 (comment)