Feature request
CalendarList renders its months into a hardcoded FlatList with no way to substitute a different list implementation:
https://github.com/wix/react-native-calendars/blob/master/src/calendar-list/index.tsx
<FlatList
ref={list}
windowSize={...}
data={items}
renderItem={renderItem}
...
/>
CalendarListProps already extends Omit<FlatListProps<any>, 'data' | 'renderItem'>, so every prop of the list is configurable — but the component itself isn't. There's no renderScrollComponent-style escape hatch either.
Why it matters
Several common setups need a different list component rather than different list props:
- Nested scrolling containers —
BottomSheetFlatList from @gorhom/bottom-sheet, or any list that has to coordinate with a parent gesture handler. Passing a plain FlatList's props doesn't help; the container has to be the sheet's list or the inner scroll doesn't work.
- Extra content inside the scroll area — our own case: we wrap the list to render a contextual notice above the months, inside the same scroll container, which
ListHeaderComponent alone doesn't cover for our layout.
- Alternative list engines —
FlashList and similar, for long pastScrollRange / futureScrollRange values.
Today the only options are patching the package or forking CalendarList, both for what amounts to one indirection.
Proposed change
Accept an optional list component and default to FlatList, preserving current behaviour exactly:
export interface CalendarListProps extends CalendarProps, Omit<FlatListProps<any>, 'data' | 'renderItem'> {
...
/** Custom list component to render the months into. Default = FlatList */
List?: FC<FlatListProps<any>>;
}
const List = props.List ?? FlatList;
return (
<View style={style.current.flatListContainer} testID={testID}>
<List ref={list} ... />
{renderStaticHeader()}
</View>
);
That's the whole change — a prop, a default, and swapping the JSX tag. Fully backwards compatible: omitting List gives byte-identical behaviour to today, and every existing list prop keeps flowing through untouched.
Notes
- We've run exactly this as a local patch for a while against
1.1314.0 with no issues, including the imperative scrollToDay / scrollToMonth methods, which keep working since the ref is forwarded unchanged.
- Naming is yours to pick —
List, ListComponent, renderScrollComponent (matching RN's own naming) would all work. Happy to open a PR in whichever shape you'd prefer, and to include the type as ComponentType<FlatListProps<any>> if you'd rather not narrow it to FC.
Feature request
CalendarListrenders its months into a hardcodedFlatListwith no way to substitute a different list implementation:https://github.com/wix/react-native-calendars/blob/master/src/calendar-list/index.tsx
CalendarListPropsalready extendsOmit<FlatListProps<any>, 'data' | 'renderItem'>, so every prop of the list is configurable — but the component itself isn't. There's norenderScrollComponent-style escape hatch either.Why it matters
Several common setups need a different list component rather than different list props:
BottomSheetFlatListfrom@gorhom/bottom-sheet, or any list that has to coordinate with a parent gesture handler. Passing a plainFlatList's props doesn't help; the container has to be the sheet's list or the inner scroll doesn't work.ListHeaderComponentalone doesn't cover for our layout.FlashListand similar, for longpastScrollRange/futureScrollRangevalues.Today the only options are patching the package or forking
CalendarList, both for what amounts to one indirection.Proposed change
Accept an optional list component and default to
FlatList, preserving current behaviour exactly:That's the whole change — a prop, a default, and swapping the JSX tag. Fully backwards compatible: omitting
Listgives byte-identical behaviour to today, and every existing list prop keeps flowing through untouched.Notes
1.1314.0with no issues, including the imperativescrollToDay/scrollToMonthmethods, which keep working since therefis forwarded unchanged.List,ListComponent,renderScrollComponent(matching RN's own naming) would all work. Happy to open a PR in whichever shape you'd prefer, and to include the type asComponentType<FlatListProps<any>>if you'd rather not narrow it toFC.