How to practice with Debug React

Start your first scenario

Pick a scenario in the library and choose Fix the bug. The workbench opens with:

• Brief: the bug report, written the way a user would describe the problem, with reproduction notes and hints. Start here.
• Notes: an optional scratchpad for your hypothesis and observations.
• The editor, with the app's files. Your changes reach the preview as you type.
• The preview, the running app. Use it to see the bug for yourself before you change anything.
• Checks and Console: the check results, and what the app logs.

On a phone, these are tabs.

An order that works well:

1. Reproduce the bug in the preview, following the bug report.
2. Form a hypothesis: which order of events could cause what you see?
3. Read the code your hypothesis points to, and confirm or reject it, for example with a console.log.
4. Make the smallest change that fixes the cause, not only the symptom.
5. Repeat the steps from the bug report, then choose Run checks.

If you are stuck, choose Reveal hint 1. Each scenario has three hints, each more specific than the last. Using them is recorded on your report and never penalized.

The header shows your active practice time. It only counts while the workbench is in front of you, and it is for your information: never a countdown or a grade.

When you are ready, choose Submit attempt. Explaining your fix comes next; see Explain and review.

Practice independently

Each scenario suggests working through it without AI assistance. This is not a judgment on AI tools. Debugging is a skill, and you only find out which parts you understand by working through them yourself.

Welcome help: official documentation such as react.dev and MDN, your browser's developer tools, console.log, and the built-in hints.

Getting stuck is useful. Notice where you got stuck and what got you moving again: that is what to practice next. Once you have submitted, the worked solution and the proposed fixes show other ways to solve the same bug, so comparing comes afterwards.

Understand the checks

Run checks runs five behavioral checks against your code in a separate, hidden sandbox. They test what the app does, for example that an older response cannot overwrite newer results, not how the code is written. Any correct fix passes, not only the worked solution.

A run uses a copy of your code taken when you start it, so editing during a run does not change its results. Each check shows one of these:

• Passed: the check finished and the app behaved correctly.
• Failed: the check finished and the app did not behave as the check describes.
• Stale: you have changed the code since this run, so the results describe older code. Run the checks again.
• Unavailable: the check did not finish, for example because the sandbox did not load or the run took too long. A timeout is never counted as a pass. Run the checks again; if it keeps happening, see When something looks wrong.
• Not run and Running: no result yet.

Passing checks does not prove a fix is right in every possible case. The checks cover the behavior in the bug report and the most likely ways a fix goes wrong. They are learning feedback, not a certificate, which is why you also explain what you verified and what you did not.

When you submit, the checks run again on exactly the files you submitted. Failing or incomplete submissions are allowed: this is practice.

Explain and review

Submit attempt asks four questions: what caused the bug, as an order of events; what you changed and why it is enough; which alternative you considered and why you rejected it; and how you verified the fix and what remains untested. A follow-up question then takes the scenario one step further.

A useful explanation:

• describes the cause as a sequence of events ("the user types, the first request starts, ..."), not only a label such as "a race condition";
• says why your change is enough, not only what it is;
• names what you did not test. That is a strength, not a weakness.

Finish with Complete attempt, or Save as incomplete to stop early. Nobody grades the answers. Your report puts your reasoning next to the check results and your code changes, with a self-review checklist to compare against.

The report also has the worked solution, with its reasoning and trade-offs. It stays hidden until you choose Show worked solution, so you decide when to compare. A finished attempt does not change: Retry from the broken files and Continue editing in a new attempt start a new attempt linked to it.

Review a fix

Once you have finished a fix, the scenario offers Review a fix: a change someone else proposed for the same bug. Reviewing differs from fixing. You start from someone else's reasoning, and the question is whether the change really works, not how you would have written it.

Read the change, try it in the preview, then choose Approve or Request changes, say what it gets right or wrong, and if you like, predict which checks will fail. After Submit review, the checks run on the proposed fix and show whether they agree with your verdict. Some proposals look right and are not; others are correct but differ from the worked solution. Review another fix offers the next proposal.

Keep your progress safe

Your attempts save automatically in this browser as you work. The header shows Not saved yet or Attempt saved locally.

They stay in this browser, on this device and on this address. Another browser, another device or a private window does not see them, and clearing your browser's data for this site deletes them.

• Export backup, on the Attempts page, saves everything to a file. Import backup restores it here or in another browser. Importing only adds attempts that are not already there; it never replaces yours.
• If you practiced on the earlier address, react-debug-arena.pages.dev, your history is stored there: export it on that address and import it here.
• If saving fails, for example because the browser's storage is full or blocked, a warning stays on screen and your changes stay in this tab. Keep the tab open, free some space or allow storage for the site, then use the retry button the warning offers. Export a backup if you can.
• If the same attempt is open in two tabs and both change it, saving pauses and asks which version to keep, so neither tab overwrites the other.
• Clear local history, on the Attempts page, deletes all attempts in this browser. It cannot be undone, so export a backup first.

Your data and privacy

• Your practice stays in your browser. Your attempts, code and answers are never uploaded. No accounts, analytics or ads.
• The site is hosted by Cloudflare, which, like any web host, sees your IP address and browser, but none of your practice.
• The code sandbox is provided by CodeSandbox and runs in your browser. Your code is not sent anywhere, but loading the sandbox shares basic technical data, such as your IP address and browser, with CodeSandbox and the services that deliver it.
• Feedback contains only what you type, plus the app version, the page you came from and your browser's name. It is emailed to the developer.

When something looks wrong