Verification Checklist

Reading about developer tools is useful. Being able to open them immediately, find what you need, and act on what you see — without thinking — is what matters. This checklist verifies you have crossed that line.

Do not tick boxes by reading through this page. Open your project, reproduce each scenario, and confirm it with your own hands.

---

Why This Matters

Debugging is a skill you use when something is already broken and there is often pressure to fix it quickly. The last thing you want in that moment is to be navigating menus trying to remember how to open the Network tab or where the filter button is.

The goal is automaticity — the same way a CA can open Excel and navigate to a cell reference without thinking about how to do it, you should be able to open DevTools, switch to the right tab, and read the information you need without conscious effort.

This checklist does not move on until you can do that.

---

Before You Start

You need a running project to test with. Use your current project's dev server. If you do not have one running yet, these exercises will be less realistic — but you can still practice on any website (open udyogaseva.in or any React app).

Open your dev server: run npm run dev in VS Code's terminal and open the app in Chrome.

---

Section 1: Opening DevTools

• Close DevTools completely if it is currently open
• Press F12 — DevTools opens
• Press F12 again — DevTools closes
• Open it again with Ctrl + Shift + I (Windows) or Cmd + Option + I (Mac)
• Right-click any element on the page and click Inspect — confirm it opens DevTools with the Elements tab active and that element highlighted
• Change the docking: find the three-dot menu (⋮) inside DevTools and switch between "Dock to bottom" and "Dock to right" — confirm the layout changes
• Open the mobile device simulator with Ctrl + Shift + M (Windows) or Cmd + Shift + M (Mac)
• In the simulator, switch from "Responsive" to "iPhone 14" in the device dropdown — confirm the page resizes
• Switch back to "Responsive" and close the simulator

Checkpoint: You should be opening and closing DevTools without hesitation. If you find yourself looking up the shortcut, practice the F12 motion ten more times.

---

Section 2: Console Tab

• Click the Console tab in DevTools
• Look at any messages that are already there — identify whether each is red (error), yellow (warning), or white (log)
• In the Console's input field (the > prompt at the bottom), type console.log('hello from the console') and press Enter — confirm you see the output appear above
• Type [1, 2, 3, 4, 5].map(n => n * 2) in the Console REPL and press Enter — confirm you see [2, 4, 6, 8, 10]
• Clear the console using Ctrl + L (Windows) or Cmd + K (Mac) — confirm all messages disappear
• Open your project's code in VS Code. Add console.log('test log from component', new Date()) somewhere inside a component that renders. Save. See the output appear in the Console.
• Click the Errors filter button in the Console toolbar — confirm only error-level messages appear (or nothing if there are no errors)
• Switch back to All

Deliberately trigger an error (do this in your dev environment):

In your code, add a line that will crash: const x = undefined; console.log(x.property);. Save. Open the Console. You will see a red TypeError. Click the file link in the stack trace. Confirm DevTools jumps to that line. Fix the code and remove the intentional crash.

• You triggered a TypeError deliberately and read the stack trace
• You clicked the file link and it jumped to the broken line
• You understand which line in the stack trace is yours (your file name) vs React internals

---

Section 3: Network Tab

• Click the Network tab in DevTools
• Refresh the page — confirm the Network tab populates with requests
• Click Fetch/XHR in the filter bar — confirm most requests disappear and only data requests remain
• Find a request to your Supabase project (look for your Supabase URL in the Name column)
• Click that request
• In the right panel, click the Headers tab — confirm you can see Request Headers including Authorization or apikey
• Click the Response tab — confirm you can see the JSON data that came back
• Click the Preview tab — confirm the JSON is displayed as an expandable tree
• Identify the Status code of this request — confirm it is 200 (green)

Understanding status codes:

• Without changing any code, state out loud what a 401 response means (not authenticated)
• State out loud what a 403 response means (authenticated but RLS blocking)
• State out loud the difference between 404 (URL doesn't exist) and 500 (server error)

Bonus — test a real error (if you have a Supabase project connected):

Temporarily break your Supabase URL in .env (change one character). Refresh your app. Find the failing request in the Network tab. Read the error. Fix the URL. Confirm requests succeed again.

---

Section 4: Elements Tab

• Right-click any visible button or heading on your page → click Inspect
• Confirm the Elements tab opens with that element highlighted (blue background in the HTML tree)
• In the Styles panel on the right, find the rule that sets the color or background-color of the element
• Identify which file that rule comes from (shown after the rule, e.g., tailwind.css:1 or a file name)
• Find at least one property that is crossed out (overridden by a higher-priority rule) — or note that no properties are crossed out for this element
• Click directly on a property value (e.g., click on #1e3a8a in a color rule) and change it to a different color — confirm the change appears live on the page
• Refresh the page — confirm your DevTools edit disappeared (it was temporary)
• Scroll to the bottom of the Styles panel and find the Box Model diagram — identify which layer (margin, border, padding, content) is the largest

---

Section 5: React DevTools

• Check the Chrome toolbar — is there a React DevTools icon (the React atom logo)?
  • If yes: continue
  • If no: install it now (Chrome Web Store → search "React Developer Tools" by Meta)
• Open DevTools. Confirm you see a Components tab and a Profiler tab (these are added by React DevTools)
• Click the Components tab — confirm you see a component tree starting from your root component
• Click any component in the tree — confirm the right panel shows Props and/or Hooks
• Find a component that receives data as a prop (e.g., a card or list item) — click it and read its props in the right panel
• Click the "Select element" button (cursor icon in the Components tab toolbar), then click a specific UI element on the page — confirm DevTools highlights the responsible component in the tree

---

Section 6: Common Errors Recognition

Do this without looking at the Common Errors page. For each error message below, state: what type of problem it is, and the first thing you would check.

• TypeError: Cannot read properties of undefined (reading 'map') — answer: data hasn't loaded yet, add optional chaining or a loading check
• Network tab shows status 403 for a Supabase request — answer: RLS policy blocking, check policies in Supabase dashboard
• Network tab shows status 401 — answer: not authenticated, check if Authorization header is present
• SyntaxError: Unexpected token '<' — answer: server returned HTML not JSON, check the actual status code and URL
• Error: Maximum update depth exceeded — answer: infinite re-render loop, check useEffect dependency array

---

Final Self-Assessment

Before marking this complete, answer these honestly:

• When something breaks in my app, my first instinct is now to open DevTools — not to change code randomly
• I know which tab to open for which type of problem without needing to look it up:
  • JavaScript error → Console
  • Data not loading → Network
  • Wrong CSS → Elements
  • Wrong component state → React DevTools Components tab
• I can read a network request's response and identify whether the problem is auth, RLS, a wrong URL, or my component code
• I understand that a 200 status with an empty array is different from a 403 — and how to respond to each
• I have triggered a real error, read the stack trace, and found the line that caused it

---

One Last Thing

DevTools proficiency is not a one-time checkbox. The first few times you use it to debug a real problem, it will still feel slow and unfamiliar. That is normal. After five or six real debugging sessions, it becomes automatic.

The mark of someone who genuinely knows how to use DevTools is not that they know every feature. It is that when something breaks, they do not panic — they open DevTools with one keystroke and start reading.

That is the habit this module is building. You will get there.