ts-proto: Repeated fields can be undefined
It appears that a repeated field like this one:
repeated Document documents = 2;
Simply gives this as output:
documents: Document[];
But, if you use the standard NodeJS protobufjs serialization without adding defaults: true a deserialized message won’t actually contain a documents field.
So it seems more appropriate to output:
documents: Document[] | undefined;
Or even:
documents?: Document[];
Of course, it’s always possible to add an option to turn this on or off using a setting similar to --ts_proto_opt=stringEnums=true (which BTW does nicely fit the the enums: String override on the protobufjs (de)serializer).
I could help on a PR for this, but first wanted to check what the preferred solution could be.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (12 by maintainers)
Commits related to this issue
- chore(sdk): move more state to new state format (#225) — committed to sentioxyz/ts-proto by zfy0701 2 years ago
Message received and understood, I’ll pick it up… 🙂
Hey @mharsat , thanks for the report! I was worried about this, per discussion above, i.e. you’re right, this is “not proto3” behavior.
I was hoping that existing users of
useOptionalwould be fine with this, but I guess you’re right thatuseOptionalsas it was before this PR was only a type-system change and not a decoding behavior change, which is what this PR turned it into…I’ll revert and push out a new version.
I like your description of
forceOptionalRepeated… I kinda wonder if something likedontApplyDefaultsor evenmatchJsonOffTheWirewould be more higher-level/use-case-driven names given that afaiu that is what @dot-i is looking to achieve.