Repository navigation
Example showing need for FlatList extraData prop is misleading #5216
Description
Basically #1529 from 2019 which was closed due to inactivity.
Related: #2634 which attempted to address this but unfortunately received no attention.
Description
The second example at https://reactnative.dev/docs/flatlist#example is introduced with
By passing
extraData={selectedId}toFlatListwe make sureFlatListitself will re-render when the state changes. Without setting this prop,FlatListwould not know it needs to re-render any items because it is a PureComponent and the prop comparison will not show any changes.
But if you delete the extraData prop everything works fine. Since renderItem closes over selectedId, it is recreated whenever selectedId changes (or on every single render if the react compiler is disabled), hence FlatList receives a new prop and re-renders properly as you'd expect.
Which makes me wonder: is there ever a need for extraData? Was it once necessary (perhaps in class component days, or old react native architecture) and is no longer needed?
I'm struggling to think of a scenario in which it's needed, other than an escape hatch for syncing with something outside react, or to opt back in to reactivity after making manual memoizations.
Currently the docs suggest it's necessary to make basic reactivity work, which is confusing.
Documentation version
0.87
Activity
theprantadutta commentedon Aug 29, 2026
I dug through the current
FlatList/VirtualizedListsource to try to answer the "isextraDataever needed?" question, since that determines what the fix should say. Short version: you're right that the sentence is misleading, butextraDataisn't vestigial — it just doesn't do what the docs claim it does.Why the example works without it. In that example
renderItemis an inline closure overselectedId, so it's a new function identity on every render. By defaultFlatListpasses the renderer straight through:With
strictModeunset,_rendererruns on every render andVirtualizedListreceives new item-render props regardless ofextraData. So removing it changes nothing here — exactly what you observed.Where it is load-bearing. Two places I can find:
extraDatais an argument to_renderer(...), and_memoizedRendererismemoizeOne(this._renderer). WhenstrictModeis enabled (documented as "Enable an optimization to memoize the item renderer to prevent unnecessary rerenders"), the memoized renderer is only rebuilt when one of its arguments changes —extraDataamong them. With a stablerenderItem(module-scope, oruseCallbackwith stable deps) plusstrictMode,extraDatais what tells the list something it renders from has changed.VirtualizedList.componentDidUpdatecomparesdataandextraDatato reset the viewability cache soonViewableItemsChangedfires again. That path is independent of item rendering.So the accurate framing is roughly:
extraDatatells the list that somethingrenderItemdepends on changed, when that change isn't visible indataor in the identity ofrenderItemitself. The current text instead says the list "would not know it needs to re-render any items because it is aPureComponent", which is the part that doesn't hold up — and it reads as though basic reactivity depends on it.What I'd propose, if a maintainer agrees with the direction: rewrite that bullet along the lines above, and either drop
extraDatafrom the example or add a one-line note that it's redundant there becauserenderItemis inline. I'd rather not guess how muchstrictMode/ viewability detail belongs in a beginner-facing example, which is the one thing I'd want steering on.Happy to open that PR straight away — say the word and which shape you'd prefer. (@Simek, you reviewed my last docs PR here, so tagging you in case this is on your patch.)
Caveat on my evidence: this is reading current
mainsource, not a runtime repro — I don't have an Android/iOS setup to hand. If anything above doesn't match observed behaviour, trust the runtime over me.docs: clarify FlatList extraData prop and PureComponent behavior (fixes