Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -58,17 +58,18 @@ export default async function parseResponse<T extends ParseMethod = 'json'>(
const result: JsonResponse = {
response,
json: cloneDeepWith(json, (value: any) => {
// `json-bigint` could not handle floats well, see sidorares/json-bigint#62
// TODO: clean up after json-bigint>1.0.1 is released
if (value?.isInteger?.() === false) {
return Number(value);
}
if (
value?.isGreaterThan?.(Number.MAX_SAFE_INTEGER) ||
value?.isLessThan?.(Number.MIN_SAFE_INTEGER)
value?.isInteger?.() === true &&
(value?.isGreaterThan?.(Number.MAX_SAFE_INTEGER) ||
value?.isLessThan?.(Number.MIN_SAFE_INTEGER))
) {
return BigInt(value);
}
// // `json-bigint` could not handle floats well, see sidorares/json-bigint#62
// // TODO: clean up after json-bigint>1.0.1 is released
if (value?.isNaN?.() === false) {
Copy link
Member

Choose a reason for hiding this comment

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

@justinpark Won't decimal numbers be truncated in case they are passed to the native Javascript BigInt object? This can happen when value?.isGreaterThan?.(Number.MAX_SAFE_INTEGER) || value?.isLessThan?.(Number.MIN_SAFE_INTEGER). In other words, do we need to include a check for type integer?

if (
   value?.isInteger?.()  <-- check for integer
   value?.isGreaterThan?.(Number.MAX_SAFE_INTEGER) ||
   value?.isLessThan?.(Number.MIN_SAFE_INTEGER)
) {
   return BigInt(value);
}

Also, if that's the case, don't we also need to handle large decimals given that toNumber will truncate?

Copy link
Member Author

Choose a reason for hiding this comment

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

Adding an integer check to BigInt is a good idea. I have added that part.

I think the truncation of large decimals is a trade-off. For example, when a value used as bigint is truncated, it affects the accuracy of the information related to the ID, so it is appropriate to keep all decimals by bigint format. However, in the case of large decimal floating numbers, since the values are within a range that allows arithmetic operations, I believe it is a part that can be compromised to support operations in such cases, even if some decimal can be truncated.

return value?.toNumber?.();
}
return undefined;
}),
};
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -143,7 +143,7 @@ describe('parseResponse()', () => {
const mockBigIntUrl = '/mock/get/bigInt';
const mockGetBigIntPayload = `{
"value": 9223372036854775807, "minus": { "value": -483729382918228373892, "str": "something" },
"number": 1234, "floatValue": { "plus": 0.3452211361231223, "minus": -0.3452211361231223 },
"number": 1234, "floatValue": { "plus": 0.3452211361231223, "minus": -0.3452211361231223, "even": 1234567890123456.0000000 },
"string.constructor": "data.constructor",
"constructor": "constructor"
}`;
Expand All @@ -161,6 +161,7 @@ describe('parseResponse()', () => {
expect(responseBigNumber.json.floatValue.minus).toEqual(
-0.3452211361231223,
);
expect(responseBigNumber.json.floatValue.even).toEqual(1234567890123456);
expect(
responseBigNumber.json.floatValue.plus +
responseBigNumber.json.floatValue.minus,
Expand Down
Loading