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

Typescript definitions for REST response #77

Draft
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

cwdx
Copy link

@cwdx cwdx commented May 12, 2022

Done:

  • Typescript definitions for REST endpoints

Fixes #75

Copy link

@nilswx nilswx left a 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",
Copy link

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.

Copy link
Owner

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",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 1.2.3?

Copy link
Owner

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;
Copy link

@nilswx nilswx May 26, 2022

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.

Copy link
Owner

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

Copy link
Owner

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.

Copy link

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;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be OrderSide.

Copy link
Owner

@tiagosiebler tiagosiebler left a 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.

Comment on lines +156 to +174
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> {
Copy link
Owner

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",
Copy link
Owner

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;
Copy link
Owner

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.
Copy link
Owner

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> {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
getRebateHistory(): GenericAPIResponse<unknown> {
getRebateHistory(): Promise<APIResponse<any>> {

price: number;
}

export type HistoricalBalances = Array<HistoricalBalance>
Copy link
Owner

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

Suggested change
export type HistoricalBalances = Array<HistoricalBalance>

type: "orders" | string; // other types undocumented
}

export type Fills = Fill[];
Copy link
Owner

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;
Copy link
Owner

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
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
volume: number; 24390.24
volume: number;

Copy link

@nilswx nilswx May 30, 2022

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>;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export type Futures = Array<FutureCoin>;

Just use FutureCoin[] instead of creating Futures to represent the array of future coin.

@tiagosiebler tiagosiebler marked this pull request as draft October 22, 2022 08:07
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

Successfully merging this pull request may close these issues.

Response types
3 participants