Got an error like this in your React component?
Cannot read property `map` of undefined
In this post we’ll talk about how to fix this one specifically, and along the way you’ll learn how to approach fixing errors in general.
We’ll cover how to read a stack trace, how to interpret the text of the error, and ultimately how to fix it.
The Quick Fix
This error usually means you’re trying to use .map on an array, but that array isn’t defined yet.
That’s often because the array is a piece of undefined state or an undefined prop.
Make sure to initialize the state properly. That means if it will eventually be an array, use useState([]) instead of something like useState() or useState(null).
Let’s look at how we can interpret an error message and track down where it happened and why.
How to Find the Error
First order of business is to figure out where the error is.
If you’re using Create React App, it probably threw up a screen like this:
Look for the file and the line number first.
Here, that’s /src/App.js and line 9, taken from the light gray text above the code block.
btw, when you see something like /src/App.js:9:13, the way to decode that is filename:lineNumber:columnNumber.
How to Read the Stack Trace
If you’re looking at the browser console instead, you’ll need to read the stack trace to figure out where the error was.
These always look long and intimidating, but the trick is that usually you can ignore most of it!
The lines are in order of execution, with the most recent first.
Here’s the stack trace for this error, with the only important lines highlighted:
TypeError: Cannot read property 'map' of undefined
at App (App.js:9)
at renderWithHooks (react-dom.development.js:10021)
at mountIndeterminateComponent (react-dom.development.js:12143)
at beginWork (react-dom.development.js:12942)
at HTMLUnknownElement.callCallback (react-dom.development.js:2746)
at Object.invokeGuardedCallbackDev (react-dom.development.js:2770)
at invokeGuardedCallback (react-dom.development.js:2804)
at beginWork$1 (react-dom.development.js:16114)
at performUnitOfWork (react-dom.development.js:15339)
at workLoopSync (react-dom.development.js:15293)
at renderRootSync (react-dom.development.js:15268)
at performSyncWorkOnRoot (react-dom.development.js:15008)
at scheduleUpdateOnFiber (react-dom.development.js:14770)
at updateContainer (react-dom.development.js:17211)
at eval (react-dom.development.js:17610)
at unbatchedUpdates (react-dom.development.js:15104)
at legacyRenderSubtreeIntoContainer (react-dom.development.js:17609)
at Object.render (react-dom.development.js:17672)
at evaluate (index.js:7)
at z (eval.js:42)
at G.evaluate (transpiled-module.js:692)
at be.evaluateTranspiledModule (manager.js:286)
at be.evaluateModule (manager.js:257)
at compile.ts:717
at l (runtime.js:45)
at Generator._invoke (runtime.js:274)
at Generator.forEach.e.<computed> [as next] (runtime.js:97)
at t (asyncToGenerator.js:3)
at i (asyncToGenerator.js:25)I wasn’t kidding when I said you could ignore most of it! The first 2 lines are all we care about here.
The first line is the error message, and every line after that spells out the unwound stack of function calls that led to it.
Let’s decode a couple of these lines:
at App (App.js:9)
Here we have:
Appis the name of our component functionApp.jsis the file where it appears9is the line of that file where the error occurred
Let’s look at another one:
at performSyncWorkOnRoot (react-dom.development.js:15008)
performSyncWorkOnRootis the name of the function where this happenedreact-dom.development.jsis the file15008is the line number (it’s a big file!)
Ignore Files That Aren’t Yours
I already mentioned this but I wanted to state it explictly: when you’re looking at a stack trace, you can almost always ignore any lines that refer to files that are outside your codebase, like ones from a library.
Usually, that means you’ll pay attention to only the first few lines.
Scan down the list until it starts to veer into file names you don’t recognize.
There are some cases where you do care about the full stack, but they’re few and far between, in my experience. Things like… if you suspect a bug in the library you’re using, or if you think some erroneous input is making its way into library code and blowing up.
The vast majority of the time, though, the bug will be in your own code ;)
Follow the Clues: How to Diagnose the Error
So the stack trace told us where to look: line 9 of App.js. Let’s open that up.
Here’s the full text of that file:
import "./styles.css";
export default function App() {
let items;
return (
<div className="App">
<h1>List of Items</h1>
{items.map(item => (
<div key={item.id}>
{item.name}
</div>
))}
</div>
);
}Line 9 is this one:
{items.map(item => (
And just for reference, here’s that error message again:
TypeError: Cannot read property 'map' of undefined
Let’s break this down!
TypeErroris the kind of error
There are a handful of built-in error types. MDN says TypeError “represents an error that occurs when a variable or parameter is not of a valid type.” (this part is, IMO, the least useful part of the error message)
Cannot read propertymeans the code was trying to read a property.
This is a good clue! There are only a few ways to read properties in JavaScript.
The most common is probably the . operator.
As in user.name, to access the name property of the user object.
Or items.map, to access the map property of the items object.
There’s also brackets (aka square brackets, []) for accessing items in an array, like items[5] or items['map'].
You might wonder why the error isn’t more specific, like “Cannot read function `map` of undefined” – but remember, the JS interpreter has no idea what we meant that type to be. It doesn’t know it was supposed to be an array, or that map is a function. It didn’t get that far, because items is undefined.
'map'is the property the code was trying to read
This one is another great clue. Combined with the previous bit, you can be pretty sure you should be looking for .map somewhere on this line.
of undefinedis a clue about the value of the variable
It would be way more useful if the error could say “Cannot read property `map` of items”. Sadly it doesn’t say that. It tells you the value of that variable instead.
So now you can piece this all together:
- find the line that the error occurred on (line 9, here)
- scan that line looking for
.map - look at the variable/expression/whatever immediately before the
.mapand be very suspicious of it.
Once you know which variable to look at, you can read through the function looking for where it comes from, and whether it’s initialized.
In our little example, the only other occurrence of items is line 4:
let items;This defines the variable but it doesn’t set it to anything, which means its value is undefined. There’s the problem. Fix that, and you fix the error!
Fixing This in the Real World
Of course this example is tiny and contrived, with a simple mistake, and it’s colocated very close to the site of the error. These ones are the easiest to fix!
There are a ton of potential causes for an error like this, though.
Maybe items is a prop passed in from the parent component – and you forgot to pass it down.
Or maybe you did pass that prop, but the value being passed in is actually undefined or null.
If it’s a local state variable, maybe you’re initializing the state as undefined – useState(), written like that with no arguments, will do exactly this!
If it’s a prop coming from Redux, maybe your mapStateToProps is missing the value, or has a typo.
Whatever the case, though, the process is the same: start where the error is and work backwards, verifying your assumptions at each point the variable is used. Throw in some console.logs or use the debugger to inspect the intermediate values and figure out why it’s undefined.
You’ll get it fixed! Good luck :)