You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
constdatapoints=client.datapoints.retrieve({aggregates: ['average'],granularity: '1d',/*...rest of args*/});// datapoints is typed as Promise<DatapointAggregates[]>`constdatapoints=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.
The text was updated successfully, but these errors were encountered:
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
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:
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 argumentGoing 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 bothaverage
andmin
can beundefined
, 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.
The text was updated successfully, but these errors were encountered: