You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many of our protobuf objects end up being eventually serialized as JSON. Currently, message fields have default values of null, which gets serialized into the result.
This is problematic because most specs for defining schema in JSON (e.g., swagger) define optional fields as being omitted from the result. This forces the need to prune null values before serialization in order to adhere to spec.
What are your thoughts on changing the default value of these types to undefined? What about a compile time option for deciding?
pbf --default-defined ./thing.proto
The text was updated successfully, but these errors were encountered:
@kjvalencik how much of a perf hit would it be to roll-back our optimization of predefined properties? The issue with just using undefined is that properties would still be enumerable, so e.g. if a consumer does for (const key in obj), it would go over the undefined properties. Maybe we should just accept the perf hit and strive for maximum compatibility here.
That's an interesting thought and worth benchmarking. I don't think it would be substantial for small messages, but ones with many keys would go through a lot of hidden class transitions.
Many of our protobuf objects end up being eventually serialized as JSON. Currently, message fields have default values of
null
, which gets serialized into the result.This is problematic because most specs for defining schema in JSON (e.g., swagger) define optional fields as being omitted from the result. This forces the need to prune
null
values before serialization in order to adhere to spec.What are your thoughts on changing the default value of these types to
undefined
? What about a compile time option for deciding?The text was updated successfully, but these errors were encountered: