Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debouncing fetcher logic #984

Open
dvmoritzschoefl opened this issue Oct 18, 2023 · 1 comment
Open

Debouncing fetcher logic #984

dvmoritzschoefl opened this issue Oct 18, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@dvmoritzschoefl
Copy link

It seems that currently the debouncing of requests is solved on a per-fetcher basis, meaning that every fetcher needs to implement the same logic again. We did not understand this at the beginning since the fetcher method is called fetchTilesDebounced which suggests that it would not be triggered on each zoom event. Maybe it would be useful to move this code to a base class.

@dvmoritzschoefl dvmoritzschoefl added the enhancement New feature or request label Oct 18, 2023
@etowahadams
Copy link
Contributor

Hi @dvmoritzschoefl,

This is a good point that would help improve adherence to the DRY principal.

Currently datafetchers with workers implementTabularDataFetcher. Instead, these datafetchers could extend a base TabularDataFetcher class which has has a default fetchTilesDebounced function as you suggested.

A little background which might be interesting:fetchTilesDebounced is the the primary way data is passed to GoslingTrack from datafetchers that don't use a worker, but not in datafetchers that use a worker, which instead use getTabularData. So actually, the logic in fetchTilesDebounced could also be removed for classes which implement TabularDataFetcher. However, higlass still expects there to be a function called fetchTilesDebounced so we still include it.

In the long term, we want for Gosling to be able to support custom datafetchers. To do this, we first need to reduce the API surface that is exposed to datafetchers through HiGlass. We are in the process of gradually adding types to HiGlass, which will make it easier to break apart into sub packages which in turn will make it easier to specify what parts of HiGlass the datafetchers have access to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants