Can renderItem close over state?

[mdj-uk]

Something like this works fine in FlatList and FlashList, but results in stale UI in LegendList:

<LegendList
    data={DATA}
    renderItem={({ item }) => (
        <Item
            item={item}
            onPress={() => setSelectedId(item.id)}
            isSelected={selectedId === item.id}
        />
    )}
    keyExtractor={(item) => item.id}
/>

When renderItem changes - for example because the selectedId state it closes over changes, or because we've disabled the react compiler so it's recreated on each render - LegendList does not re-render its items. So the selected item never seems to change.

Just curious if this is intentional behaviour or not?

I think the situation is a bit confusing because the FlatList docs use this exact example to teach you to use the extraData prop, but it's actually completely unnecessary. (See 2nd example at https://reactnative.dev/docs/flatlist#example and its surrounding text.) In both FlatList and FlashList you can remove extraData and it works fine. But in LegendList you need to add extraData={isSelected}, or change how/where the state is stored.

If it is intentional then fair enough :-) I doubt there's any way to tell from within LegendList whether renderItem has changed meaningfully or not. So I guess you'd have to rely on the compiler memoizing it, or the user wrapping it in useCallback with the correct dependency array - which I appreciate could tank performance for many users!

Demo: https://github.com/mdj-uk/legend-list-closure-demo

(Aside: is there a way to share a demo with expo snack? When I try there's an error message saying "This package cannot be bundled for the Snack runtime because it depends on modules that are unavailable in the browser or on native platforms")

[sambai-dev]

Confirmed against source (main @ 8beb228, ahead of the published 3.3.8): row content is memoized per container with dependencies [itemKey, data, extraData], and renderItem identity plays no role in invalidating it.

• The row renderer in src/components/Container.tsx builds the item element inside a useMemo keyed on [itemKey, data, extraData]. A newly created renderItem closure does not appear anywhere in that chain, so it cannot trigger row re-renders.
• The newest renderItem is written into the shared props snapshot on every render of the inner list component (src/components/LegendList.tsx), and getRenderedItem (src/utils/getRenderedItem.ts) calls whatever function is current and passes extraData through to its props. So rows always run fresh code once something else invalidates them, but nothing in the invalidation path watches the function itself.
• The documented contract matches: in src/types.base.ts, extraData?: any is described as "Extra data to trigger re-rendering when changed."

It appears intentional, and extraData={selectedId} is the designed fix for your exact example. This also explains the FlatList contrast: as you observed, FlatList cells happen to re-render through prop propagation when renderItem changes, while legend-list gates row rendering explicitly on declared data. (I verified the legend-list side in this session; I have not verified the React Native side.)

On whether the list could detect a meaningful renderItem change: I believe no signal based on function identity would be sound. A useCallback'd renderItem with an incomplete dependency array looks "unchanged" while still closing over an old selectedId, which would silently render wrong selection state. Keying invalidation on declared data makes stale closures a visible, debuggable failure mode instead of a silent one.

What works today:

1. extraData={selectedId}: feeds both the memo gate in Container.tsx and the extraData prop handed to renderItem.
2. Moving selection into the data items themselves (your last suggestion): then data identity changes drive re-renders with no additional prop.
3. useCallback with correct dependencies also works, at the re-render cost you noted.

A related datapoint consistent with this mechanism: #271 (closed) reported focus loss specifically when extraData updates forced row re-renders.

Caveat: verified against main; file paths and behavior can shift between versions.