Usually, you shouldn't get into a lot of trouble while coding the examples in this book. But, of course, in the typical day of any software developer, there will be many times where things go awry and where a good debugging session will help.
Let's see how you can debug web applications. This is a must-have skill for any developer out there, and there are many tools and solutions to help you figure out what your programs are doing.
The most basic debugging tool at your disposal is simply the console.log function, which you can use to log variables while your program executes. Although, it clearly isn't a panacea and far from a best practice, so you should use it sparingly for small checks. When your code reaches production, you don't want it to be cluttered with console.log statements. Debugging and logging are two separate concerns that should each be treated in an appropriate way.
Debugging is something that you should normally do using a debugger such as the ones that web browser developer tools offer out of the box.
Let's see how to use those included with Google Chrome. Press F12 to display them, then go to the Console tab. If you look on the right, you'll see that each time a log entry is added, you have the corresponding file and line where the statement came from. Click on one of those:
Once you do so, you should be brought to the Sources tab, which should look like this:
At the top, you will see the currently opened file(s). If you click on the icon on the left, you can display the navigator and open additional files.
In the next screenshot, you can see the file content with the line numbers. If you click on a line number, for example, on line 10 in this example, then you'll add a breakpoint:
If you click on that line again, you'll remove the breakpoint. On the right, you can see the list of breakpoints under Breakpoints, and you can enable/disable each of them.
Whenever a breakpoint is hit (that is, when the runtime is about to execute the line where the breakpoint is located), the debugger will pause the application and will let you inspect the state of the program.
Since we have added a breakpoint in the isEnter function, go ahead and press Enter in the Add todo input:
As you can see, the program is now paused. On the left, you can see that it is, and you can resume it if you want. On the right, you can see that the breakpoint that was hit is highlighted. Also, under the Scope section on the right, you can now see the current stack and inspect the state of the variables, such as the event that was just passed to the isEnter function.
On the left, you can see exactly where the debugger has paused the program.
Finally, on the right, you should learn to master the different buttons:
- Resume (F8): Let the program continue.
- Step over next function call (F10): Continue the execution of the next function without going into it.
- Step into next function call (F11): Continue the execution of the next function and go into it.
- Step out of current function (Shift + F11): Get out of the current function.
- Step (F9): Continue to the next statement.
These functions allow you to step through the code, going as deep as you need to understand everything that is going on. Usually, you should get into the function calls that you care about (for example, the addTodo function) and step over the functions that you are not interested in. If you simply step into everything, then you could easily spend days debugging and be drowned by the excruciating amount of information.
In the debugger, you can also use the Watch section to define expressions to keep an eye on.
The debugger is your best weapon for troubleshooting issues, so take your time to learn and master it. Check out the official documentation to learn more: https://developers.google.com/web/tools/chrome-devtools.