4 ms·
I hate this so much because you can’t nicely serialise a BigInt as JSON. Using a string is nicer but it only makes sense where int64 is used as an ID, not wher
by mort96 5mo ago
I hate this so much because you can’t nicely serialise a BigInt as JSON. Using a string is nicer but it
only makes sense where int64 is used as an ID, not where it’s used as a number; and you don’t wanna have to configure this per field per query.
- nh2 5mo agoJSON has arbitrary length numbers in the spec only.
- mort96 5mo agoCompletely and utterly irrelevant.
- sheept 5mo agoYou can serialize a BigInt by specifying a replacer: const obj = { a: 9007199254740993n } JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)
- mort96 5mo agoAnd then you end up with strings on the other side, not numbers.
- sheept 5mo agoNo you don't? The example I gave produces {"a":9007199254740993} not {"a":"9007199254740993"}
- mort96 5mo agoOh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.
- sheept 5mo agoIf you're applying a replacer, then you'd supply a reviver when parsing: const json = '{ "a": 9007199254740993 }' JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)
- mort96 5mo agoYeah but now you have the world's biggest foot gun in your API.
- marcosdumay 5mo agoIMO, I'm tending toward thinking that having types on your readable serialization format is a mistake, and that they should be always input to the (de)serializer instead.