Revert "Reduce delay when slicing with h5wasm through viewer config" #1657
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hmm on second thoughts...
I was looking at #1572 and more specifically at the Autoscale feature of the Line visualization. This feature is designed to control how the domain of the line visualization is computed: when toggled on, the domain is computed from the current slice only; when toggled off, the domain is computed from the entire dataset.
Turns out in terms of data fetching, it is very similar to the prefetch button solution I tried in #1635: the difference is that when toggled off, it triggers a fetch/read of the entire dataset and not just one dimension. This actually simplifies a lot of things, since fetching the entire dataset triggers the suspense fallback (which means that the fetch can be cancelled if need be), and we don't have to rely on
react-suspense-fetch
to know whether to disable debouncing: we can just use the Autoscale state.So what I'm saying is that before settling on the
viewerConfig.slicingTiming
approach, I'd like to try a "pre-fetch button" approach again like in #1635, but designed to work more like the Autoscale toggle.As added benefits, it would allow disabling debouncing for h5grove as well, and would help us rethink that Autoscale feature to address #1572, which was always a bit confusing.