Protobuf.js: Static code type wrappers

[adam-26]

Hi,

I am using static-code, and (for example) want to convert the google/protobuf/timestamp.proto type to a JavaScript Date when using the fromObject()/toObject() functions.

I see in the codebase the wrapper.js and common.js files that allow custom types to be added, but can't see that its possible to use with static-code. Am i missing something? If not, would you consider adding this as a new feature?

Thanks, Adam.

[adam-26]

Using the above commit, you can register custom type converters that are used when converting Objects <-> Messages using static code.

For example, you could register type converters for Timestamp, Duration, even custom types. An improved converter for enum types could be created to correctly map the enum as either a value or a string in both directions.

Here is a basic example of registering a type converter:

import root from "./bundle.js";

const numberTypeConverter = {
    getTypeName: function() {
        return 'Number';
    },

    getDefaultValue: function() {
        return 0;
    },

    fromObject: function(value) {
        return value;
    },

    toObject: function(value, options) {
        return value;
    }
};

root.objectMapper.registerConverter(numberTypeConverter);

Note that the commit above is only a prototype, it does generate code - but it does not currently support all data types. Check the commit comments for more information - including how to easily generate some test code.

The files of interest in the commit are:
cli/targets/converters/registered-type-converter.js
src/objectMapper.js
src/objectMappers/string.js

The implementation should reduce the code size of static output, similar behavior could be applied to other methods in static code to reduce static code size (_drastically i think_).

I haven't done any performance benchmarking, it would probably reduce the performance of static code, but that would likely be a very minimal performance hit.

Feedback is most welcome. Is anyone else interested in such a feature?

If this feature was more complete, would this be accepted as a PR? Any feedback on the API design?

[adam-26]

@dcodeIO, would be interested in feedback when you have time :)