Chrome developer tools to master
apsdehal.in
Chrome developer tools to master
1–10 of 100 posts
Re: Chrome developer tools to master
#2One thing that wasn't touched here is that you can actually map the developer tools to your local files. My old co-worker used Dev tools as his text editor. Pretty nifty!
Re: Chrome developer tools to master
#3I implemented two simple interview tests in order to weed out people who can't do simple debugging.
In one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it?
So far, two ways to pass: Just look at the source code, or use the network debugging tools to find the error.
Spraying console.log statements everywhere is a red flag to me. So far, the test seems to work well.
Re: Chrome developer tools to master
#4I implemented two simple interview tests in order to weed out people who can't do simple debugging. In one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it? So far, two ways to pass: Just look at the source code, or use th…
[deleted]
Re: Chrome developer tools to master
#5As the author notes, most of these tips can be applied to Firefox (or Edge) as well.
Re: Chrome developer tools to master
#6I implemented two simple interview tests in order to weed out people who can't do simple debugging. In one, I hand them my laptop and give them a basic create-react-app sample that uses fetch on a remote URL, but there's a typo in the URL. I tell them it's supposed to fetch a remote REST API and parse the JSON but it doesn't work--how would you fix it? So far, two ways to pass: Just look at the source code, or use th…
I have a similar interview question, but I have a few layers on top of it, not all of which are required to progress through the interview:
1. Send CSP headers that prevent some of the JS from executing. This is really obscure to most people, but if you look at the console and search the internet for the error, it gives you a good idea. This gets you thinking about the script.
2. Include a simple JS syntax error in the AJAX call. It helps prime them to figure out why the call, once the error is fixed, still doesn't work, rather than having them try to think about the entire front-end as a source for potential problems.
I like to make sure that people are generally guided to the problem to solve, but also to test them along that path. A lot of debugging involves things a few steps/layers removed from the actual problem before you get to the point of solving it, so it's fun to test those steps too, as each can lead you down a wrong/different path.
Re: Chrome developer tools to master
#7This is great, besides the Sources tab, I use DOM and Event breakpoints a ton to debug a lot of problems.
Something, I'm not sure if most people know, if you break somewhere (whether event or DOM), you can access the currently in scope variables directly in the console. It's extremely useful for finding out what's going on with something in the middle of hairy code at a specific point in time.
Re: Chrome developer tools to master
#8One thing I didn't see in the article:
As well as setting breakpoints, one can trigger the debugger by including the statement
debugger;
Re: Chrome developer tools to master
#9This is great, besides the Sources tab, I use DOM and Event breakpoints a ton to debug a lot of problems. Something, I'm not sure if most people know, if you break somewhere (whether event or DOM), you can access the currently in scope variables directly in the console. It's extremely useful for finding out what's going on with something in the middle of hairy code at a specific point in time.
It's also possible to change the value of these variables and test different code paths.
Re: Chrome developer tools to master
#10One thing I didn't see in the article: As well as setting breakpoints, one can trigger the debugger by including the statement debugger; in a script. Then, having the Dev Tools console open when that statement executes will automatically hop you into the debugger with access to variables in scope, etc. Easier IMO than manually setting breakpoints, especially when working with some transpiled languages.
For transpiled languages: if you set up source maps correctly, you can access the non-transpiled language and the devtools will set up rules on the correct places (in this case, breakpoints, which also jump automatically to the original source instead of the transpiled version)