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.
replyIMO, 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.
replyYou can serialize a BigInt by specifying a replacer:
reply const obj = { a: 9007199254740993n }
JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)And then you end up with strings on the other side, not numbers.
replyNo you don't? The example I gave produces
reply {"a":9007199254740993}
{"a":"9007199254740993"}Oh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.
replyIf you're applying a replacer, then you'd supply a reviver when parsing:
reply const json = '{ "a": 9007199254740993 }'
JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)Yeah but now you have the world's biggest foot gun in your API.
replyJSON has arbitrary length numbers in the spec only.
replyCompletely and utterly irrelevant.
reply