You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it seems that the callback only ever has one argument, with that sole argument representing either a result, or an object with a potential error in it:
api.goals.list(params,(result)=>{if(result.error){throwresult.error;}//else result is the data we're looking for });
Ideally, the pattern would use the standard node callback pattern of (error, result):
api.goals.list(params,(err,result)=>{if(err){throwerr;}//else result is the data we're looking for });
An advantage to this (other than predictable behaviour for new developers integrating this module) is easy compatibility with node v.8.x.'s promisify method to make methods into Promises*:
Thank you for this suggestion. I agree that Promises should be supported by our library out of the box. Also, we can do better with standard error handling.
We will probably fix those issues when we release some updates to this lib. We don't have this planned in the nearest future, though.
Currently, it seems that the callback only ever has one argument, with that sole argument representing either a result, or an object with a potential error in it:
Ideally, the pattern would use the standard node callback pattern of
(error, result)
:An advantage to this (other than predictable behaviour for new developers integrating this module) is easy compatibility with node v.8.x.'s
promisify
method to make methods into Promises*:versus the current:
*That being said, it'd also be nice if this library supported Promises in addition to callbacks.
The text was updated successfully, but these errors were encountered: