FieldMask#toJson() with camel case

[Daniel Shmuglin]

Why to fail like that?

For example writing to log file/console some message instance with nested FieldMask using JSON.stringify(...) sounds totally fine.

[Daniel Shmuglin]

could be related timostamm/protobuf-ts#396 (comment)

[Steve Ayers]

Can you provide an example as to what you see failing? Just so that we can confirm whether this is the same issue protobuf-ts has?

[Daniel Shmuglin]

I think it isn't related, indeed I'm sending camelCase paths.
And yet I think JSON.stringify() should not fail on nested FieldMask with camel case.
Maybe FieldMask class could override Message#toJSON and skip the casing validation, while retaining this validation in #toJson()? WDYT?

[Steve Ayers]

This is actually in accordance with the JSON encoding definition for FieldMask on protobuf.dev: https://protobuf.dev/reference/protobuf/google.protobuf/#json-encoding-field-masks. Protobuf-ES adheres to the canonical JSON representation defined by the Protobuf team.

We wouldn't want to override toJSON to accommodate JSON.stringify because by definition, the output of JSON.stringify is a string representation of a JSON object. It wouldn't make sense for this to be the case:

const fieldMask = new FieldMask({
    paths: ["user.display_name", "photo"],
});

fieldMask.toJson();    //  fails
fieldMask.toJsonString();  // fails
JSON.stringify(fieldMask);   // produces user.display_name,photo

Aside from the unpredictable behavior, our docs state that JSON.stringify is the equivalent of calling message.toJsonString({emitDefaultValues: true}) and this would violate that. This also means that the string in the third example does not survive a roundtrip, since both fromJsonString and fromJson would both fail trying to serialize it. We would then have to override that behavior for FieldMask also, adding more unpredictability and deviation from the spec.

Going to close this, but I appreciate the question. If there's something else you notice that is amiss, feel free to open a new issue.