-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Added error to callback #2439
Added error to callback #2439
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #2439 +/- ##
========================================
Coverage 39.33% 39.33%
========================================
Files 20 20
Lines 1612 1612
========================================
Hits 634 634
Misses 978 978 Continue to review full report at Codecov.
|
js/main.js
Outdated
@@ -295,6 +295,7 @@ var MM = (function () { | |||
// Otherwise cancel show action. | |||
if (module.lockStrings.length !== 0 && options.force !== true) { | |||
Log.log("Will not show " + module.name + ". LockStrings active: " + module.lockStrings.join(",")); | |||
callback("Active lock strings"); |
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.
Maybe rename it to "ERR_ACTIVE_LOCK_STRINGS" so it is a little clearer that it is a error string?
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.
Er even better: allow for an optional error callback?
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 replaced the error for the callback to an actual error object. If you log the error it gives you an actual stack trace from its origin which helps to debug.
I think adding a second callback just for the error isn't necessary. Also, @rejas just fixed the callback recently. Until now it was never triggered, so we are not breaking existing modules with 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.
The problem of this is older modules might not check if the callback contains an error. They might think the action was executed successfully because the callback was called. So this is a somewhat breaking change.
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.
@MichMich if you want me to change it I can, but as I said, @rejas just fixed the callback which means until now the callback was never executed at all https://github.com/MichMich/MagicMirror/pull/2385/files#diff-50260f11109f55b944da641c51de244dffd718cbd77f7e5ce7b9124ab18fe265R437
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.
Ah, true. But still I think a separate error callback is a bit cleaner (and easier to use as a module developer). Or do you disagree?
# Conflicts: # CHANGELOG.md
js/main.js
Outdated
*/ | ||
var showModule = function (module, speed, callback, options) { | ||
var showModule = function (module, speed, callback, errorCallback, options) { |
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.
woudln't just "error" be the most common name for such a function (here and in the other occurences too)?
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 error sounds more like an object instead of a 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.
yes, you are probably right :-)
Just a thought: What if we make the error callback part of the options object? |
It's a fine balance.... If we do it, why not also make the callback part of it? Not sure if this way or the current one one is more readable or less error prone... |
Because that would be a change of API. The regular callback is also something you often use. Error is something you only need in very specific occasions so can be tucked away. IMHO it's good to limit the amount of arguments a method has. Since error will only be interesting for a hand full of devs, it's ok to be tucked away. Of course we could also allow the main callback to be put in the options object and check to see if the 2nd argument is an object or method. If it is an object the callback can be extracted. |
You had me at "change of API" :-) I agree, changing API would be some "v3" change that we dont need to put here. +1 for your putting the error callback in the options and have the normal callback for API reasons in the main function call |
And are we going to call it |
I'd go for |
Agree! |
# Conflicts: # CHANGELOG.md
|
After adding
lockStrings
in a merge request of a module we were running into issues because the callback wasn't triggered in case lock strings were active. Which means you only get notified on success. The way nodejs and any popular libraries that still uses callbacks implement them are like callback(error) or callback(error, data). This way the caller gets always notified and can handle based on the error argument.@skuethe with this, we can avoid manually checking for active lock strings again.
fewieden/MMM-Modal#7 (comment)