-
-
Notifications
You must be signed in to change notification settings - Fork 268
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
Conditional numberInString. Allow passing number | string
to order endpoints
#226
Comments
JS can be quite bad at precise math, as you also noticed here. Even when trimming and rounding to try and work around this, you're likely to see this happen again and cause other problems in your workflows. If you're dealing with sensitive math (such as order amounts, values, prices, anything money related), I really recommend using a decimal library such as big.js or decimal.js for any calculations that require precision. Once your calculations are done you can still extract a number (or a string if you prefer) from this special type. |
That part is sorted out. My suggestion is just to change the typings to allow strings, so people don't need to use hacks like this to circumvent the requirement for some values to be numbers: {
quoteOrderQty: amount.toFixed(4) as unknown as number
} |
If the API accepts strings for these fields (even the docs say numbers only), I'm absolutely open to that. It was also suggested here - just need to update the type to accept |
numberInString
to order endpointsnumber | string
to order endpoints
Before using your library, I was passing everything as strings because the request is made using form data and every param is sent as string anyways (as opposed to JSON, that has bools, numbers, null etc). I'd love to be able to change that but I can't make the tests pass as is in my environment. Are there any documentation on that? |
That's a good point!
The tests take API credentials for the private portion. I have a sub-account dedicated to these tests, although I did notice the API key expired (since it doesn't have IP whitelisting enabled), so I'm fixing that shortly. What're your tests failing with? Missing credentials? If you're in a unix or macOS shell, you can just pass API credentials using env vars as such: API_KEY_COM="yourapikeyhere" API_SECRET_COM="yourapisecrethere" npm run test:watch That's how I normally do full test runs locally and that's how the CI run executes these tests too. |
(just as a clarification about my suggested type: I suggested |
Also a good point. I'm undecided about using it in a request scenario where either of the two types is OK...because it's currently used for responses, but only responses with the beautifier enabled will always return a number for this field, or if the beautifier is disabled they will always return a number in a string. I had hoped to eventually improve how types resolve so that typescript knows "this client was instanced with the beautifier enabled, so all |
I don't know enough about TS to help you with that right now, but I think it would be a fun subject to study! :) I'll let you know as soon as I have a working example. |
That would be extremely helpful! I'm also very curious how one might resolve that. It would be easy if the boolean controlling the beautifier were included in a function call (although that would be an ugly design choice too in my opinion), but right now any API call would somehow need to know that this part is going via the beautifier so any Maybe passing in a generic Tricky but interesting challenge. Open to design changes too if it makes it easier to solve, within reason. |
Good new is that it seems possible with conditional types: |
I thought it might be in that direction, good stuff, though I still wonder how the implementation might look on something like the rest clients...does each method need a pass-through generic in the return value? |
The type of the client can be inferred by the values in the constructor like this: (hover the |
Ah that is quite nice, all that's left then is passing in the generic to the type return by each method. Nice! Edit: that's also a good reason to use |
number | string
to order endpointsnumber | string
to order endpoints
Currently, the values in
NewSpotOrderParams
only accept numbers. Since all numbers in JS are floats, this leads to some numbers having recurring decimals when converting to base 10, tripping the filter "Precision is over the maximum defined for this asset." even after normalizing the number (withMath.floor(qty / precision) * precision
).Allowing passing
numberInString
or simplystring
(asnumberInString | number
) would allow the user to trim the passed value withNumber.toFixed
.eg:
The text was updated successfully, but these errors were encountered: