Graduating From Repl.it to Dev Tools
Tags: beginners, javascript, webdev
Published: 2021-01-20 10:21:23

If you're like me, you're a wiz in a school setting, but real world applications test your stress levels and make you lose focus. The leap from classroom to office is a nosedive from the guiding hand of a teacher to the grimace of an impatient boss. And it means leaving the comfort of repl.it or Python Tutor for the cold reality of Chrome's developer tools. Fortunately, with some practice, dev tools can be as useful or more than those safe and easy sandboxes.

Go to any website and press `Ctrl+Shift+I` (in Windows or Linux) or `Command+Option+I` (on a Mac), and a new frame will take over the right side of your screen, pinning your page to the left. These are the developer tools. Look at the top right corner of the dev tools window. At the end of the "Elements, Console, Sources..." panel you'll see a gear icon followed by three dots in a vertical line. Click the dots. A small window should appear with a few options, the first one saying "Dock side" with four icons next to it. Click the icon that says "Dock to bottom" when you hover over it. Now the dev tools are on the bottom of your screen. Changing the dev tools' position is easy, so it's good to get the least annoying placement for whatever you're trying to do.

The best-known dev tools tabs are probably Console and Sources. Console lets you write JavaScript and compiles it for you. Sources shows the text files powering your page. If you can't find the file you're looking for, press `Ctrl+P` (Windows, Linux) or `Command+P` (Mac), and all of the source files should appear in a drop-down menu. In the main html file, you can change the text and layout of the page. The changes are only visible to you, and they revert to normal when you refresh.  

If you're developing a webpage, you can load your unpublished work on a private http server and use dev tools to see what your code is doing. If you save your changes and reload your page but your changes don't stick, do a hard refresh. On Windows or Linux, that's `Ctrl+Shift+R`. On a Mac, `Command+Shift+R`.  Always hard refresh when checking your code. 

The Elements panel is wildly useful. It's like Sources, but it shows you the html of the DOM as it's been modified by JavaScript. This html does not exist in any actual file. It is the end result of the html file and the JavaScript files that are enacting changes on it. You can access Elements by right-clicking (Ctrl-click for Mac) any part of the page and clicking "Inspect." It will show you the html code for the part of the page you clicked and highlight the part of the page produced by the code you hover over. This is really useful if you've introduced some JavaScript that's messed up the layout of your page, and you need to figure out which element you accidentally made block-level.

In your JavaScript file, you can run a "console.log" statement, and it will show up in your console when you refresh the page. The console also displays error messages. You can supercharge the error-checking ability of your console by adding a "debugger" line to your code. Go anywhere in your code and add a line that says:

```
debugger;
```

Now save your file and refresh the page. The code will come to a hard stop on the line you put the debugger on. Since each var, let, and const you declare is function or block-scoped, you can't just type any binding name into your console and expect to see its value. You need to guide your code to the scope level where the binding is held. So you stick a debugger line inside a function declaration, conditional, or loop and then check your local bindings while the code is frozen in their scope. 

Let's say you have some code like this:

```
let i = 0;
while (i < 10){
  i++;
}
```
And you want to use the console and debugger to get the value of i. You put a debugger line in the while loop:

```
while (i < 10){
  i++;
  debugger;
}
```

And then you run your code. It hits the debugger line and stops, and you can now type "i" into your console to get the value. But which iteration of the loop is it giving you the value for? The code stops as soon as it reaches the debugger line, so initially, i will be 1. But what if you want to know the value of i at the third iteration? There is a panel in your dev tools that stays put whether you're in Elements, Console, or Sources. That panel will say "Debugger paused" while your code is frozen, and it will have a few icons above that line. A play button, a dot with a loopy arrow above it. An arrow pointing down, one pointing up, and one pointing to the right. The right arrow is your "step" feature. It will walk through your paused code line-by-line every time you press it. So if you press it once, it will take you back to the top of your while loop and check the conditional. i equals 1, which is less than 10, so it proceeds into the loop on the next click. Then adds 1 to i on the next click, etc etc. A few clicks later, you can get to the third iteration of the loop and see that i = 3. This is useful for values that are being sent to functions or recursive calls and coming back different from what you expected. Put the debugger right before the function call and walk through the steps until you figure out what's going wrong. 

This is just the tip of the iceberg with dev tools' ability to freeze and pick apart your code. You can go into Sources and highlight a line number of one of your source code files. The number will turn blue. This does the same thing as adding a debugger line in your actual source code. Refresh the page and it will freeze on that line. If your code never freezes, that means your interpreter is never reaching the debugger line. Perhaps it's a conditional whose condition is never met. 

```
if (false){
  debugger;
} //your code will never pause
```

If you dig a little deeper, you can even trigger pauses with events like mouse clicks. Go ahead and play around in dev tools. It's not as user friendly as a pure learning environment, and sometimes it seems deliberately confusing. Why does the next line always say "undefined" after you enter a command into the compiler? Is it just to make you think you've done something wrong? Maybe. But don't let that discourage you from making the most of the tools at your disposal.