How much console.log can be written here and there? At the beginning, I didn’t mind checking the status of the application with this command added here and there to the code, but I’m starting to write more complex applications and decided to look for some alternatives.
Is using console.log a bad idea?
First of all, using console.log is not bad. It allows you to find and fix errors in the application. In fact, in none of the JS tutorials, I found information on how to search for bugs other than with console.log. However, I lacked a tool that would allow me to stop the code at any time and look at the variables, for example, what is there in each of them at a given moment, or even run the code line by line.
There must be an alternative for console.log
Since the VBA code editor built into Microsoft Office has such functionalities, JS code writing tools certainly have such functionalities. I just thought and started looking. Someone once told me that YouTube, apart from billions of videos about nothing, has countless videos with useful knowledge.
When it comes to knowledge in the field of IT, it really is. I found the information very quickly using Google Chrome as an advanced debugger. The Ctrl + Shift + I key combination runs the developer tool along with the console. This is nothing new, but this console has the features I wanted which are “hidden”. The tab called “Sources” has all the tools I’ve been looking for for a long time.
What kind of possibilities Google Chrome gives you?
First, it lets you stop your code at any time. For example, you can select at which event the code should stop. The Event Listener Breakpoints tab allows us to define it very easily.
When the execution of the code is suspended, the line the code is currently on will be highlighted in blue in the top window. Now you have several possible options:
- line by line code execution,
- move to the next function,
- move to the previous function,
- view the state of local and global variables,
- track selected variables.
How I missed it all. What’s more, if you decide that there is no error in the currently viewed place in the code, you can select any line of code and run the code execution to the indicated line. More about this tool you can read from Google Web Page.
How about a deep inspection of variables?
Another cool option is to run commands like typeof in the Watch tab. It allows you to examine the content of the variable you are interested in at a specific moment of code execution.
How many times have I wondered why some operation on a variable is failing. I used console.log for this in several places and it took a long time to figure out the state of the variable. Now I can do it much faster.
Instead of console.log, you will full access to the console.
Extra cool thing is that when the code is stopped, you have access to the console and you can perform operations on all variables that are currently in the stack. You can also correct your code in the top window and save it with ctrl + s and then run from the indicated place to see if the introduced corrections brought the expected results.
Are you still happy to use console.log?
I’m very happy that I was able to find information on how to search for bugs in a more effective way. If you are tired of using consol.log as a way to catch bugs, I also recommend you switching to Google Chrome DevTools.
You can also check these types of tools in your code editor. However, I believe that today I work on the “X” editor, tomorrow I can work on the “Y” editor, and Google Chrome DevTools will probably be on the top as long as it is the most popular browser among users.
If you are interested in nice and helpful tools for VS Code, I wrote about that I use here: Useful tools for developers.
Finally, a summary of the week. First of all, I’m working on the last application in the Java Script course. More interesting news comes, mainly about generating content for the page depending on the state of the application. I managed to devote eight and a half hours to study.
