Three bugs I get hired to fix, written out the way I actually work on them: reproduce first, find the real root cause, then fix.
Each folder has the same three files:
| File | What it is |
|---|---|
broken.tsx |
The code as it arrives, with the symptom described |
DIAGNOSIS.md |
What is actually wrong and why it behaves that way |
fixed.tsx |
The fix, with a note on what changed |
| Bug | Symptom the client reports |
|---|---|
| 01 — Stale closure | "The counter freezes at 1" |
| 02 — Hydration mismatch | "Console error on every page load, layout flickers" |
| 03 — Infinite refetch | "The page hammers our API and the tab goes hot" |
They cover the three things that actually break React apps in production: state captured at the wrong time, server and client rendering different HTML, and referential identity in dependency arrays. Nearly every "my app is slow" or "my app randomly breaks" ticket reduces to one of them.
- Reproduce it first. I do not touch code until I can make the bug happen on demand. A fix for a bug you cannot reproduce is a guess.
- Name the root cause in writing. You get the affected files and what the fix will change, before I change anything.
- Fix, test, hand back. You verify it yourself.
Client and employer code. Everything in this repo is written from scratch for this repo.
Ho Quoc Cuong — React / Next.js / Node.js bug fixing