-
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
Documentation for load, loadsync does not correspond with implementation and examples #608
Comments
When first implemented, When I think about it, now that IE8 support has been dropped and alternative getter/setter functions are a thing of the past, it's actually not necessary anymore to mark this as not recommended. Will take a look! |
You can now set the protobuf.parse.defaults.keepCase = true; This affects all load/loadSync functions where/when no ParseOptions are specified. These fall back to use Note that protobuf.load/loadSync are convenience functions, so I'd like to keep them rather simple. |
…defaults holding all possible defaults, see #608
Changed this to fall back to |
Alright, thanks a lot for the fast response! |
Closing this for now as 6.4.0, which is now released, should solve the issue. Feel free to reopen the issue if necessary. |
protobuf.js version: 6.3.1
Going by the API doc, the only load functions available are
Root.load
andRoot.loadSync
, who take filename, options and callback as arguments, with options being aParseOptions
object (permitting for example to specify you don't want camelCase conversion). Going by the example and these docs, I expected to be able to do the following:However, when passing an options object, a stacktrace is generated implying that the options object is taken as a
Root
object on which load is invoked...Stack trace:
When going through the source, I saw that
index.js
exports itself undocumentedload
andloadSync
functions, who take a different set of parameters, namelyfilename
,root
andcallback
. These functions check if a root parameter is present and if so invokeload
/loadSync
on this object, with the givenfilename
andcallback
as arguments. If no root argument is given, a newRoot
object is generated andload
/loadSync
are called on this new object. This leads to the terribly confusing situation where, if you don't want to specify options, you can just follow the example using the exported functions, however, when you want to specify options, you need to first create aRoot
object yourself and use this object instead (thus effectively re-implementing the exportedload
/loadSync
functions, but this time taking into account the options.Is this intended behavior of the library? If so, it might be necessary to perhaps modify the docs to make this distinction clear..
The text was updated successfully, but these errors were encountered: