Replies: 1 comment
-
I think the issue with this is that other protobuf implementations will not be able to parse the data anymore. Some of the well-known types have a specialized JSON mapping (for example google.protobuf.Duration), but it the mapping is actually well-defined too, and covered in the conformance tests. It would be really neat if there was a well-know type for UUIDs, or at least a google.type type, but it looks like google is using |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Perhaps this is a niche use-case, but there are several places where being able to customize the JSON input and/or outputs by MessageType would be helpful. One case that comes up quite frequently in my work is around GUIDs. Seeing as there is no standardized/scalar/wellknown
GUID
type we've come up with our own at work which is literally just:This saves a tremendous amount of size (on the wire) and CPU cycles during (de)serialization. We obviously have functions for converting between the
{ data: Uint8Array }
representation above andstring
, but the struggle is getting that conversion applied for every deeply nested instance of aGuid
message inside another message. Here's an example interceptor we use for debugging RPC:The problem (which may be obvious now) is that what we end up seeing in these debug messages is a lot of
When we'd prefer to see
We have written our own function that will attempt to recursively walk the result of a
MessageType.toJson(message)
using thatMessageType.fields
to replace all instances of thatGuid
proto message with what we want, but it's not generic and really only covers the cases we care about.What I'm wondering is if some kind of generic functionality similar to that would A) even be possible, B) be useful to others, and C) whether it would be something that might be added to the existing
MessageType.internalJsonRead/Write
functions. Even some guidance on how something like this could be made generic outside of the official protobuf-ts packages (but still using its interfaces) would be great as I'm not sure TBH. I'm imagining some kind of visitor pattern where the consumer can specify an array (or Map?) ofMessageTypes
and replacer functions in theJsonWriteOptions
andJsonReadOptions
and then any place where one of those MessageTypes existed in the message object would get replaced with the output of the replacer function. Thoughts?Beta Was this translation helpful? Give feedback.
All reactions