the tools built into your browser are incredibly powerful these days. thereâs a lot to say on how to use these tools. you should start by just taking any random website you like and mess around with it using the tools. once youâve played with it a little bit, go read the reference docs. make sure youâve enabled sourcemaps with your bundling tool. create-next-appâs bundler config should have these on by default.
i wonât go over every feature in this guide, but iâd like to point out some highlights and tricks/tips that iâve found commonly ignored by engineers:
$0: select an element via the Elements panel and it will be available via the Console as the $0 variable.
breakpoints: i have found over the years to be rather surprised that a lot engineers donât know this is available. click on any source line to pause execution there.
conditional breakpoints: related to the above you can right-click on a line to add a line that only executes given a certain set of circumstances.
add logpoint: Chrome 73+ has a new feature that lets you add console.log statements on the fly to your code, without having to pause execution(which can throw off timing and prevent reproducing certain classes of bugs.)
device toolbar: in the top left, next to the Inspect element icon is a button that lets you see how your site is responsive to different mobile device widths.
network throttling: letâs you simulate a slower network to see how your site responds under slower conditions. not everyone has your app running locally đ.(under Show Console DrawerâNetwork conditions).
user agent spoofing: lets you see how your site responds under different browsers or bot user agents. in general, it shouldnât! donât change your site depending on the highly unreliable user agent whenever possible!(under Show Console DrawerâNetwork conditions).
workspaces: DevTools has the ability to save the changes you make in the browser back to the source files on disk.
your bundler, by the way, will create source maps so that your files that are bundled for your app can be mapped backed to the original code in development mode for easier debugging within Chromeâs DevTools.
on the topic of your bundler, another mention here in your workflow is that webpack allows for hot module replacement(HMR). this allows for a much faster iteration cycle, especially when debugging a particular section of code.
a must-have tool to debug React components, changing their state and props on demand.
some highlights and tricks/tips for React DevTools:
$r: iâll mention here that related to the $0 variable is the sister variable $r that gives you the last selected React component from React DevTools.
node
to be able to debug node.js, you must launch it with the--inspect flag. from there, you can use your favorite editor/IDE and attach the debugger to the process. you usually have to specify the port(defaults to 9229) and then youâre off to the races! it should work more or less like Chromeâs DevTools debugger.
other configuration options:
--inspect-brk will allow you to wait until debugger attaches, then break on the first line of JS.
--inspect=0.0.0.0:9229 will allow remote connections(useful if your process is on another machine; though may be safer to SSH tunnel instead).
if you visit chrome://inspect in your browser, this will allow you to connect your editor to the V8 debugger protocol.
tracking errors
exception handling
at the very least, you need to gather exceptions from your clients and send them up to your server so you know what errors are happening to your users out in the wild. if youâre lucky you will have passionate users that will mercifully report to you bugs they are experiencing.(thank your lucky stars!) but a lot of bugs will go unnoticed and unreported manually by users. and, they might only happen in certain special cases or in certain browsers/countries/days of the week/what have you.
tl;dr
Chrome DevTools
React DevTools
node
tracking errors
exception handling