-
Notifications
You must be signed in to change notification settings - Fork 632
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
Es6 style promises #531
Es6 style promises #531
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -222,24 +222,27 @@ | |
*/ | ||
_routerMethodOnAuthPromise: function(rejectIfAuthDataIsNull) { | ||
var ref = this._ref; | ||
var deferred = this._q.defer(); | ||
|
||
function callback(authData) { | ||
if (authData !== null) { | ||
deferred.resolve(authData); | ||
} else if (rejectIfAuthDataIsNull) { | ||
deferred.reject("AUTH_REQUIRED"); | ||
} else { | ||
deferred.resolve(null); | ||
return this._utils.promise(function(resolve,reject){ | ||
function callback(authData) { | ||
// Turn off this onAuth() callback since we just needed to get the authentication data once. | ||
ref.offAuth(callback); | ||
|
||
if (authData !== null) { | ||
resolve(authData); | ||
return; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmmm, not quite what I was envisioning. I'd just do There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you might be conflating these methods with See the $q constructor documentation, they aren't returning there at all. I would think it's bad practice to return the result of a function whose return value is NOT(edit) guaranteed by documentation / specification (they may be leaving it's return value unspecified intentionally to allow for future changes). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ahh okay, okay, I definitely mis-spoke there and you are correct about the return value/chaining thing. I still prefer stylistically to have the |
||
} | ||
else if (rejectIfAuthDataIsNull) { | ||
reject("AUTH_REQUIRED"); | ||
return; | ||
} | ||
else { | ||
resolve(null); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This guys is still missing a |
||
} | ||
} | ||
|
||
// Turn off this onAuth() callback since we just needed to get the authentication data once. | ||
ref.offAuth(callback); | ||
} | ||
|
||
ref.onAuth(callback); | ||
|
||
return deferred.promise; | ||
ref.onAuth(callback); | ||
}); | ||
}, | ||
|
||
/** | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -128,16 +128,18 @@ | |
} | ||
applyLocally = !!applyLocally; | ||
|
||
var def = $firebaseUtils.defer(); | ||
ref.transaction(valueFn, function(err, committed, snap) { | ||
if( err ) { | ||
def.reject(err); | ||
} | ||
else { | ||
def.resolve(committed? snap : null); | ||
} | ||
}, applyLocally); | ||
return def.promise; | ||
return new $firebaseUtils.promise(function(resolve,reject){ | ||
ref.transaction(valueFn, function(err, committed, snap) { | ||
if( err ) { | ||
reject(err); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please just put them on the same line. Thanks! |
||
return; | ||
} | ||
else { | ||
resolve(committed? snap : null); | ||
return; | ||
} | ||
}, applyLocally); | ||
}); | ||
}, | ||
|
||
$asObject: function () { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have found it to be good practice to add a
return
statement before every call toresolve()
orreject()
to make sure no code gets run after them. I've had too many bugs where I didn't do this and they are a huge pain to track down.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I agree with your premise. Angular promises are now A++ compliant. Part of that spec states that once a promise is resolved or rejected, it's state is fixed permanently - future calls to resolve or reject will not change the promises state. Once you call
resolve(A)
, you can callresolve(B)
orreject(E)
as often as you like - the promise will always be resolved withA
.Are you possibly thinking about always returning a value from a promise handler? That makes a lot of sense. It allows chaining.
That said - I am totally willing to change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I have more pedantic reasons for wanting the
return
in there. I'm not worried about the promise getting resolved or rejected multiple times since, as you said, the A++ spec prevents that. But I do think in most cases it is unexpected and unnecessary to run more code after the promise is resolved or rejected. Putting an explicitreturn
in there will stop future lines in that function from running, which is what we want in most cases. Not doing so can lead to some nasty bugs where code runs when don't expect it to.But yes, allowing for chaining is also a positive, so let's do it! But when you do add the
return
statements, you'll need to move theref.offAuth(callback)
above theif
block or else thereturn
statements will exit early causing that code to not run.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chaining isn't at issue here (we aren't in
then
callback).I made the changes requested. IntelliJ complains that the return statements are unnecessary, but the linter passes.