Skip to content

Conversation

@live-wire
Copy link

@live-wire live-wire commented Jul 8, 2022

BigInts in request and response are silently modified. This PR adds support for bigints

Description

Uses this library to support bigInts.

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Checklist

My PR contains...

  • No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
  • Dependency changes (any modification to dependencies in package.json)
  • Bug fixes (non-breaking change which fixes an issue)
  • Improvements (misc. changes to existing features)
  • Features (non-breaking change which adds functionality)

My changes...

  • are breaking changes to a public API (config options, System API, major UI change, etc).
  • are breaking changes to a private API (Redux, component props, utility functions, etc.).
  • are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
  • are not breaking changes.

Documentation

  • My changes do not require a change to the project documentation.
  • My changes require a change to the project documentation.
  • If yes to above: I have updated the documentation accordingly.

Automated tests

  • My changes can not or do not need to be tested.
  • My changes can and should be tested by unit and/or integration tests.
  • If yes to above: I have added tests to cover my changes.
  • If yes to above: I have taken care to cover edge cases in my tests.
  • All new and existing tests passed.

@tim-lai
Copy link
Contributor

tim-lai commented Jul 18, 2022

@live-wire Thanks for the PR. However, as noted here and here,

On the subject of BigInt, JSON specification, section 6 (Numbers) is quite clear about supported number ranges. Going beyond them creates issues of correctly interpreting numbers.

In addition, exposing integers via API in JSON format that may be really big is not a good idea. One can accidentally generate a number that is outside of the range, and different platforms consuming the JSON will interpret the number differently. Even JSON:API has a convention of sending numbers as strings to avoid that problem.

Some time ago JavaScript landed a new type BigInt that can support ranges outside of 253 - 1. Unfortunately this type is not JSON serializable and the only recommended way of transferring it via JSON is: transfer it as a string. That way, every platform can deal with it as it likes.

As such, we're unable to accept this PR. Thanks again for your time and contribution.

@tim-lai tim-lai closed this Jul 18, 2022
@live-wire
Copy link
Author

The change I made will soon be a part of JSON.parse(.... See this.
I like the solution of treating big integers as strings, however, the big integers are currently being silently modified to wrong values. That is not a great user experience in my opinion.

@ttyniwa
Copy link

ttyniwa commented Sep 17, 2022

Unfortunately this type is not JSON serializable and the only recommended way of transferring it via JSON is: transfer it as a string.

I think this is the right decision for the particular project using JSON.
(In paticular, we should make that choice if we have an unspecified number of JavaScript client.)

But, i agree to @live-wire .
Since swagger specification defines int64, swagger-ui should be able to handle int64 correctly.
https://swagger.io/docs/specification/data-models/data-types/

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.

3 participants