List flickers on drop commit (iOS & Android) — New Arch / RN 0.79

[OmkarK45]

Description

After a drag-and-drop operation completes (on onDragEnd), the list briefly flickers — all rows flash white/transparent for one frame before settling into their final positions. This is reproducible on both iOS Simulator and Android.

Steps to reproduce

1. Render a DraggableFlatList with a mixed list (section headers + draggable rows — see reproduction below)
2. Drag an item and release it to commit the drop
3. Observe a one-frame flicker across the entire list immediately after drop

What I've tried

• Removed all useOnCellActiveAnimation / useAnimatedStyle usage from renderItem — flicker persists
• Replaced every Animated.View in cell renderers with plain View — flicker persists
• Commented out section-header rows so the list is uniform item type — flicker persists
• The flicker does not occur in a similar drag-and-drop list in our app that uses DraggableFlatList in a simpler setup on an older RN version

Environment

react-native-draggable-flatlist	4.0.3
react-native	0.79.4
react	19.0.0
New Architecture	Enabled
Platform	iOS Simulator + Android (both affected)

Minimal reproduction

import DraggableFlatList, { type DragEndParams } from 'react-native-draggable-flatlist';
import { useState, useCallback } from 'react';
import { View, Text, Pressable } from 'react-native';

type SectionItem = { key: string; type: 'section'; title: string };
type RowItem = { key: string; type: 'row'; label: string };
type ListItem = SectionItem | RowItem;

const INITIAL_DATA: ListItem[] = [
  { key: 's-1', type: 'section', title: 'Section A' },
  { key: 'a-1', type: 'row', label: 'Item A1' },
  { key: 'a-2', type: 'row', label: 'Item A2' },
  { key: 'a-3', type: 'row', label: 'Item A3' },
  { key: 's-2', type: 'section', title: 'Section B' },
  { key: 'b-1', type: 'row', label: 'Item B1' },
  { key: 'b-2', type: 'row', label: 'Item B2' },
  { key: 'b-3', type: 'row', label: 'Item B3' },
  { key: 's-3', type: 'section', title: 'Section C' },
  { key: 'c-1', type: 'row', label: 'Item C1' },
  { key: 'c-2', type: 'row', label: 'Item C2' },
  { key: 'c-3', type: 'row', label: 'Item C3' },
];

export default function Demo() {
  const [data, setData] = useState(INITIAL_DATA);

  const renderItem = useCallback(({ item, drag, isActive }) => {
    if (item.type === 'section') {
      return (
        <View style={{ padding: 12, backgroundColor: '#e0e0e0' }}>
          <Text style={{ fontWeight: 'bold' }}>{item.title}</Text>
        </View>
      );
    }
    return (
      <View style={{ padding: 16, backgroundColor: isActive ? '#eee' : '#fff', borderBottomWidth: 1, borderColor: '#ddd' }}>
        <Text>{item.label}</Text>
        <Pressable onPressIn={drag}><Text>drag</Text></Pressable>
      </View>
    );
  }, []);

  const onDragEnd = useCallback(({ data: newData }: DragEndParams<ListItem>) => {
    setData(newData);
  }, []);

  return (
    <DraggableFlatList
      data={data}
      keyExtractor={item => item.key}
      renderItem={renderItem}
      onDragEnd={onDragEnd}
    />
  );
}

Notes

Suspicion is that this is a New Architecture / Fabric reconciliation issue — the list re-renders all cells synchronously after setData is called in onDragEnd, and the one-frame flash may be Fabric unmounting/remounting cell wrappers before the new layout is committed. Would be happy to test any suggested workaround.

[OmkarK45]

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-06-12.at.12.57.16.mov

[OmkarK45]

Follow-up findings after further investigation:

Calling setListKey(k => k + 1) (forcing a full remount) on every onDragEnd significantly reduces the flicker — most cells are clean after drop. However, there is still a single-frame flicker on the last visible item in the viewport (the last item that fits on screen, not the literal last item in the list).

In our case the last visible item happens to be a section header (a non-draggable row rendered differently from draggable rows), but this may just be coincidental — it appears to be a viewport boundary issue rather than specific to section headers.

Repro still uses the sectioned data array from the original report. Steps are the same. The per-drop key reset is a partial workaround, not a fix.