Automatically wrapping & unwrapping wrappers.proto types?

[RodH257]

protobuf.js version: 6.6.3

Hey, first off this library is really great - love the typescript integration! Thanks for building it.

I'm trying to work out how to retain 'null' values across the wire. We have some instances where a value can be null and it means something different to empty string or 0 value. Google has the wrappers https://github.com/google/protobuf/blob/master/src/google/protobuf/wrappers.proto that let you do this, and protobuf.js handles retaining the null well, however it doesn't automatically wrap and unwrap the values

Lets say I have

message ChangeEvent {
  string source = 1;
  google.protobuf.StringValue code = 2;
}

I'd like to be able to pass in:

const changeEventWithCode = {
  source = 'test',
  code = 'code',
}

const changeEventWithoutCode = {
  source = 'test',
  code = null,
}

and have them both encode & decode to the same thing. However it seems if I want to set the code string, I have to do:

const changeEventWithCode = {
  source = 'test',
  code = {
    value: 'code',
  },
}

I was hoping fromObject and toObject would handle this, but they don't - is there any way I can hook in some customisation to do this, or would this be a good feature to add to the framework?

[dcodeIO]

There is no special handling for Wrappers, Any, Duration, Timestamp etc. currently.

What could be done, though, is to set up custom classes for these types that are capable of handling these cases. Haven't thought this through, yet, unfortunately.

[RodH257]

I was thinking along those lines as well, I was having a bit of difficulty working out how to get the custom classes injected in when using codegen, but I'll have another crack

[dcodeIO]

This adds (hidden) options to specify custom implementations of fromObject and toObject. Basically, when there is an option __fromObject, it is used instead of the generated converter with this.fromObject referencing the original function. Likewise, a __toObject option does the same but for toObject.

There is a commented out example here: 0c6e639#diff-2c36c683dff5798fefed561dbec17803R54

Additional functionality can now be implemented right within src/common.js where these types are provided.

[dcodeIO]

Has it's own module now.

Adding wrappers to the module translates to reflection. Static code integration is still todo, but possible.

[dcodeIO]

If anyone is interested in tackling other common types, feel free to send a PR! Otherwise, if there is a need for a specific type, but a PR is out of reach, feel free to leave a comment.

[alexleigh]

I'm having trouble writing wrappers to support google/protobuf/wrappers types. Suppose I have a message like the following:

message HasStringValue {
  google.protobuf.StringValue string_value = 1;
}

And I try to call HasStringValue.fromObject with an object like the following:

{
  stringValue: "hello world"
}

The desired result is that the string in this object gets turned into a StringValue message. However, this method results in the following error:

TypeError: .HasStringValue.stringValue: object expected

I tried to override this behavior both by providing a wrapper for .google.protobuf.StringValue and also by writing a custom constructor for .google.protobuf.StringValue. But neither my wrapper's fromObject nor my custom constructor gets invoked. It seems the error is thrown when building the outer HasStringValue message, and so the custom building logic for StringValue is never reached. Could I do something different to get protobuf wrappers to work?

[kurayama]

This error comes from https://github.com/dcodeIO/protobuf.js/blob/master/src/converter.js#L36 which gets thrown before fromObject even has a chance to be called.

@dcodeIO Is there any way around this? Couldn't a preprocess step be called before this step? Or rename fromObject/toObject to serialize/deserialize and assume the argument could be anything.

[7chenko]

Any word on a solution for well-known types support in static code generation? I'm using protobufjs to read/write JSON that is generated by C# Protobuf code, which produces canonical JSON for well-known types throughout. I am forced to write brittle hardcoded preprocessing before every fromObject and toJSON calls to wrap/unwrap the values.