Skip to content
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

Merged

Conversation

fewieden
Copy link
Contributor

  • Does the pull request solve a related issue?

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.

  • If so, can you reference the issue?

fewieden/MMM-Modal#7 (comment)

  • What does the pull request accomplish?
  • callback for show function always gets called.
  • If lockStrings are still active the callback contains an error

@codecov-io
Copy link

codecov-io commented Jan 28, 2021

Codecov Report

Merging #2439 (652e1a5) into develop (ef2fd16) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           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.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef2fd16...652e1a5. Read the comment docs.

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");
Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Contributor Author

@fewieden fewieden Jan 28, 2021

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.

image

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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

Copy link
Collaborator

@MichMich MichMich Jan 31, 2021

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?

js/main.js Outdated
*/
var showModule = function (module, speed, callback, options) {
var showModule = function (module, speed, callback, errorCallback, options) {
Copy link
Collaborator

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)?

Copy link
Contributor Author

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

Copy link
Collaborator

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 :-)

@MichMich
Copy link
Collaborator

MichMich commented Feb 6, 2021

Just a thought: What if we make the error callback part of the options object?

@rejas
Copy link
Collaborator

rejas commented Feb 7, 2021

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...

@MichMich
Copy link
Collaborator

MichMich commented Feb 7, 2021

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.

@rejas
Copy link
Collaborator

rejas commented Feb 7, 2021

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

@MichMich
Copy link
Collaborator

MichMich commented Feb 7, 2021

And are we going to call it errorCallback or onError?

@rejas
Copy link
Collaborator

rejas commented Feb 7, 2021

I'd go for onError since there are already occurences of that name in the code.

@MichMich
Copy link
Collaborator

MichMich commented Feb 7, 2021

Agree! onError sounds best. :)

@fewieden
Copy link
Contributor Author

  • Moved errorCallback into options
  • Renamed to onError
  • Created PR in the documentation project
  • Resolved merge conflicts

@MichMich MichMich merged commit ea6eebd into MagicMirrorOrg:develop Feb 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants