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

Response for returning data points should have stronger typing #922

Open
Robin-Hoodie opened this issue Nov 29, 2022 · 1 comment
Open

Comments

@Robin-Hoodie
Copy link

Robin-Hoodie commented Nov 29, 2022

Currently, the datapoints.retrieve method returns a response of Promise<DatapointAggregates[] | Datapoints[]>.

This makes things more complicated for consumers than they need to be, as they either have to:

  • Type cast the response
  • Add their own wrapper method, which does allow for a properly typed response

Consumers should ideally be able to call retrieve without needing to pass a generic type, as the return type can be inferred from the query argument

const datapoints = client.datapoints.retrieve({ aggregates: ['average'], granularity: '1d' , /*...rest of args*/ });
// datapoints is typed as Promise<DatapointAggregates[]>`

const datapoints = client.datapoints.retrieve(/*...args without 'aggregates'*/);
// datapoints is typed as Promise<Datapoints[]>

Going even further, I think it'd also be a good idea to be able to strongly type the types of aggregates themselves.
As in, if we pass aggregates: ['average', 'min'], the response is currently still returning a set of datapoints where both average and min can be undefined, even though we know they are in fact defined.

Thinking about possible implementations, it'd probably make sense to require consumers to pass in a generic type for this possibility. Not requiring that would likely result in a combinatory explosion.

@Robin-Hoodie Robin-Hoodie changed the title Response for returning data points should be typed properly Response for returning data points should have stronger typing Nov 29, 2022
@Robin-Hoodie
Copy link
Author

Any feedback on this?

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

No branches or pull requests

1 participant