Your console fills up with red text, and near the top sits some version of TypeError: Cannot read properties of undefined (reading 'name'). Nothing about that sentence feels helpful on first read — but it's actually one of the more precise errors JavaScript gives you. It's just easy to misread under pressure.
The error isn't saying your program is broken. It's saying: at this exact line, you tried to read a property off a value that turned out to be undefined. That's a narrow, specific claim — and once you know how to read it, the fix is usually mechanical.
What the error is actually telling you
Take this code:
const user = users.find(u => u.id === targetId);
console.log(user.name);
// TypeError: Cannot read properties of undefined (reading 'name')
Read the message right to left. (reading 'name') tells you which property access failed — .name. Cannot read properties of undefined tells you what it was trying to read .name off of — something that was undefined. Put together: whatever sits to the left of .name in your code — here, user — wasn't what you expected it to be.
The message never claims .name itself is the problem. .name is just where the crash became visible. The real question is always one step earlier: why was user undefined in the first place? In this example, .find() returns undefined when nothing matches — so either targetId is wrong, or the user genuinely isn't in the list yet.
The fix, step by step
-
Read the property name in the error (
'name'in this case) — that tells you which line and which access failed, nothing more. - Trace back to where the undefined value came from. Find the line that assigned, returned, or fetched it.
-
Ask why it's undefined there, specifically. Common causes: an array method (
.find,.pop, array indexing) that found nothing, a destructured key that doesn't match the actual object shape, or code that runs before an async fetch has resolved. - Fix the actual cause, not just the crash site. If the value can legitimately be missing sometimes, guard for it deliberately. If it should never be missing, the bug is upstream — a typo, a wrong assumption about timing, or a mismatched API response shape.
-
Confirm with a
console.logright before the crashing line before you touch anything — print the variable itself, not just the property, so you can see exactly what you're working with.
Two mistakes worth knowing about ahead of time
Reaching for ?. as a reflex instead of a decision. Optional chaining (user?.name) makes the error go away, but it doesn't answer why user was undefined. Sometimes that's the right call — the data is genuinely optional. Other times it quietly hides a real bug, the same way a bare except: in Python swallows errors you actually needed to see. Use ?. when missing data is expected and handled; don't use it just to make red text disappear.
Assuming the crash line is where the bug lives. The value was usually already wrong several lines — or several files — earlier. A common version of this: reading props.data.items before an API call has actually resolved, because the component rendered on the very first pass with no data yet. The crash shows up wherever the property access happens, not wherever the value went wrong.
A debugging habit that works
Before changing anything, console.log() the variable itself, one line above the crash — not the property, the whole thing. If it's undefined, walk backward: where was it supposed to be set, and did that code actually run before this line did? Async timing is the single most common root cause behind this error in real apps — check whether you're reading data before a fetch, await, or state update has actually completed.
Once you know why it's undefined, the fix is usually one of two things: guard for it on purpose with ?. and a sensible fallback (user?.name ?? "Unknown"), or fix whatever upstream logic is producing an empty value when it shouldn't be. Both are valid — just make sure you know which one you're doing, rather than reaching for ?. and moving on before you find out.
This post is adapted from the JavaScript Essentials Companion Guide — a practical, no-fluff guide to JavaScript for developers who want to understand it, not just copy it.
Top comments (2)
This is a great explanation, especially the point about fixing the cause instead of blindly adding ?.. I've definitely seen optional chaining hide an upstream data or timing issue. Tracing where the undefined value actually came from is usually much more useful than just silencing the error.
Exactly — that's the trap.
?.makes the error disappear, but the reason the value was missing is still sitting there waiting to bite you somewhere else. I've started treating every unexpectedundefinedas a "who's supposed to be sending this and why aren't they" question before I even think about chaining. Appreciate you calling that out — it's the kind of thing that's easy to gloss over in a short post but matters a lot in practice.