fix: generate canonical JSON encoding for FieldMasks

[buyology]

Fixes/updates #497.

The canonical JSON encoding of FieldMasks is a comma-separated string of the FieldMask.paths-array. Generate that JSON mapping for FieldMask-fields.

In #497 @alexeyten suggested that

[…] probably in JS this should be represented as an array of string.

This change does not touch the representation of the FieldMask. I checked other generator libs, e.g. the Go generator, and it did not touch the representation of the FieldMask. It is probably also simpler not do so in order to get the correct wire-encoding "for free".

[stephenh]

This change does not touch the representation of the FieldMask.
I checked other generator libs, e.g. the Go generator, and it did
not touch the representation of the FieldMask. It is probably also
simpler not do so in order to get the correct wire-encoding "for free".

Cool, that makes sense. This looks great!

Fwiw I think ts-proto's "idiomatic TypeScript" mission statement would generally lean towards using the string[] representation directly in the message interfaces themselves as well, but it's also definitely np to defer that to a separate PR.

[stephenh]

🎉 This PR is included in version 1.105.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[boukeversteegh]

Awesome! I was just going to use field-masks but refrained after noticing this missing feature. Thanks 👍

For the typescript representation part, we could use the wrap/unwrap approach as we do for Wrapper types.
So it won't be necessary to re-implement the encoding/decoding.

Basically, the FieldMask representation would be kept as-is, but it will be responsible for the JSON coding.

The container messages will:

• generate json for a fieldmask field like this: FieldMask.ToJson(FieldMask.wrap(message.someFieldMask))
• and parse json like this: message.someFieldMask = FieldMask.unwrap(FieldMask.FromJson(obj.someFieldMask)).

That way we can keep a 'clean' FieldMask concept, which is a true representation of the Protobuf object, which gives the wire-format out of the box, while allowing for TS-friendly types within the container messages.

Additionally, the logic for the canonical json is isolated in separate methods.

Let me know if your thoughts and if you're interested in implementing this. Otherwise I might look into it if I have some time.

[boukeversteegh]

hi @buyology , I went ahead to add the above suggestions. Please have a look if this implementation works for you.

See #525