You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The @grpc/proto-loader library (documentation) supports a oneofs config option which adds some additional information to a deserialized message to identify which field in a oneof (if any) the user specified. My team makes heavy use of this feature, so not having that information in our typedefs is a bit of a hinderance to us switching over to ts-proto.
Proposal
Introduce a new oneof=virtual_properties option which would behave the same as the existing properties option but add in the proto-loader "virtual" property as described below.
deserializing a message with the email field specified results in the following object. Note the contact field which proto-loader populates to let you know which field in the oneof the user actually provided:
even better would be to use a discriminating union similar to the oneof=union option but that might be a good amount of work. If people agree with this as a proposal I'd be happy to take a stab at it
The text was updated successfully, but these errors were encountered:
The
@grpc/proto-loader
library (documentation) supports aoneofs
config option which adds some additional information to a deserialized message to identify which field in a oneof (if any) the user specified. My team makes heavy use of this feature, so not having that information in our typedefs is a bit of a hinderance to us switching over tots-proto
.Proposal
Introduce a new
oneof=virtual_properties
option which would behave the same as the existingproperties
option but add in the proto-loader "virtual" property as described below.Example
Given the following proto message definition:
deserializing a message with the
email
field specified results in the following object. Note thecontact
field which proto-loader populates to let you know which field in the oneof the user actually provided:specifying this in the interface generated by
ts-proto
could look like the following:even better would be to use a discriminating union similar to the
oneof=union
option but that might be a good amount of work. If people agree with this as a proposal I'd be happy to take a stab at itThe text was updated successfully, but these errors were encountered: