When debugging JavaScript I make heavy use of the console to evaluate individual lines of code, to retrieve instance values to test in 3rd party software (i.e. when building SOAP requests)
Now I've got IE11, it looks like the code I type into the debugger is executed (I can open alert boxes etc..) however the results are not printed in the console. Does this mean I now have to surround everything I type into the console with console.log(JSON.stringify( /* ..expression.. */, null, 4 )) statements?
Is there an easier way to return to the IE10 console behavior?
Answered by #MrAnonymous, please direct all (well deserved) praise to the comments above.
As noted above, this is an issue with the Debugger tools themselves and can be rectified by reloading the tools.
Related
When outputting messages into the console, the source is also displayed (in Chrome Developer Tools it's on the right):
console.log("Foo"); //Source
Foo test.js:1 //Output
However, on some sites, messages are displayed without the source being displayed, such as on Facebook:
Having a look on the Chrome Console API Reference there are examples across a ton of different outputs but all of them have the source displayed.
How can I hide the source (.js page and line number) of console outputs?
Edit: Just for clarification, this is not a duplicate of How does Facebook disable the browser's integrated Developer Tools? as that question answers how the console disables standard user input (and its answers explain how it works). I am specifically asking about the aesthetic of not displaying the source file and line.
They are using setTimeout to detach from the source:
setTimeout(console.log.bind(console, '\n%c' + s[0], s[1]));
for those who are still looking for this, you can use something like
function consoleWithNoSource(...params) {
setTimeout(console.log.bind(console, ...params));
}
consoleWithNoSource("Helloo....!")
What is the benefit of using console.log vs console.info?
Or any of the other console commands for that matter?
console.info("info");
console.error("error");
console.warn("warn");
vs
console.log("log");
I thought it might change the color of the output or concatenate some sort of label, but they seem to all do the same thing. And according to the documentation here:
https://nodejs.org/api/console.html#console_console_info_data
they seem to all do the same as console.log
According to the documentation that you linked to, console.error and console.warn outputs to stderr. The others output to stdout.
If you are doing piping or redirection from node.js the difference is important.
There is a lot of JavaScript written to run in both the browser and Node.js. Having node implement the full console allows for greater code cross-compatibility.
In most browsers, not only do these log in different colors, but you can also filter to see specific messages.
console.info("info");
console.error("error");
console.warn("warn");
console.log("log");
While console.log and console.info might seem the same, with only mere coloring differences (in most browsers), you can take advantage of having these differently named functions.
For example, you can configure a linter like eslint to produce a warning message whenever console.log is used but no warnings for console.info. Now you can use console.log for temporary development/debug logging and console.info for information that end users might need. The linter warnings will remind or even force you to removed the temporary console.log calls before commits code or publishing release builds.
console.log() is shorter than console.info()
They're the same thing, and that's the only advantage.
According to the docs it's pretty clear.
console.info([data], [...])#
Same as console.log.
console.error([data], [...])#
Same as console.log but prints to stderr.
console.warn([data], [...])#
Same as console.error.
This means there is no benefit or downside. info == log, and warn == error. Unless you want to print to stderr, info and or log will work.
Visually, No difference actually among console.log , console.info , console.warn , as well as console.error regarding the server side(terminal).
However, there are lightweight modules that add blue, orange and red colors for console.info , console.warn , as well as console.error respectively . By that, console API behaves like client-side.
npm i console-info console-warn console-error --save-dev;
One more detail in addition to the accepted answer: In Chrome and FireFox, console.info log lines are prefixed with a little i icon while console.log lines are not. warn and error lines are prefixed with a little triangle and x, respectively.
stdin
A readable stream for reading input from the user.
stdout
A writable stream, either synchronously or asynchronously.
stderr
A blocking synchronous writable stream intended for error messages.
The stdout or non-blocking functions are: console.log, console.info, util.puts, util.print and Stderr.
The blocking functons are: console.warn, console.error, util.debug and process.stdin (a readable stream for getting user input).
It has been established that log and info are basically the same thing, but I'm not sure that completely answers the question:
What is the benefit of using console.log vs console.info?
One benefit, apart from what has already been mentioned, is you can use each for a different purpose. For example, you might use console.log just for quick debugging and spitting things out to the console, while you might use console.info for permanent messages you want to output to the console in your code, such as information on the current app status. Then when you have a situation where a random object is printed in your console and you realize you've left a log statement in there somewhere by accident, you can do a global search for 'console.log' and delete every instance and have confidence you didn't delete anything important that you meant to leave in there.
I have seen where console.log is for temporarily logging of state information for debugging.
console.info is a more permanent thing - such as saying what port something is running on, and something you wouldn't cut out after you are done debugging.
This makes it easy to clean up your code for committing it. You can even have your linter have a rule to prevent console.log from being committed.
There is a difference for React devs. It comes from an issue in the react devtool extension and at least affects Create-React-App users, not sure if it's all web pack.
Issue is mentioned here:
react devtools console.log() from react_devtools_backend.js:4049
but the jist is:
console.log will always report its source as
react_devtools_backend.js:4049
wheres console.info will have the actual filename and line number you're logging from.
The different logging levels let you manage the noise level in your console: In both the Firefox (I'm using 78 right now) and Chrome (84) devtools, the js console lets you choose what "debug level" of output you want to see. FF lets you toggle the visibility of console.error, .warn, .log, .info, and .debug messages by clicking individual buttons for each (that show you how many were suppressed, when "off"), whereas Chrome has a dropdown with checkmarks next to the items (.info and .log are controlled by the "Info" one, and .debug by "Verbose"). The Chrome dropdown label ("All levels" or whatever you set) turns red if output was suppressed.
This question already has answers here:
How can I debug my JavaScript code? [closed]
(20 answers)
Closed 9 years ago.
Is there something like jsfiddle where i can just enter my js code and it will show me any syntax erros, ',' or ';' out of place for example?
Using the code:
$("#customer").autocomplete({
minLength: 0,
source: customers,
focus: function (event, ui) {
$("#customer").val(ui.item.label);
return false;
},
select: function (event, ui) {
$(this).val(ui.item.label).change();
$("#customerid").val(ui.item.value);
return false;
}
});
You can check the console of the browser, opened by pressing the F12 key while in the browser. Then go to the console tab and see what messages are printed there. Javascript errors are printed here, including syntax errors.
The console will append errors from javascript when you're looking at the page in the browser.
You have two options:
Check the console of your browser (All the major browsers have it). I use google chrome. Console will show you the file having errors plus the line at which the errors are found. But... As further interpretation of Javascript is stopped after an error is found, it'd usually show you a single error. If you want to get a list of all the errors at once, then I'd suggest you to go look for some online service. Plus Google chrome has the best debugger (in my opinion) with watch and all that stuff that can help you in debugging.
You could also use online services available. For example paste your
code at JSLint and it will show you the errors
Just be aware that missing semicolons do not constitute syntax errors in JavaScript. Semicolons are optional (well almost always), if you have line breaks between statements.
Press f12 and see Console option for any errors.
A quick search on google brought up JSLint. This tool might help
JSLint.
Seems a nice tool with a lot of options for Code Quality too.
You can use Jsbin.
Check your code here when I removed one comma.
This allow you to share your code to anyone(similar to JsFiddle).
What can JS Bin do?
Write code and have it both save in real-time, but also render a full preview in real-time
Help debug other people's JavaScript, HTML or CSS by sharing and editing urls
CodeCast - where you share what you're typing in JS Bin in real-time
Remote rendering - view the output of your JS Bin on any device on any platform, updating in real-time
Processors, including: coffee-script, LESS, Markdown and Jade.
Debug remote Ajax calls
I'm writing a javascript / HTML5 canvas library to provide basic GUI elements for web audio applications.
There's a little demo script that creates widgets with the library and assemble them in a GUI. You can find it # http://bitterspring.net/webshifter/
The problem is, it seems to work correctly on Chrome and on Firefox 3.6 - 4.0 but, in the last cases, only with firebug. Without firebug, the script seems to visualize nothing on screen, while with firebug it does.
The only firebug-related pieces of code are some console.log statement I use to track the behaviour of the library. But these statements should have no effect on a non-firebug enabled browser, as I learnt from Firebug forums. What can prevent the example script to work, in these cases?
The library + example code is freshly committed on http://github.com/janesconference/KievII , by the way.
EDIT: Seems that, when console is not defined, console.log() throws an exception. Is there a way to keep the logging lines of code and not getting the exception? (yeah, one could check if console != undefined, but is there a better way?)
EDIT: This does the trick, it seems (Font)
if (typeof console=="undefined"){console={log:function(A){var B=false;if(B){alert(A)}}}}
Right, the console object is not available in all browsers by default.
This code:
if (typeof console=="undefined"){console={log:function(A){var B=false;if(B){alert(A)}}}}
- currently disables console support in Firefox 4's Web Console, since it tries to inject the console object when opened and won't do that if the page already defined a console object.
An interesting wrapper for console that deals with this problem is: http://benalman.com/projects/javascript-debug-console-log/ , although I haven't tried it myself.
Firebug is certainly a wonderful tool for javascript debugging; I use console.log() extensively.
I wanted to know if I can leave the Firebug-specific code in production.
What's the best practice? Commenting the debug code?
If you leave console.log() calls in your production code, then people visiting the site using Internet Explorer will have JavaScript errors. If those people have extra debugging tools configured, then they will see nasty dialog boxes or popups.
A quick search revealed this thread discussing methods to detect if the Firebug console exists: http://www.nabble.com/Re:-detect-firebug-existance-td19610337.html
been bitten by this before. Ideally all the console.log statements need to be removed before production, but this is error prone and developers invariably forget or only test in FF + Firebug.
A possible solution is to create a dummy console object if one isn't already defined.
if( typeof window.console == 'undefined'){
window.console = {
log:function(){}
};
}
One word of caution: It used to be the case for Safari on 10.4 that any call to console.log would throw a security exception as the console object is a reserved object used in the Mac OS Dashboard widgets. Not sure this is the case anymore, will check tonight.
Personally I modified my compressor a while ago to strip out console references pre-compress. A few minutes adding a regex there saves a lifetime of hassle.
Just thought I would add a really good tip for any js debugging.... use the keyword "debugger", and its like a breakpoint in the code, firebug detects it also MSIE (if you have visual studio) detects it and as I say its a breakpoint.
Not many people seem to know about this but I have found it invaluble... also if there isnt a debugger installed on the machine that is running the code, nothing happens and the code goes through fine. Although I wouldn't advise leaving them in there.
I have had many a headache caused by this.
I use console.log() a lot, and until recently, found that it would cause the entire JS code to fail in versions of FF not using firebug.
I usually run a find before going live, and commenting it out.
D
Some compressors will strip out any line prefixed by ;;; (which is a legal sequence to have, being three empty statements.) This way you're not strictly limited to console references (i.e. you could do some calculations and then console.log() the result at the end, and the compressor can strip all of them out.) I use JavaScript::Minifier for this.
I use this in OOP Javascript, making my own wrapper for log that checks that firebug exists:
myclass.prototype.log = function()
{
if( typeof window.console != 'undefined' )
{
console.log.apply( null, arguments );
}
}
Just call:
this.log( arg1, arg2, ...)
Just a reminder that IE Dev Tool does not support apply() on console.log.
Calling console.log.apply() will raise exception in IE8 when dev tool is active.
You can try JavaScript Debug, it is s simple wrapper for console.log
http://benalman.com/projects/javascript-debug-console-log/