6 ms·
Anyone knows how does bigint serialization and deserialization to JSON look like in practice in Chrome and Firefox?
by warpech 7y ago
Anyone knows how does bigint serialization and deserialization to JSON look like in practice in Chrome and Firefox?
- wpq0 7y agoAfaict, JSON serialization is not supported yet, got a "TypeError: BigInt value can't be serialized in JSON". I'm on Firefox Developer edition 68.0b3.
- M2Ys4U 7y agoI suppose one could use a replacer[0] when calling JSON.stringify and a reviver[1] when calling JSON.parse [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#The_replacer_parameter https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse#Using_the_reviver_parameter https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- bpye 7y agoYou can certainly serialize to a string but knowing when you should revive to a BigInt seems tricky. You could prefix the strings I guess?
- tzs 7y agoHow about serializing to an array ["bigint", "170141183460469231731687303715884105727"]? It takes more space, but is easy to recognize, and easy to generalize to other types.
- jfk13 7y agoPresumably that could be confusing if you ever happen to have an actual array whose first element is the string "bigint".
- hombre_fatal 7y agoWell, no matter what you do, surely you plan on documenting your API to such a bare bones level that your user isn't racking their brain whether a key is a number or an array of data.
- repsilat 7y agoNah, you just have to also encode all arrays like ["array", [...]] ;-)
- derfniw 7y agoReuse the literal? (postfix with 'n')
- bufferoverflow 7y agoYou don't want strings that are "digits..n" to automatically deserialize into bigints. What if you have a string like "8n", which is a tractor model, or "9n", which is a smartphone model? But it would be nice to have literal 8n to convert to a bigint 8n. That's not in the JSON standard though.
- M2Ys4U 7y agoTrue, but if you control both the serialisation and deserialisation you can get away with it
- mcaruso 7y agoJSON serialization does not seem to be supported yet. `JSON.serialize(42n)` gives me a TypeError "Do not know how to serialize a BigInt" in Chrome. Deserialization support also doesn't exist as far as I'm aware. Would be great to be able to choose to decode integer JSON literals as BigInt, but I'm not holding my breath.
- darknoon 7y agoYou could decode all of them as BigInt, but then you would be accepting a large overhead for the much greater number of constants like 1 or 42 where it's unnecessary. Everywhere you pass that JSON data would need to be updated to operate in terms of BigInt instead of number. If you only decoded big ones as BigInt, you would have the same problem of updating the code but now you have 2 codepaths at every callsite! It's perhaps a defect in the JSON spec that it doesn't have a provision to support BigInt, but it's not really clear what should happen!
- ratel 7y agoYou need some way of serialization that makes clear it was serialized as a BigInt and thus must be de serialized as a BigInt without the likelihood of it misinterpreting the data like 9n being a tractor model. A single indicator would be too error prone, so the schema has to be more complex. With that complexity it needs to perform and be (cheaply) verifiable. Quickest thing I can think of is storing it as power of 2 + the difference ending with character n as good measure. It is easy to serialize/de-serialize and you can verify the number by re-serializing to be a proper BigInt and not for instance a String. Confusion still would be possible, but rare. So 1 would be stored as 0+1n, 42 would be stored as 5+10n, etc.
- deleted 7y ago[deleted]
- callahad 7y agoYou can define a toJSON property on the BigInt prototype that gets used for serialization: Object.defineProperty(BigInt.prototype, "toJSON", { get() { "use strict"; return () => String(this); } }); Of course you could also serialize to a Number, but that risks losing precision. For example, the Twitter API often returns IDs as both a Number ("id") and a String ("id_str") to safely handle cases where the value might fall outside of a normal double-precision float: https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/intro-to-tweet-json.html https://developer.twitter.com/en/docs/tweets/data-dictionary...
- Spivak 7y agoI'm sure its for backwards compatibility but hot damn is that one hell of a footgun. Even with that in place would you ever feel confident returning an id that didn't fit in a double knowing the sheer amount of code that definitely didn't handle that case?
- callahad 7y agoOnly Strings are safe, forty years past K&R. Wish I knew Tcl.