Make Message.prototype.toObject({defaults: true}) use undefined instead of null?

[fnlctrl]

protobuf.js version: 6.5.0

I'm trying to send an object that's converted from a message (via toObject({defaults: true})) back to server, but I got something like:

Uncaught TypeError: Cannot read property 'freq' of null

The messages looks like

message Foo {
   Bar bar = 1;  // sometimes not provided by server
}
message Bar {
  string freq = 1;
}

and the js

// bar is not provided by server
var foo = Foo.decode(...).toObejct({defaults: true})   // {bar: null}

....some time later

var message = Foo.encode(foo)  // Uncaught TypeError: Cannot read property 'freq' of null

It was working perfectly fine before 6.5.0. Seems to be caused by the generated code only checking for undefined but not null.

So maybe we can make toObject use undefined instead of null? Or let the generated code check for both null and undefined?

[dcodeIO]

Have you tried with 6.6.1 already?

[fnlctrl]

No.. didn't find relevant info in the release notes, so I thought it wasn't fixed. I'll try asap, thanks!

[dcodeIO]

Might not be fixed in 6.6.1, just asking. Feel free to reopen if it's still an issue!

[fnlctrl]

Just got time to test it, and sadly it wasn't fixed in 6.6.1. It seems 2b12fb7 took care of it, when would it be released?

Also, 6.6.1 seems to be forcing Long.js for me when using the light build (with webpack setup)..
So I came up with this workaround (copying most of the lines from index-light)

import Service from 'protobufjs/src/service';
import Type from 'protobufjs/src/type';
import Namespace from 'protobufjs/src/namespace';
import ReflectionObject from 'protobufjs/src/object';
import Root from 'protobufjs/src/root';
import BufferReader from 'protobufjs/src/reader_buffer';
import Reader from 'protobufjs/src/reader';
Reader._configure(BufferReader);
Namespace._configure(Type, Service);
ReflectionObject._configure(Root);
Namespace._configure(Type, Service);
Root._configure(Type);


// finally
var root = Root.fromJSON(json);
var service = Root.lookup('......');

Should I open a separate issue?

[dcodeIO]

It seems 2b12fb7 took care of it, when would it be released?

Probably soon™.

6.6.1 seems to be forcing Long.js for me when using the light build (with webpack setup)..

Hmm, that shouldn't happen. There shouldn't be a place anymore where long.js is required explicitly. Instead, it's loaded dynamically. Any ideas?

[fnlctrl]

Webpack's analysis tool shows Long is required by index-minimal (The red dot 135 in the picture).

Cause:
https://github.com/dcodeIO/protobuf.js/blob/master/src/index-minimal.js#L48-L58
Seems it's not being inquired

[dcodeIO]

Ah, right, the AMD loader. Hrm...

[fnlctrl]

Why was Long.js required by default in index-minimal though? I though it was optional and easy-opt-in with protobuf.util.Long = Long

[dcodeIO]

Well, it IS meant to be optional. With the inquire thing in place, browserify does not include long by default because it doesn't evaluate AMD loaders at all. That's how it is intended.

Webpack, on the other hand, evaluates the AMD loader shim (in full, light and minimal alike), even though a loader like require.js wouldn't throw if long isn't actually present. You could still exclude it from your project through respective webpack config stuff, or wait until I move the AMD shim out of source to the dist wrapper, which I haven't done yet because browserify doesn't offer a way to specify a custom prelude.

[fnlctrl]

Well, I though if it's optional then it may be all right to just not include it at all, and put a notice in the docs about using Long (should be as easy as adding protobuf.util.Long = require('long') after var require('protobuf') if i'm not mistaken?)

[dcodeIO]

It's not that easy actually because there is some reconfiguration taking place when Long is installed (perf reasons).

[fnlctrl]

Ah, right... missed that part. Maybe Reader can expose a method to use Long explicitly then? Something like protobuf.Reader.useLong(require('long')) where useLong takes care of the reconfiguration?

[dcodeIO]

I just figured out how to use a custom browserify prelude. Once that's in place, we can remove the define call from source. useLong is a good idea, too, just want to make sure that this happens automatically with AMD.

[dcodeIO]

For reference: prelude

As you see there, long.js can also be installed manually through assigning it first and then calling protobuf.configure().

[dcodeIO]

Feel free to reopen if there are still any issues!