-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Typescript definitions for REST response #77
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great start of what this library should be. Thank you, @cwdx!
What do you think, @tiagosiebler?
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "ftx-api", | |||
"version": "1.1.8", | |||
"name": "ftx-api-typed", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR shouldn't change the package name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw @cwdx if this was to just make testing on your end easier, you can also get your package json to point to either a local folder (where you have your dev copy of the package) or your git fork, example:
"ftx-api": "github:cwdx/ftx-api#master"
You can also do this via npm install, even for a folder: npm install ../path/to/ftx-api
In case it makes testing easier.
package.json
Outdated
"name": "ftx-api", | ||
"version": "1.1.8", | ||
"name": "ftx-api-typed", | ||
"version": "1.2.3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why 1.2.3
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. Should be same version or 1.1.9 (assuming no breaking changes). If potentially risky (type conflicts), you can go for 1.2.0
export type GenericAPIResponse = Promise<any>; | ||
export type GenericAPIResponse<T> = Promise<{ | ||
success: boolean; | ||
result: T; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GenericApiResponse
should be a union type that models both the Success
and Failure
case.
When success
is false
, there is no result
.
We could also strip result
from GenericApiResponse
and instead define it as Promise<T>
that throws an FtxError
when success
is false
. I think this is more intuitive for library consumers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. GenericAPIResponse was primarily intended as a placeholder that all endpoints return Promise<semiStructuredSomething>
without being as frustrating as returning unknown
(frustrating for those less typescript exposed). I like the suggestion of the union between both cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, while definitely a nitpick I was planning on Promise<APIResponse<T>>
becoming the successor to GenericAPIResponse<T>
. I'm probably overthinking but I wanted it more obvious that all API calls return promises that contain API responses with T. GenericAPIResponse was just the very open placeholder until I had a chance to work on stronger types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. Promise
shouldn't be part of the response type.
export interface FuturesPosition { | ||
future: string; | ||
size: number; | ||
side: FuturesCoinType; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be OrderSide
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for spending time on this, this is a huge contribution that will benefit everyone using my connector. Some minor requests in some of the finer details but I love the direction this is going.
getRebateHistory(): GenericAPIResponse<unknown> { | ||
return this.requestWrapper.get('referral_rebate_history'); | ||
} | ||
|
||
getAnnouncements(language: string = 'en') { | ||
getAnnouncements(language: string = 'en'): GenericAPIResponse<unknown> { | ||
return this.requestWrapper.get( | ||
'notifications/get_announcements?language=' + language | ||
); | ||
} | ||
|
||
requestDust(toCoin: string): GenericAPIResponse { | ||
requestDust(toCoin: string): GenericAPIResponse<unknown> { | ||
return this.requestWrapper.post(`dust/quotes`, { toCoin }); | ||
} | ||
|
||
getDustStatus(quoteId: string): GenericAPIResponse { | ||
getDustStatus(quoteId: string): GenericAPIResponse<unknown> { | ||
return this.requestWrapper.get(`dust/quotes/${quoteId}`); | ||
} | ||
|
||
acceptDust(quoteId: string): GenericAPIResponse { | ||
acceptDust(quoteId: string): GenericAPIResponse<unknown> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since these are still "to do", I would prefer Promise<APIResponse<any>>
so that the change doesn't make any existing implementations angry about the lack of strict type checks once they upgrade.
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "ftx-api", | |||
"version": "1.1.8", | |||
"name": "ftx-api-typed", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw @cwdx if this was to just make testing on your end easier, you can also get your package json to point to either a local folder (where you have your dev copy of the package) or your git fork, example:
"ftx-api": "github:cwdx/ftx-api#master"
You can also do this via npm install, even for a folder: npm install ../path/to/ftx-api
In case it makes testing easier.
export type GenericAPIResponse = Promise<any>; | ||
export type GenericAPIResponse<T> = Promise<{ | ||
success: boolean; | ||
result: T; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, while definitely a nitpick I was planning on Promise<APIResponse<T>>
becoming the successor to GenericAPIResponse<T>
. I'm probably overthinking but I wanted it more obvious that all API calls return promises that contain API responses with T. GenericAPIResponse was just the very open placeholder until I had a chance to work on stronger types.
@@ -0,0 +1,3669 @@ | |||
# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been using npm for my connectors, please remove the yarn.lock
@@ -75,25 +153,25 @@ export class RestClient { | |||
* Misc possible undocumented endpoints - these may not always work | |||
**/ | |||
|
|||
getRebateHistory() { | |||
getRebateHistory(): GenericAPIResponse<unknown> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getRebateHistory(): GenericAPIResponse<unknown> { | |
getRebateHistory(): Promise<APIResponse<any>> { |
price: number; | ||
} | ||
|
||
export type HistoricalBalances = Array<HistoricalBalance> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above, would prefer if you just used HistoricalBalance[]
instead of creating a duplicate type
export type HistoricalBalances = Array<HistoricalBalance> |
type: "orders" | string; // other types undocumented | ||
} | ||
|
||
export type Fills = Fill[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same again, and anywhere else with a "plural" type. Just use Fill[]
directly where you have an array of the Fill type.
id: string; | ||
liquidity: "maker" | "taker"; | ||
market: string; | ||
baseCurrency?: string | null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen a few like this, just to check - are they really undefined or string or null? all 3 possibilities?
/** @description: USD volume in the last 24 hours */ | ||
volumeUsd24h: number; | ||
/** @description quantity traded in the last 24 hours */ | ||
volume: number; 24390.24 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
volume: number; 24390.24 | |
volume: number; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. This number was also showing up in IntelliSense results in VS Code.
type: FuturesCoinType | ||
} | ||
|
||
export type Futures = Array<FutureCoin>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export type Futures = Array<FutureCoin>; |
Just use FutureCoin[]
instead of creating Futures
to represent the array of future coin.
Done:
Fixes #75