Editing, Reloading, and Reading Errors
The project now has a complete path from index.html to visible DOM nodes. That path also gives errors an order.
read source
-> resolve imports
-> transform JSX
-> evaluate modules
-> render components
-> commit DOM
-> handle later eventsA failure at one step prevents later steps from using the new code. A JSX syntax error never reaches component rendering. A click-handler error occurs after the screen has already rendered. A wrong result can reach every step without throwing an exception.
Build a repair routine around that order. Create a small failure on purpose, read its report, restore the code, and confirm the page after the repair.
Keep Four Reports Available
The editor, terminal, browser overlay, and browser console report related but different information.
The editor can mark syntax, lint, and type issues near source before the file is saved. Its report depends on installed extensions and project configuration.
The terminal holds the Vite process. It reports server startup, module resolution, transformation, and build-tool failures.
The browser overlay displays development failures sent by Vite or reported while the page runs. It is designed to make the current blocking error visible over the application.
The browser console records runtime exceptions, React warnings, browser warnings, and application logs.
One error can appear in more than one report. The repeated message does not prove that several unrelated failures occurred.
Arrange the editor beside the browser and keep the Vite terminal visible. Open the browser Console panel. Clear old output before each controlled failure so you can connect the report to the action that caused it.
A Successful Edit Has Observable Steps
Change the chapter heading.
function ChapterHeading() {
return <h1>The First React Screen, Complete</h1>;
}Save the file. Vite notices the saved source, transforms the module, and sends a development update. The browser displays the new text.
Confirm two results after saving.
- The terminal accepted the changed module.
- The browser displayed output from that module.
If the browser does not change, do not classify the problem as a React render failure immediately. Confirm that the editor saved the correct file, Vite accepted it, and the browser is connected to the printed development URL.
Begin with the First New Error
One invalid line can cause several follow-on reports. A parser failure may prevent an import, which leaves an update unavailable, which causes the browser overlay to remain.
Read the first new report produced after the edit. Locate these parts.
error category or message
source file
line and column
nearby source excerpt
stack or import chain when presentThe line and column identify where a tool could no longer continue. The original mistake can appear earlier, particularly for a missing quote, brace, parenthesis, or closing tag.
Repair one cause, save, and read the reports again. Do not change several unrelated files from one error screen.
Transform Failure from Invalid JSX
Remove the closing h1 tag.
function ChapterHeading() {
return <h1>The First React Screen;
}Vite cannot transform the module into executable JavaScript. The terminal and overlay report App.jsx with a line and column near the invalid JSX.
The page may keep the last valid component output behind the overlay. That old output does not mean the broken file ran. Vite retained the previous valid module because no replacement module could be produced.
Restore the closing tag.
return <h1>The First React Screen</h1>;Save and wait for the overlay to clear.
Another transform failure comes from adjacent return expressions.
return (
<h1>The First React Screen</h1>
<p>Six lessons</p>
);One return needs one expression. Wrap the elements in main or another appropriate parent.
Module Resolution Failure
Change the App import in main.jsx.
import App from "./Application.jsx";No file exists at that relative path. Vite reports that it failed to resolve the import from main.jsx.
Read a relative import from the importing file's directory. ./Application.jsx means a file beside main.jsx, not beside the project root or the current terminal prompt.
Check four facts.
- The target file exists.
- Every directory and filename uses the stored letter case.
- The relative path begins at the importing file.
- The written extension matches the file when an extension is included.
Restore the generated import.
import App from "./App.jsx";Case deserves a deliberate check. A case-insensitive local file system can accept ./app.jsx for a file named App.jsx, while a case-sensitive deployment rejects it. Match source casing exactly even when the local machine accepts a variation.
Reinstalling packages does not create a missing local source file. Follow the unresolved specifier from the importing file.
Module Evaluation Failure
Valid syntax can still fail while a module executes.
Add a top-level call to a missing function.
initializeLessons();
export default function App() {
return <h1>ReactBook</h1>;
}The JSX transforms successfully. The browser begins evaluating the module and JavaScript throws a ReferenceError because no binding named initializeLessons exists.
The component is never available to React because module evaluation stopped first.
module transformed
module evaluation failed
App export was not completed
React could not render the new moduleRemove the call. This class of error differs from a component render error even though both appear in the browser runtime.
Component Render Failure
Use an undefined binding inside the component.
function ChapterHeading() {
return <h1>{chapterTitle}</h1>;
}The module can load because a missing variable name is valid JavaScript syntax. The failure occurs when React calls ChapterHeading and JavaScript evaluates the expression.
ReferenceError: chapterTitle is not definedThe JavaScript stack records function calls involved in the exception. React development reporting can also include a component stack.
ChapterHeading
AppThe JavaScript stack helps locate executable source. The component stack shows the React nesting that led to the component. They answer different questions.
Define the binding before use.
function ChapterHeading() {
const chapterTitle = "The First React Screen";
return <h1>{chapterTitle}</h1>;
}Open the first useful stack frame that belongs to your src directory. Frames inside React and Vite explain library calls around the error, but application repair normally begins at the source expression that supplied the invalid operation.
A Component Can Throw a Deliberate Error
A component can reject an invalid requirement.
function ChapterHeading({ title }) {
if (!title) {
throw new Error("ChapterHeading requires title");
}
return <h1>{title}</h1>;
}Render it without the input.
<ChapterHeading />The message identifies the requirement and the component stack identifies the failed occurrence. Restore a title after observing the report.
<ChapterHeading title="The First React Screen" />The prop makes the render exception intentional, distinguishing it from a parser or import failure.
For this controlled local failure, the development overlay supplies the report you need.
Event Handler Failure
A page can render correctly and fail only after interaction.
function ContinueButton() {
function handleClick() {
openNextLesson();
}
return <button onClick={handleClick}>Continue</button>;
}The component renders because defining handleClick does not run its body. Clicking the button calls the handler and JavaScript reports that openNextLesson is not defined.
The existing screen can remain visible. React did not fail while calculating the component tree. An event callback failed after commit.
The component rendered successfully. The failure happened only after the click.
Warnings Can Leave Visible Output
React can report a warning without aborting the render. A list with missing keys can remain visible while the console explains that React cannot identify its items reliably across updates.
A visible page therefore does not mean the console is clean. Read warnings and follow the named component before continuing.
Warnings should not be hidden through broad console filters. A targeted repair keeps later reports visible.
Exceptions and warnings have different effects, but both carry information about source behavior that needs review.
Wrong Output Without an Error
Valid code can calculate the wrong result.
const total = 6;
const completed = 2;
function LessonProgress() {
return <p>{total - completed} lessons complete</p>;
}The page displays 4 lessons complete. Every tool can parse, resolve, evaluate, render, and commit this code. The expression does not represent the intended value.
Inspect the current values and the calculation.
return <p>{completed} lessons complete</p>;Use a temporary console log or debugger breakpoint when several values feed the calculation. React DevTools shows props and state directly. Remove temporary logs after locating the value source.
Correct DOM with Wrong Presentation
The Elements panel can show the correct heading and class while CSS hides it.
.chapter-title {
color: transparent;
}React completed its work. The browser applied a CSS value that made the text invisible.
Inspect the element and its computed styles. If the expected class is absent, return to component output. If the class is present and the computed rule is wrong, inspect the stylesheet and cascade.
This prevents a styling failure from being treated as a root or render failure.
Source Maps Point Back to JSX
The browser executes transformed JavaScript. Vite provides development source maps that connect generated positions back to src/App.jsx and other original files.
That connection allows a stack frame to open the JSX line you wrote rather than a generated helper call. Keep source maps active during development.
Production source maps require a deployment decision. Publicly served maps can expose application source. Private error-monitoring uploads can retain debugging value without serving maps to every browser.
Reload, Restart, or Repair
Choose the response that matches the failed layer.
Repair and save for normal source syntax, missing bindings, wrong expressions, and local import paths.
Reload the browser to test a clean client start or clear state preserved by development updates.
Restart Vite after dependency installation, selected configuration changes, environment-file changes, or a stopped server process.
Reinstall dependencies only when installation state or package resolution is involved. It has no connection to a missing JSX close tag.
source failure -> repair source
stale page state -> reload page
server input changed -> restart Vite
package state failed -> inspect npm installationUse One Repair Routine
Apply the following sequence after a new failure.
- Reproduce it with one save, load, or interaction.
- Read the first new report.
- Identify the stage that produced it.
- Open the first relevant application source location.
- State what value or syntax was expected there.
- Make the smallest repair that restores the requirement.
- Save and confirm the report clears.
- Repeat the original action.
- Perform one clean browser reload.
The sixth step prevents unrelated cleanup from entering a bug repair. Once the behavior is restored, a separate refactor can have its own review.
Check the Full Trace
Trace the running screen without skipping a layer.
index.html creates div#root
main.jsx finds that DOM node
createRoot creates one React root
root.render receives an App element
React calls App and nested components
JSX produces React element descriptions
React DOM commits host nodes
the browser applies CSS and paintsYou can also place a failure before transform, during import resolution, during module evaluation, during component rendering, after an event, or in visible application logic.
Source Notes
- Vite documentation, Troubleshooting
- Vite documentation, Features
- React documentation, React Developer Tools
- MDN, Error stack