Skip to content
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 primitives #120

Closed
rubennaatje opened this issue Aug 21, 2020 · 3 comments
Closed

Optional primitives #120

rubennaatje opened this issue Aug 21, 2020 · 3 comments

Comments

@rubennaatje
Copy link

Is there a way to make sure everything is optional?

We used to have our own interface generator from protos that did that but we're now opting for an open source one, that is the only issue however.

Reason is that we use an gRPC service that breaks when some values are used with some calls.

@stephenh
Copy link
Owner

@rubennaatje / cc @philikon since we was asking about something similar for arrays.

Yeah, we could extend the useOptionals to apply to everything.

I guess part of my curiosity is that I think this optionalness makes creation easier but hurts (imo) reading.

I.e. for a protobuf field like string name = 1, string desc = 2, then something like:

type FooMessage { name?: string; desc?: string }

Makes this snippet A easier because it can leave off name:

const foo: FooMessage = { desc: "foo" };

However, it means that snippet B becomes harder because it might be undefined:

const foo: FooMessage = { desc: "foo" };
const name = foo.name; // might be undefined

Which would be fine, however if we were to decode FooMessage off the wire, i.e.:

const foo: FooMessage = FooMessage.decode(...someBytes...);
const name = foo.name; // will be empty string

I.e. client code that reads .name now has to deal with the "empty scenario" as "well, it might undefined b/c we created it" or "well, it might be empty-space b/c it was decoded it".

Which, is not terrible, but is more idiosyncratic than I'd like.

Fwiw what FooMessage.decode is doing is basically:

const foo: FooMessage = { ...baseFoo, desc: "foo" };

I.e. it's bringing in the base options to that name will consistently be empty-space-if-not-set.

Also note that FooMessage.fromPartial({ desc: "foo" }); does the same ...baseFoo.

Well, all of this is me just rationalizing why I don't think I'd use the useOptionals flag, and instead use fromPartials for instantiation, but given that we do have the useOptionals flag, I'm good with it applying it to everything.

Reason is that we use an gRPC service that breaks when some values are used with some calls.

This is a little surprising to me, in theory with protobuf the gRPC service shouldn't be able to tell if the (primitive) field was either "not sent on the wire" or "sent on the wire as a default value"?

@rubennaatje
Copy link
Author

@stephenh thanks for the well explained answer. I get all your points.

And especially the last bit was interesting for me. I don't know why at some point we thought we needed all optionals but now I've completely replaced our stuff with yours. And it works fine :)

So thanks for your time and thanks for your work.

@stephenh
Copy link
Owner

@rubennaatje cool, thanks for the follow up. :-) Glad it worked out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants