Fix values provided by H5Grove

[axelboc]

• Return scalar values instead of typed arrays of length 1.
• Restore flattening of non-numeric arrays.
• Return classic JS arrays instead of typed arrays until we decide whether/how to support typed arrays in the visualizations.
• Assert values returned by providers against datasets type and shape to avoid future regressions - fix [types] Strengthen Value<D> type #824

[loichuder]

There is a complexity layer that is missed by your assertions: the presence of selection in the params changes the shape of the array returned from the request. It can even return a scalar value instead of an array.

This means the checks of shapes (such as in h5grove provider and in assertDatasetValue) must be done according to the asked selection rather than considering the full dataset metadata. Same thing for the flattening.

[axelboc]

Right, I need to re-add the flattenValue utility that we've removed. That being said, I don't think it ever supported the case of the selection of a scalar. When we ignore this edge case, assertDatasetValue works fine, as it always receives an array.

Since this edge case isn't something we encounter in the viewer, I don't really see the point of supporting it. At least not in this PR.

[axelboc]

This will throw if we ask the API to select a scalar, so at least we'll know (in the unlikely event we write code that does this inadvertently).

[loichuder]

I understand that given our usecases, we will never get a scalar from an array dataset.

Still it bothers me to prevent it for the following reasons:

• Here and in assertDatasetValue usage locations, we have access to selection. So we could assert according to the selection.
• The type inference in useDatasetValue could make use of dimMapping to have a Value<D> corresponding to the gotten slice.

Anyway, this will do for now.

[axelboc]

Sure, it's all doable, but adding this level of type safety to useDatasetValue means that we then have to assert that the returned value is not scalar inside the relevant containers, which leads to exactly the same result as the assertion that the value returned by the provider is an array regardless of selection.

If anything, it would make more sense to prevent useDatasetValue from being called with a dimMapping that only contains numbers.

[axelboc]

Either way, we still have implicit coupling between useDatasetValue and the provider APIs' getValue methods... Perhaps a better solution would be to rethink the signature of getValue to make this coupling more explicit - e.g. by letting the method accept a dataset rather than an entity, and an optional dimension mapping array with at least one axis in it.

[loichuder]

I understand that given our usecases, we will never get a scalar from an array dataset.

Still it bothers me to prevent it for the following reasons:

• Here and in assertDatasetValue usage locations, we have access to selection. So we could assert according to the selection.
• The type inference in useDatasetValue could make use of dimMapping to have a Value<D> corresponding to the gotten slice.

Anyway, this will do for now.