Running generated React before you trust a word of it

Reading code is not evidence

Generated React looks plausible in a way that generated prose rarely does. Imports read correctly, hooks appear in a sensible order, the component returns something that could be JSX, and the whole file has the shape of work somebody did carefully. That shape is exactly what makes review unreliable.

None of the failures that matter are visible in the shape. An import path that does not resolve, a prop that arrives undefined because nothing passed it, a hook placed after an early return, an event handler that references a state setter that was renamed: every one of those looks fine until the component runs.

A live mount converts each of them into a message. That is the entire argument for running the code rather than reading it: the browser is the only reviewer that cannot be persuaded by confident syntax.

It is also the fastest form of review there is. Pasting a component into a sandbox and watching it fail takes seconds, and the failure names the line. Reading the same file carefully takes ten minutes and produces a hypothesis.

The four failures a mount exposes

Unresolved imports first. A model working from memory will import from a path that existed in a library two major versions ago, or a submodule that was never part of the package. The compile step fails with the path, which is the whole diagnosis.

Runtime exceptions on first render, which are usually about data rather than logic. A component that maps over a prop which is undefined throws immediately, and the stack points at the map rather than at the caller, so the message is often more useful than the code.

Hook order. Conditional hooks, hooks after an early return, a hook inside a loop: React reports the violation with the component name, and the fix is almost always to move the hook above the branch rather than to add a guard.

Console warnings that predict later bugs. A missing key, a state update during render, a dependency array that changes on every render. None of these stop the mount, and all three misbehave once real data arrives, which is why they are worth reading on a blank canvas where nothing else is competing for attention.

• Import paths that do not resolve.
• Runtime exceptions on the first render.
• Hook order violations and conditional hooks.
• Warnings that only become bugs with real data.

Read the console, not the preview

A blank preview has three plausible causes: a compile error, a runtime exception, or a component that legitimately renders nothing. Only the console distinguishes them, and this is the single most common reason people conclude that a sandbox is broken when it is not.

The habit worth building is to open the console before you look at the preview. The preview tells you what the user would see, which is nothing useful when the answer is an error; the console tells you why, which is the only information that changes what you do next.

Keep the editor in view too. The point of a sandbox is that you can correct the output and see the fix, and a fifteen-second loop between edit and recompile is what makes generated code practical to repair rather than merely to reject.

When a component mounts cleanly, read the warnings anyway. A clean mount with four warnings is a component that will work until it is given two items in a list or a value that arrives late.

The one tool here that is not offline

Every other tool in the toolbox runs in your browser and uploads nothing. This one does not: the sandbox sends the files to a third-party bundler to compile and run them, which is what makes a live preview possible without shipping a compiler.

That is a reasonable trade for a component you generated five minutes ago and a poor one for source code with your company's name in it. The rule is simple: if the code contains a secret, a customer record, an internal endpoint or anything you would not paste into a public gist, do not put it here. Redact first, or reason about it somewhere else.

It also means the sandbox is the wrong place to test anything that needs credentials. Environment variables, database access and authenticated requests are out of scope by construction, and a component that depends on them will fail here for reasons that have nothing to do with its quality.

Reading the failure output properly

Import failures are the easiest to diagnose and the easiest to misread. The message names the specifier, not the fix, so a failure on a path like @/components/Button usually means the alias is not configured in the sandbox rather than that the component is missing. Check whether the failure is about the module system before rewriting the import.

Runtime exceptions name the component and give a stack that points at the caller, not at the cause. That is why the useful habit is to read the top three frames and then look at what was passed in, rather than reading downward looking for a bug in the component. React's own error codes are worth looking up: many of them describe a hook or a rendering rule rather than a logic mistake.

Hydration and strict-mode warnings are the ones people skip. Text content mismatch, invalid nesting, a state update during render: each will surface differently in production and each has a one-line fix that is much cheaper now than after a deploy.

Keep the console visible while you edit. A fix that removes one error often introduces a warning, and the loop between editing and recompiling is short enough that reading the new output costs nothing.

What to redact before you paste

Because this is the one tool that leaves the browser, redaction is part of using it. Strip API keys, bearer tokens, database URLs, internal hostnames, customer names, email addresses and anything under NDA. If the component only fails because of the data it receives, replace the data with a shape that triggers the same path rather than the real records.

Environment references are the usual leak. A file that calls an internal endpoint will carry that URL into the sandbox, and the failure that results is about network policy rather than about the component. Replace the fetch with a stub that returns the shape the component expects, and the run tests what you actually wanted to test.

For a component that cannot be sanitised, do not paste it. Reason about it, run the project locally, or ask for a review of the specific function. The sandbox is a convenience for cheap iterations, not a mandatory step, and the rest of the toolbox remains offline.

If you are unsure, treat the code as public. That test is quick, unambiguous, and it is the same test you would apply before pasting into any third-party tool.

A checklist for generated components

A mount is the first item, not the last. The useful review of a generated component runs from cheap and mechanical to expensive and judgemental, and the sandbox covers only the first step.

What follows is a direct read: props that arrive undefined, effects that never clean up, handlers that fire on every keystroke, state that duplicates something derivable. Each of those passes the mount and fails in use.

Then the boundary questions. What happens when the list is empty, when the request fails, when the component is unmounted mid-flight? Generated components are strong in the middle and weak at the edges, which is the same observation that applies to generated code of every kind.

• Does it mount, with the console open and clean.
• Are props defended, or only assumed.
• Do effects clean up, and do handlers fire at the right rate.
• What renders when the data is empty, loading or failed.
• Is anything security-relevant: auth, money, personal data.

The components that should not be generated

Some components deserve a run in a sandbox and some deserve a different process entirely. Anything handling authentication, payment state, access rules or personal data should not begin life as generated code with a visual review, because the failures that matter are invisible on screen.

The exception is the purely presentational component: a card, a table row, a badge. Generation is good at those, the failure modes are visual, and a mount plus a read is a proportionate review. Knowing which category you are in before you start saves an afternoon of the wrong kind of checking.

What a clean run actually proves

It proves the component compiles and survives its own default state. That is a real and underrated result: most generated components that fail in production fail at exactly this stage.

It does not prove the component works. There are no real props, no authenticated user, no API, no server data and no second render with changed state. A component can mount beautifully and then do the wrong thing the moment it receives a list of two items.

Nor does it prove anything is safe. Logic that touches money, permissions or personal data needs a review by someone who does that work professionally, and a sandbox run is not a substitute for it.

The honest summary is that running the code removes the cheapest class of failures so that human attention is spent on the expensive ones. It is the same principle as every other tool in the box, applied to a different kind of artefact.