-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
optional fields return zero value (empty string) instead of null #728
Comments
If not set, it returns the default value of the field and the default value of an unset string field is an empty string as of the official spec. More precisely, the value you see there comes from |
The spec says that you should be able to distinguish between an empty value
and an unset value.
…On Mar 25, 2017 15:17, "Daniel Wirtz" ***@***.***> wrote:
If not set, it returns the default value of the field and the default
value of an unset string field is an empty string as of the official spec.
More precisely, the value you see there comes from
protos.cockroach.build.Info.prototype.go_version
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#728 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPESOkTTyzVuWyBGV2BRrmJLCgmI_ks5rpWhHgaJpZM4MpI3d>
.
|
You can by using |
Yikes, that's an unfortunate API. Still, the type definitions should
reflect that the value is non-null.
…On Mar 25, 2017 15:42, "Daniel Wirtz" ***@***.***> wrote:
You can by using r.hasOwnProperty("go_version")
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#728 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPPaI9Xj4ebSmQN0u-Nzr1Ep0Wqz1ks5rpW4QgaJpZM4MpI3d>
.
|
The type definition just says it is I know that the API isn't perfect, but I don't see another way in JS (without introducing something not really performant like hidden properties through getters/setters for everything and such). Edit: Sorry, accidentally closed the issue. |
Why can't you make unset properties return null?
…On Mar 25, 2017 15:47, "Daniel Wirtz" ***@***.***> wrote:
Reopened #728 <#728>.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#728 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPIGfnaiDCVkJ0fXPCE6TkLACcYr-ks5rpW82gaJpZM4MpI3d>
.
|
Using |
Can you link to some of those discussions?
…On Mar 25, 2017 15:56, "Daniel Wirtz" ***@***.***> wrote:
Using null for everything was something frequently discussed in v5. This
ultimately lead to the behavior we have today.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#728 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPH3KHBDH2OghbVLdmYrEEhsb08qhks5rpXFPgaJpZM4MpI3d>
.
|
#380 (including related) for example. What could be done, though, is to wrap all of this in an utility method for convenience. Like: function isset(obj, prop) {
var value = obj[prop];
if (value != null && obj.hasOwnProperty(prop))
return typeof value !== 'object' || (Array.isArray(value) ? value.length : Object.keys(value).length) > 0;
return false;
} |
Closing this issue for now as it hasn't received any replies recently. Feel free to reopen it if necessary! |
I had some tough time with this. Assume the protobuf def
const message = MyMessage.decodeDelimited(bytes)
const messageJson = MyMessage.toObject(message)
// {foo: 1}
console.log(message.a)
// {foo: 1}
console.log(messageJson.a)
// 0
console.log(message.a.bar)
// undefined
console.log(messageJson.a.bar) If you forget to use |
Hello, I don't know if it's a good solution, but I changed this behaviour by adding one-liner to our project: import { Field } from 'protobufjs';
Object.defineProperty(Field.prototype, 'typeDefault', { get: () => null, set: () => null }); It works just like I want now. |
Given the definition:
The generated message behaves incorrectly:
This should return null, not empty string. Note that in protobuf 3 it should return empty string, since primitives are non-nullable in protobuf 3.
The typescript definitions are also incorrect with respect to the nullability of these attributes.
The text was updated successfully, but these errors were encountered: