Good to see you again. Last time, you changed the words inside a Text component and confirmed the new text appeared in Expo Go. That established your basic edit-and-check loop.
This lesson adds an essential companion skill: repairing code when one small typing mistake stops the app from running. You will deliberately create a safe syntax error, use Expo Snack’s feedback to find it, restore the correct code, and verify that Expo Go works again. Plan for about 30 minutes.
What a syntax error is
Code has a grammar. In JSX, the language used to describe React Native screens, symbols such as <, >, /, {, and } are part of that grammar.
This is valid JSX:
<Text>My task tracker</Text>
The opening tag is <Text>. The closing tag is </Text>. Both need their final > character.
Here is a syntax error:
<Text>My task tracker</Text
One > is missing. Although the line looks almost right to a person, the computer cannot correctly interpret it. Snack cannot build the app, so Expo Go may show a red error screen rather than your interface.
Syntax errors are usually caused by small structural mistakes:
| Mistake | Broken code | Repair |
|---|---|---|
| Missing closing angle bracket | <Text>Hello</Text | Add > |
| Missing closing tag | <Text>Hello | Add </Text> |
Closing tag missing / | <Text>Hello<Text> | Change the second tag to </Text> |
| Extra character in a tag | <Textt>Hello</Text> | Restore Text exactly |
The key idea is: the error is often close to the line you just changed. Do not start changing random parts of the project. First identify the reported location, then compare the nearby code with the correct pattern.
What Snack and Expo Go are telling you
When a serious error prevents an Expo app from running, Expo Go displays a Redbox error screen. A warning may use a less severe message, but an error that stops the preview deserves immediate attention.
Errors and warnings - Expo Documentation
Read this short Expo Documentation guide to distinguish a fatal error from a warning and understand why the error message and stack trace are useful clues rather than something to ignore.
In “Redbox error and Yellowbox warning,” read the error-versus-warning explanation. Then, in “Stack traces,” read the stack-trace explanation. Focus on the idea that an error report identifies a file and often a line number; on your phone, App.js or App.tsx is the file you will usually inspect first.
A stack trace is the longer technical list beneath an error message. At this stage, you do not need to understand every entry. Use it as a location clue:
- Find the clearest error message near the top.
- Look for a file name, commonly
App.jsorApp.tsx. - If a line number is shown, open that line in Snack.
- Inspect the line itself and the few lines just above it.
A parser sometimes notices a missing character only when it reaches the next line. So a reported line is a strong clue, not a guarantee that the exact bad character is on that line. Check the component tag you most recently edited as well.

On a phone-sized browser, the editor may not show the same layout as this image. You may need to scroll below the code area, tap an error indicator, or look for a red error message in the Snack interface. The essential information is still the same: read the first clear message, find the named file or line, and inspect locally.
Create one safe, intentional error
You will use the same Text line you successfully edited in the previous lesson. Before changing it, make sure the project currently works in Expo Go. If it does not, restore it to the last known working version first.
In Snack, open App.js or App.tsx and find your visible text. It might look like this:
<Text>My task tracker</Text>
Make only this controlled edit: remove the very last > on the line.
<Text>My task tracker</Text
Then pause. Do not make any other changes.
Snack should detect an error after a moment. The exact wording depends on the current Snack and React Native versions, but it may mention an unexpected end, an expected >, JSX, or a parsing error. Expo Go may change from the app preview to a red error screen.
This controlled mistake is useful because you know exactly what changed. In future projects, you will not always know immediately, but the same method applies.
Read the report before repairing
Take a moment to observe these details:
- Does Snack identify
App.jsorApp.tsx? - Is a code line marked red, underlined, or listed in an error panel?
- Does Expo Go show a red error screen instead of your task-tracker text?
- Does the message suggest that Snack could not understand the code’s structure?
You are not expected to memorize the message. Error text can vary. What matters is the diagnosis:
I made a structural change to a
Textclosing tag, and the app stopped compiling. The reported location points me back to that area.
Do not confuse this with a stale preview. If the app still displays the older working screen, wait briefly and check Snack for an error indicator. A syntax error should prevent the changed code from running successfully.
Restore the exact valid structure
Now repair only the character you removed. Your line must finish with:
</Text>
The complete result should be:
<Text>My task tracker</Text>
Check it slowly:
- The opening tag begins with
<. - The component name is
Text, with a capitalT. - The words are inside the two tags.
- The closing tag begins with
</. - The final
>is present.
Wait for Snack to re-check the code. The red error message should disappear or be replaced by a successful status. Then switch back to Expo Go. Your normal app screen should return, showing the text you chose.
This is the full repair loop:
- Notice that the app does not run.
- Read the reported file and location.
- Inspect the small region around the indicated code.
- Compare it with the required JSX pattern.
- Repair the smallest mistake possible.
- Verify that Snack and Expo Go are working again.
A successful repair is not complete until the app actually returns in Expo Go. Clearing an error marker in the editor is encouraging, but seeing the running screen confirms that the project can build and load on your Moto G.
When an error message looks intimidating
Some red screens contain a long stack trace with file paths and unfamiliar technical terms. That is normal. The screenshot below is an example of a red Expo Go screen with a detailed module-loading failure.

For the syntax error you created, the most useful evidence is usually in Snack because that is where you edited the source code. Start with the short message and nearby marked line rather than trying to interpret every stack-trace entry.
Use these rules when you encounter errors later:
- Work from the most recent change. If you changed one line, inspect that line first.
- Make one repair at a time. Several speculative edits can create new errors and hide the original problem.
- Preserve known-good code. If only one tag is damaged, do not rewrite the whole file.
- Read exact punctuation. In JSX,
</Text>and<Text>are different structures; one slash matters. - Verify after every repair. A working preview is evidence, not merely a guess.
If your error does not disappear after restoring >, compare your entire line to the working pattern above. Check especially for an accidental deleted <, an extra slash, or a changed component name. If it still does not work, use Snack’s undo control once or twice until the line matches its earlier version, then wait for the preview to update.
Finish with a reliable debugging habit
Before you end the session, confirm each item:
- I located the
Textline inApp.jsorApp.tsx. - I intentionally removed one
>and saw Snack or Expo Go report an error. - I used the error feedback and my most recent change to identify the affected area.
- I restored the line to a valid form ending in
</Text>. - Snack no longer reports the syntax error.
- Expo Go once again displays the running app.
You can now handle the first and most common kind of beginner coding problem: a small syntax mistake that prevents the app from running. A red error screen is not a verdict on your project; it is a report that narrows your search to a file, a location, and a structural rule.
The next module moves from JSX editing to JavaScript building blocks. You will begin representing task information with values declared using const and let.
Can't find a good explanation? Sign up and we'll make it for you
Sign up