Making options argument optional per docs #764
Conversation
If options are not passed to the access-token.findForRequest() function, then the callback argument will be undefined. This makes the options truly optional as the docs prescribe.
|
Can one of the admins verify this patch? To accept patch and trigger a build add comment ".ok\W+to\W+test." |
There was a problem hiding this comment.
IIRC calling Array.prototype.slice on arguments incurs performance penalty.
This is the usual way of handling optional args:
if (cb === undefined && typeof options === 'function') {
cb = options;
options = {};
}There was a problem hiding this comment.
@bajtos I agree that the structure you suggest is very common, and in fact is the way that I initially implemented it! But then I thought it would be good to search through the existing LoobBack code, and this is the structure that is used throughout the existing codebase - so this is what I submitted.
But this is a case of following convention - that is, I agree that the way you suggest would be faster, and is easier to read. Any idea of the benefit of the "loopback way"?
There was a problem hiding this comment.
Any idea of the benefit of the "loopback way"?
I am not sure as I don't use it. I suppose it supports arbitrary number of optional arguments before the last callback arg. I.e. the following call will work correctly too:
AccessToken.findForRequest(req, options, 1, 2, 3, callbackFn);|
@slnode ok to test |
|
@mikehedman thank you for the pull request, please address my comment above. Can you also add a unit-test to verify the implementation and prevent regressions in the future? |
|
And yes, I'll work up some testing as well. |
|
I noticed the patch is reverting some of the changes made on the master branch. If you want to bring your feature branch up-to-date with the upstream master, use In this case, I'd suggest you to remove the two merge commits first, before starting any new work: |
|
Folks, I spent quite some time looking at the existing unit tests, and the function I changed (and its dependencies), and I'm just not currently qualified to write an effective test for this change. I just don't know enough about how LoopBack's internals work. I'll get there someday, but I'm not there now. So either we can go forward with this PR as it stands now, someone else can add the testing, or we can table the PR, and I'll try to return to it when I'm better equipped to write the tests. Sorry about that, Mike. |
|
@bajtos - I've reverted the merges as you suggested. I'll work on being more attentive to the git parts. Thanks for your help. |
|
@mikehedman I'll take a look and either advise you how to write the unit test or submit the patch myself. |
|
Closing in favour of #813 |
If options are not passed to the access-token.findForRequest() function, then the callback argument will be undefined. This makes the options truly optional as the docs prescribe.