Forem: Nitish Poonia

Optimizing Re-renders in React Native: React.memo, useCallback, useMemo — When They Actually Help

Nitish Poonia — Thu, 05 Mar 2026 11:47:35 +0000

React.memo, useCallback, and useMemo are the most misunderstood performance
tools in React Native. Most developers either ignore them entirely and
wonder why their lists re-render constantly, or wrap everything in all three
and wonder why their app feels slower than before. Neither approach is right.

This post covers what these tools actually do at the mechanics level, the
most common ways they are misused, how to measure whether they are genuinely
helping, and how to know when not to use them at all.

What Re-renders Actually Are

Before optimising re-renders, you need to be precise about what a re-render
is and what it costs.

A re-render in React means the component function runs again. React calls
your function, gets a new JSX tree, diffs it against the previous one, and
applies only the changes to the native view layer. The function running
again does not necessarily mean anything visible changes on screen.

The cost of a re-render has two parts. First, the cost of running the
function itself — executing your JavaScript, computing derived values,
creating new objects. Second, the cost of reconciliation — React diffing
the old and new JSX trees. For simple components this is microseconds.
For complex components with deep trees it can be meaningful.

The mistake most developers make is assuming all re-renders are expensive.
Most are not. Optimising a component that renders in 0.1ms is wasted effort
that adds complexity without improving anything the user experiences.

React.memo — What It Does and When It Helps

React.memo is a higher-order component that wraps your component and
memoises the last rendered output. Before re-rendering, it does a shallow
comparison of the previous and current props. If nothing changed, it skips
the render entirely and returns the cached output.

const PostCard = React.memo(({ post, onPress }) => {
  return (
    <Pressable onPress={onPress}>
      <Text>{post.title}</Text>
      <Text>{post.subtitle}</Text>
    </Pressable>
  );
});

React.memo genuinely helps in one specific scenario: a parent component
re-renders frequently, but a child component's props rarely or never change.
The canonical example is a FlatList item component whose parent re-renders
on scroll events or state changes unrelated to the list data.

// Parent re-renders on every scroll event due to scroll position state
export default function FeedScreen() {
  const [scrollY, setScrollY] = useState(0);

  return (
    <FlatList
      data={posts}
      onScroll={e => setScrollY(e.nativeEvent.contentOffset.y)}
      renderItem={({ item }) => <PostCard post={item} />}
    />
  );
}

Without React.memo, every scroll event re-renders FeedScreen, which
re-renders every visible PostCard. With React.memo, each PostCard
checks whether its post prop changed — and since scroll position does not
affect the post data, all of them skip the render.

When React.memo Does Not Help

React.memo does a shallow comparison. This means it compares object
references, not object contents. If you create a new object or array on
every render and pass it as a prop, React.memo sees a new reference every
time and re-renders anyway.

// ❌ New object created on every parent render
// React.memo on PostCard is useless here
<PostCard
  post={post}
  style={{ marginBottom: 8 }} // ← new object every render
/>

// ✅ Stable reference — React.memo works correctly
const cardStyle = { marginBottom: 8 }; // defined outside component

<PostCard post={post} style={cardStyle} />

The same applies to functions passed as props. This is where useCallback
comes in.

useCallback — Stable Function References

useCallback memoises a function. It returns the same function reference
across renders unless its dependencies change.

// ❌ New function reference on every render
// React.memo on PostCard cannot help — onPress always changes
const handlePress = (postId) => {
  navigation.navigate('Post', { postId });
};

// ✅ Stable reference — React.memo on PostCard works correctly
const handlePress = useCallback((postId) => {
  navigation.navigate('Post', { postId });
}, [navigation]);

useCallback is useful in exactly one scenario: you are passing a function
as a prop to a memoised child component and you want React.memo to be
able to determine that the function did not change.

Without useCallback, React.memo on the child is useless because the
function prop is a new reference on every render.
With useCallback, the function reference is stable, React.memo can
correctly determine nothing changed, and the child skips re-rendering.

The two always work together. useCallback alone does nothing useful —
a stable function reference is only valuable if something is checking
whether the reference changed.

The Dependency Array Is the Trap

useCallback takes a dependency array, exactly like useEffect. The
memoised function is only recreated when a dependency changes. If you
omit a dependency, the function closes over a stale value and produces
incorrect behaviour that is difficult to debug.

// ❌ Missing dependency — handleDelete always sees the initial value of userId
const handleDelete = useCallback(() => {
  deletePost(userId, postId);
}, [postId]); // ← userId is missing

// ✅ All dependencies included
const handleDelete = useCallback(() => {
  deletePost(userId, postId);
}, [userId, postId]);

A useCallback with a stale dependency is worse than no useCallback at
all because it introduces a subtle bug that only appears when the missing
dependency changes.

useMemo — Expensive Computations Only

useMemo memoises the result of a computation. It runs the function once,
caches the result, and returns the cached result on subsequent renders
unless the dependencies change.

// ❌ Filtered and sorted on every render
const sortedPosts = posts
  .filter(p => p.published)
  .sort((a, b) => new Date(b.date) - new Date(a.date));

// ✅ Only recomputed when posts changes
const sortedPosts = useMemo(() =>
  posts
    .filter(p => p.published)
    .sort((a, b) => new Date(b.date) - new Date(a.date)),
  [posts]
);

useMemo is appropriate when a computation is genuinely expensive — takes
measurable time — and the component re-renders more frequently than the
data changes. Filtering and sorting large arrays, computing aggregates over
large datasets, and building derived data structures are good candidates.

What Is Not Worth Memoising

Most computations in a React Native component are not expensive enough to
justify useMemo. The memoisation itself has a cost — React has to store
the cached value and run the dependency comparison on every render. For a
simple computation, that overhead can exceed the cost of just running the
computation again.

// ❌ useMemo adds overhead with no benefit
// This computation is trivially fast
const fullName = useMemo(
  () => `${user.firstName} ${user.lastName}`,
  [user.firstName, user.lastName]
);

// ✅ Just compute it — it's a string concatenation
const fullName = `${user.firstName} ${user.lastName}`;

A useful mental threshold: if you cannot measure the computation taking more
than 1ms in the React Native performance monitor, do not memoize it.

Common Misuse Patterns

Wrapping Everything in React.memo

The most common misuse is wrapping every component in React.memo as a
default practice, assuming it is always free and always beneficial.

React.memo is not free. Every render of the parent triggers the shallow
comparison in every memoised child. For a component with many props,
that comparison has a non-trivial cost. If the component re-renders
frequently anyway — because its props do change — the comparison cost is
paid on every render with no benefit.

// ❌ Memo with no benefit — props change on every render anyway
const ActiveIndicator = React.memo(({ isActive, timestamp }) => (
  <View style={{ opacity: isActive ? 1 : 0.4 }}>
    <Text>{timestamp}</Text>
  </View>
));

// timestamp changes on every render — memo always misses, always pays comparison cost

useCallback on Every Function

Wrapping every function in useCallback is another common pattern that adds
complexity without benefit. A useCallback-wrapped function that is not
passed to a memoised child serves no purpose — nothing is checking whether
the reference changed.

// ❌ useCallback with no memoised consumer — no benefit
export default function SettingsScreen() {
  const handleSave = useCallback(() => {
    saveSettings(formData);
  }, [formData]);

  return <Button onPress={handleSave} title="Save" />;
  // Button is not memoised — it re-renders regardless
}

useMemo for Object Identity

A subtler misuse is using useMemo not for computation cost but purely to
maintain object identity — to prevent a new object reference from breaking
React.memo downstream.

// Using useMemo just for reference stability
const config = useMemo(() => ({
  animationDuration: 300,
  easing: 'ease-in-out',
}), []);

This works but it is the wrong tool. If the object is truly static, define
it outside the component. useMemo with an empty dependency array is a
code smell that indicates the value should not be inside the component
at all.

// ✅ Static values belong outside the component
const ANIMATION_CONFIG = {
  animationDuration: 300,
  easing: 'ease-in-out',
};

export default function AnimatedCard() {
  // ANIMATION_CONFIG is always the same reference — no memo needed
}

Measuring Real Performance Gains

The only way to know whether an optimisation is helping is to measure before
and after. React Native provides two tools for this.

React DevTools Profiler

The React DevTools profiler shows you which components re-rendered during a
recording, how long each render took, and why it re-rendered. Enable it by
connecting React DevTools to your Metro bundler.

Record a user interaction — scrolling a list, tapping a button, typing in
a field. The profiler shows a flame graph of renders. Look for:

Components that re-render when they should not
Components with unexpectedly high render times
Components that re-render dozens of times for a single interaction

This tells you where to optimise. Do not optimise components that do not
appear as problems here.

Why Did You Render

The @welldone-software/why-did-you-render library patches React to log
every re-render and tell you exactly why it happened — which prop or state
changed and what the old and new values were.

// index.js — development only
if (__DEV__) {
  const whyDidYouRender = require('@welldone-software/why-did-you-render');
  whyDidYouRender(React, {
    trackAllPureComponents: true,
  });
}

Then opt specific components into tracking:

const PostCard = ({ post }) => (
  <View><Text>{post.title}</Text></View>
);

PostCard.whyDidYouRender = true;

The console will now log every time PostCard re-renders and exactly what
caused it. This removes all guesswork from the optimisation process.

The Performance Monitor

For frame rate impact, use the built-in React Native performance monitor
(Cmd+D on iOS simulator → Perf Monitor). It shows JS thread FPS and
UI thread FPS in real time. A healthy app maintains 60 FPS on both threads.

If you see JS thread drops during list scrolling, re-render optimisation
will help. If the UI thread is dropping and the JS thread is fine, the
problem is in native rendering — animations, shadows, or image decoding —
and re-render optimisation will not help at all.

The Right Mental Model

Before reaching for any of these tools, ask three questions:

1. Is there actually a performance problem? Open the profiler and
measure. If the app is at 60 FPS and interactions feel instant, there is
nothing to optimise. Adding memo to a fast component makes it more complex
without making it faster.

2. Is the problem re-renders? The performance monitor shows you whether
the JS thread or the UI thread is the bottleneck. Only re-render
optimisation if the JS thread is dropping frames.

3. Is this the right tool? Re-renders in a FlatList item → React.memo.
Stable function reference for a memoised child → useCallback. Expensive
computation over large data → useMemo. Static values inside a component
→ move them outside the component entirely.

The hierarchy of impact for React Native performance is roughly:

Avoid unnecessary renders with correct architecture first
Use React.memo on FlatList items that have stable props
Use useCallback on functions passed to memoised components
Use useMemo only for demonstrably expensive computations
Consider FlashList for very large lists regardless of memo usage

Summary

React.memo, useCallback, and useMemo are precise tools for specific
problems, not a default coating to apply to every component. React.memo
skips re-renders when props have not changed — but only if those props have
stable references. useCallback provides stable function references — but
only helps when the consumer is memoised. useMemo caches expensive
computations — but adds overhead that exceeds its benefit for anything
trivially fast. The correct approach is to measure first with the React
DevTools profiler and Why Did You Render, identify the actual bottleneck,
and apply the minimum tool needed to fix it. Premature optimisation with
these tools does not just waste time — it actively adds complexity and
overhead that can make performance worse.

Vertical FlatList Inside ScrollView — Why It Breaks and How to Fix It

Nitish Poonia — Thu, 05 Mar 2026 11:46:34 +0000

If you have ever nested a vertical FlatList inside a ScrollView, you have
probably noticed the list either renders all items at once, refuses to
scroll, or behaves unpredictably depending on the device. You add
nestedScrollEnabled, it still does not work right. You set a fixed height,
items get cut off. Nothing feels correct because nothing is correct —
the combination is fundamentally broken by design, not by implementation.

This post explains exactly why, what is happening at the rendering and event
level, and the patterns that actually solve it without hacks.

Why This Combination Exists in the First Place

The temptation is understandable. You have a screen with a header, some
profile information, a section of stats, and then a list of posts. The
natural instinct is to wrap everything in a ScrollView and drop a FlatList
in the middle for the posts section. It looks clean in JSX and works fine
on small datasets.

// What everyone tries first
<ScrollView>
  <ProfileHeader />
  <StatsSection />
  <FlatList
    data={posts}
    renderItem={renderPost}
    keyExtractor={keyExtractor}
  />
</ScrollView>

The problem is that ScrollView and FlatList are solving the same problem in
conflicting ways, and React Native has to pick one. It always picks
ScrollView — and in doing so, it breaks FlatList completely.

Rendering Conflict — Virtualisation Is Disabled

FlatList's entire purpose is virtualisation. It renders only the items
currently visible on screen plus a small buffer, unmounts items that scroll
past, and mounts new ones just before they come into view. This is what
keeps a list of 1000 items performant.

Virtualisation requires FlatList to know its own height. It needs to know
how tall its viewport is so it can calculate which items are visible and
which are not.

When FlatList is inside a ScrollView, it has no bounded height. ScrollView
expands to fit all of its children — that is literally what it does. So
FlatList's height becomes unbounded, and the virtualisation engine sees an
infinitely tall viewport. If everything is visible, nothing needs to be
virtualised. So FlatList renders every single item immediately and keeps
them all mounted forever.

The result is identical to using a plain ScrollView with a map() — you
have lost all the performance benefits of FlatList while keeping the
complexity of it. With 500 items, all 500 components are mounted, measured,
and held in memory simultaneously.

// This is what React Native actually does with your nested FlatList
<ScrollView>
  <ProfileHeader />
  <StatsSection />
  <View>
    {posts.map(post => <PostCard key={post.id} post={post} />)}
  </View>
</ScrollView>

That is functionally what you have written. FlatList is not helping you.

Scroll Event Propagation Conflict

The second problem is at the gesture and event level. Both ScrollView and
FlatList want to own vertical scroll events. When your finger moves
vertically on the screen, React Native's gesture system has to decide which
component receives the event.

On iOS, the two scroll views fight over the gesture. The result is jumpy,
inconsistent scrolling — sometimes the outer ScrollView scrolls, sometimes
the inner FlatList tries to, and the transition between them feels broken.
Momentum scrolling stops working correctly. Pull-to-refresh on the FlatList
conflicts with any pull-to-refresh on the outer ScrollView.

On Android the behaviour is different but equally broken. Android's
nestedScrollEnabled prop exists specifically for this scenario and it does
help — but it adds significant overhead to every scroll event because the
system now has to propagate each event up the view hierarchy to determine
who should handle it. On low-end Android devices this overhead is measurable
and causes frame drops.

// nestedScrollEnabled helps but does not fix the core problem
<FlatList
  data={posts}
  renderItem={renderPost}
  nestedScrollEnabled // ← band-aid, not a fix
/>

The deeper issue remains: you have two competing scroll containers and every
gesture has to be arbitrated between them. There is no clean solution at
the event level — the fix has to be architectural.

The Wrong Fixes People Try

Before covering the correct patterns, it is worth naming the fixes that seem
reasonable but create new problems.

Fixed height on FlatList — Setting a fixed height style on the
FlatList gives it a bounded viewport, which re-enables virtualisation. But
now you have a list inside a scrollable container inside a scrollable
screen. You have two scroll areas visible simultaneously and users have to
scroll inside a scroll. This is a poor UX pattern on mobile.

// Creates a scroll-within-scroll UX problem
<ScrollView>
  <ProfileHeader />
  <FlatList
    data={posts}
    renderItem={renderPost}
    style={{ height: 400 }} // ← two scrollable areas visible at once
  />
</ScrollView>

scrollEnabled={false} on FlatList — Disabling scroll on FlatList and
relying on the outer ScrollView to scroll means FlatList still renders
everything because it has no bounded height. You have just made it a very
expensive map().

ListHeaderComponent misuse — Some developers put the header content
inside FlatList's ListHeaderComponent to avoid needing a ScrollView at
all. This works but is often done poorly, leading to a massive header
component that re-renders every time the list data changes.

The Correct Architectural Patterns

Pattern 1 — Use ListHeaderComponent and ListFooterComponent

This is the cleanest solution for the most common case. Instead of wrapping
FlatList in a ScrollView, move your header content into FlatList's own
ListHeaderComponent. The entire screen becomes one single scroll
container — FlatList — with your non-list content rendered above and below
the list items.

const ProfileHeader = () => (
  <View>
    <ProfileHeader />
    <StatsSection />
  </View>
);

export default function FeedScreen() {
  return (
    <FlatList
      data={posts}
      renderItem={renderPost}
      keyExtractor={keyExtractor}
      ListHeaderComponent={<ProfileHeader />}
      ListFooterComponent={hasNextPage ? <ActivityIndicator /> : null}
    />
  );
}

FlatList now owns the entire scroll surface. Virtualisation works correctly
because FlatList knows its own height — it fills the screen. The header
scrolls away naturally as the user scrolls down. Pull-to-refresh works
without conflict.

The ListHeaderComponent re-renders when the list data changes, so keep it
memoised if it contains expensive components.

const MemoHeader = React.memo(() => (
  <View>
    <ProfileHeader />
    <StatsSection />
  </View>
));

<FlatList
  ListHeaderComponent={<MemoHeader />}
  ...
/>

Pattern 2 — SectionList for Multiple Content Types

If your screen has multiple distinct sections — not just a header and a list
but several lists or mixed content types — SectionList is the right tool.
It handles heterogeneous sections natively, virtualises across all of them,
and maintains a single scroll container.

const sections = [
  {
    type: 'profile',
    data: [{ id: 'profile' }],
    renderItem: () => <ProfileHeader />,
  },
  {
    type: 'posts',
    title: 'Recent Posts',
    data: posts,
    renderItem: ({ item }) => <PostCard post={item} />,
  },
  {
    type: 'media',
    title: 'Media',
    data: mediaItems,
    renderItem: ({ item }) => <MediaThumb item={item} />,
  },
];

<SectionList
  sections={sections}
  keyExtractor={(item) => item.id}
  renderSectionHeader={({ section }) =>
    section.title ? <SectionTitle title={section.title} /> : null
  }
/>

SectionList is still a virtualised list under the hood — it uses the same
VirtualizedList base as FlatList. All sections are part of one scroll
container and virtualisation works correctly across all of them.

Pattern 3 — FlashList for Complex Mixed Layouts

If you are on Shopify's FlashList, it handles mixed item types through the
overrideItemType prop. You define different item types and FlashList
recycles components within each type, keeping the performance benefits of
component recycling even with heterogeneous content.

import { FlashList } from '@shopify/flash-list';

const data = [
  { type: 'header', id: 'header' },
  { type: 'stats', id: 'stats' },
  ...posts.map(p => ({ ...p, type: 'post' })),
];

<FlashList
  data={data}
  estimatedItemSize={80}
  overrideItemType={(item) => item.type}
  renderItem={({ item }) => {
    if (item.type === 'header') return <ProfileHeader />;
    if (item.type === 'stats')  return <StatsSection />;
    return <PostCard post={item} />;
  }}
  keyExtractor={(item) => item.id}
/>

This is the most performant option for complex screens. FlashList recycles
the PostCard component across all post items, which eliminates the
mount/unmount cost entirely for the most frequently rendered item type.

Pattern 4 — Separate Screens for Separate Lists

Sometimes the right answer is not a clever layout pattern but a navigation
change. If your screen has two or more substantial lists, consider whether
they belong on the same screen at all. Two tabs, each with its own FlatList
filling the screen, is almost always a better UX than one screen trying to
scroll through multiple lists simultaneously.

// Before — one screen trying to do too much
<ScrollView>
  <PostList />
  <MediaList />
  <FollowerList />
</ScrollView>

// After — tab navigator, each screen is a single FlatList
<Tab.Navigator>
  <Tab.Screen name="Posts"     component={PostsScreen} />
  <Tab.Screen name="Media"     component={MediaScreen} />
  <Tab.Screen name="Followers" component={FollowersScreen} />
</Tab.Navigator>

Decision Guide

Use this to choose the right pattern for your screen:

Single list with non-list content above or below → ListHeaderComponent and ListFooterComponent
Multiple distinct sections with different item types → SectionList
Complex mixed layout with high performance requirements → FlashList with overrideItemType
Multiple substantial lists on one screen → Reconsider the layout, use tabs

Summary

Nesting a vertical FlatList inside a ScrollView disables virtualisation
because FlatList cannot determine its own height, causing every item to
render immediately and remain mounted. Scroll event propagation conflicts
between the two containers cause unreliable gesture handling, especially on
iOS, and measurable performance overhead on Android even with
nestedScrollEnabled. The fix is always architectural — move non-list
content into ListHeaderComponent, use SectionList for multi-section
screens, or reconsider whether multiple lists belong on the same screen at
all. One scroll container per screen is not a constraint — it is the
correct mental model for building smooth React Native interfaces.

Offset Pagination vs Cursor Pagination

Nitish Poonia — Sun, 01 Mar 2026 14:33:31 +0000

Every app eventually needs a scrollable list that loads more data as the user scrolls down. The implementation looks simple. You fetch page one, when the user hits the bottom you fetch page two, and so on. Most developers reach for offset pagination because it is the first thing that comes to mind and it works perfectly in development.

Then the app goes to production. The list has 50,000 records. Users start seeing duplicate items. Some items never appear at all. The database slows down as the list grows. And none of this shows up in testing because your test database has 100 rows.

This post explains exactly why offset pagination breaks, how cursor pagination fixes every one of those problems, and how to implement the full stack — backend API in Node.js and frontend infinite scroll in React Native.

How Offset Pagination Works

Offset pagination is what most people learn first. You tell the database to skip a number of rows and return the next batch.

SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 40;

In an API this looks like:

GET /posts?page=3&limit=20
GET /posts?offset=40&limit=20

The frontend keeps track of which page it is on, increments it on each fetch, and appends the results to the list.

const [page, setPage] = useState(1);
const [posts, setPosts] = useState([]);

const loadMore = async () => {
  const response = await fetch(`/api/posts?page=${page}&limit=20`);
  const data = await response.json();
  setPosts(prev => [...prev, ...data.posts]);
  setPage(prev => prev + 1);
};

This works. Until it does not.

Why Offset Pagination Breaks at Scale

Problem 1 — The Shifting Window

Offset pagination assumes the dataset is frozen while you are paginating through it. It never is.

Imagine a user is on page three of a feed sorted by newest first. While they were reading pages one and two, five new posts were published. The entire dataset shifted forward by five positions.

When the user fetches page three, the database skips the first 40 rows. But those first 40 rows now include the five new posts. So the rows that were previously positions 36 through 40 are now at positions 41 through 45. The user sees them again — duplicates — because those exact rows are now at the top of page three.

The reverse also happens. If posts are deleted while the user is paginating, items get skipped entirely and the user never sees them.

This is not a bug in your code. It is a fundamental property of offset pagination. There is no fix. You can only replace it.

Problem 2 — Database Performance Degrades With Depth

When you run OFFSET 10000 LIMIT 20, the database does not magically jump to row 10,001. It reads and discards the first 10,000 rows, then returns the next 20. Every deep page scan costs more than the one before it.

On a table with one million rows, fetching page 500 requires the database to scan and discard 9,980 rows on every single request. As your data grows, your deepest pages get slower — which is exactly when you need them to be fast.

-- This gets slower as offset grows
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 9980;

-- Execution plan: Sequential scan, discard 9980 rows, return 20
-- Cost: O(offset)

Problem 3 — Race Conditions on the Frontend

If the user scrolls fast and triggers multiple simultaneous fetches, responses can arrive out of order. The second fetch resolves before the first, your state is set to page two results, then the first fetch resolves and overwrites it with page one results mixed in.

You end up with a scrambled, duplicated list and no error in your console.

Cursor Pagination — How It Actually Works

Cursor pagination replaces the concept of "page number" with a pointer to a specific record. Instead of saying "give me rows 40 to 60", you say "give me 20 rows after this specific record".

The API response includes a cursor — usually the ID or timestamp of the last item returned. The next request sends that cursor back, and the database uses it to find exactly where to continue from.

First request:
GET /api/posts?limit=20
Response: { posts: [...], nextCursor: "post_id_xyz" }

Second request:
GET /api/posts?limit=20&cursor=post_id_xyz
Response: { posts: [...], nextCursor: "post_id_abc" }

No more data:
GET /api/posts?limit=20&cursor=post_id_abc
Response: { posts: [...], nextCursor: null }

The cursor is opaque to the frontend. It does not know or care what it means. It just sends it back on the next request.

Why This Fixes the Shifting Window

When new posts are added to the top of the feed, your cursor still points to the same record it always did. The query says "give me posts older than post_id_xyz" — new posts are newer, so they are excluded. No duplicates, no skipped items, regardless of how much the dataset changes while the user is scrolling.

Why This Fixes the Performance Problem

-- Offset: scans and discards N rows every time
SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 9980;

-- Cursor: index seek directly to the record, then scan forward
SELECT * FROM posts
WHERE created_at < '2025-01-15T10:23:00Z'
ORDER BY created_at DESC
LIMIT 20;

With an index on created_at, the cursor query is O(1) regardless of how deep into the list you are. Page one and page 500 cost the same.

Backend Implementation — Node.js with PostgreSQL

The Posts Table

CREATE TABLE posts (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  title       TEXT NOT NULL,
  content     TEXT,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  user_id     UUID REFERENCES users(id)
);

-- This index is what makes cursor pagination fast
CREATE INDEX idx_posts_created_at ON posts (created_at DESC);

The API Endpoint

// routes/posts.js
import express from 'express';
import { db } from '../db.js';

const router = express.Router();

router.get('/', async (req, res) => {
  try {
    const limit = Math.min(parseInt(req.query.limit) || 20, 100);
    const cursor = req.query.cursor || null;

    let query;
    let params;

    if (cursor) {
      // Decode the cursor — it's a base64 encoded timestamp + id
      const decoded = JSON.parse(Buffer.from(cursor, 'base64').toString('utf8'));

      query = `
        SELECT id, title, content, created_at, user_id
        FROM posts
        WHERE (created_at, id) < ($1, $2)
        ORDER BY created_at DESC, id DESC
        LIMIT $3
      `;
      params = [decoded.createdAt, decoded.id, limit + 1];
    } else {
      query = `
        SELECT id, title, content, created_at, user_id
        FROM posts
        ORDER BY created_at DESC, id DESC
        LIMIT $1
      `;
      params = [limit + 1];
    }

    const result = await db.query(query, params);
    const rows = result.rows;

    // Fetch one extra row to know if there is a next page
    const hasNextPage = rows.length > limit;
    const posts = hasNextPage ? rows.slice(0, limit) : rows;

    // Encode the cursor from the last item
    let nextCursor = null;
    if (hasNextPage && posts.length > 0) {
      const lastPost = posts[posts.length - 1];
      nextCursor = Buffer.from(JSON.stringify({
        createdAt: lastPost.created_at,
        id: lastPost.id,
      })).toString('base64');
    }

    res.json({
      posts,
      nextCursor,
      hasNextPage,
    });
  } catch (error) {
    console.error('Failed to fetch posts:', error);
    res.status(500).json({ error: 'Failed to fetch posts' });
  }
});

export default router;

Two things worth noting here. First, the cursor encodes both created_at and id. Using timestamp alone causes problems if two posts are created at the exact same millisecond — the tie-breaker id ensures the cursor always points to exactly one record. Second, fetching limit + 1 rows is the cleanest way to check for a next page without a separate COUNT query.

Why Base64 Encode the Cursor

You could send the raw timestamp and ID as separate query params. Base64 encoding makes the cursor opaque — the frontend treats it as a black box and sends it back unchanged. This means you can change what the cursor encodes internally (add a shard ID, change the sort field) without any frontend changes.

Frontend Implementation — React Native

The Hook

Separate the pagination logic from your UI entirely. This hook handles fetching, appending, deduplication, and race conditions.

// hooks/usePaginatedFetch.js
import { useState, useCallback, useRef } from 'react';

export function usePaginatedFetch(url) {
  const [items, setItems]           = useState([]);
  const [loading, setLoading]       = useState(false);
  const [loadingMore, setLoadingMore] = useState(false);
  const [hasNextPage, setHasNextPage] = useState(true);
  const [error, setError]           = useState(null);

  const cursorRef    = useRef(null);
  const fetchingRef  = useRef(false); // prevents duplicate fetches
  const seenIds      = useRef(new Set()); // deduplication

  const fetchPage = useCallback(async (isRefresh = false) => {
    // Guard: do not fetch if already fetching or no more pages
    if (fetchingRef.current) return;
    if (!isRefresh && !hasNextPage) return;

    fetchingRef.current = true;
    isRefresh ? setLoading(true) : setLoadingMore(true);
    setError(null);

    try {
      const cursor = isRefresh ? '' : cursorRef.current;
      const endpoint = cursor
        ? `${url}?cursor=${cursor}&limit=20`
        : `${url}?limit=20`;

      const response = await fetch(endpoint);

      if (!response.ok) throw new Error(`HTTP ${response.status}`);

      const data = await response.json();

      if (isRefresh) {
        // Hard reset on pull-to-refresh
        seenIds.current = new Set();
        cursorRef.current = null;
        setItems([]);
      }

      // Deduplicate before appending
      const newItems = data.posts.filter(item => {
        if (seenIds.current.has(item.id)) return false;
        seenIds.current.add(item.id);
        return true;
      });

      setItems(prev => isRefresh ? newItems : [...prev, ...newItems]);
      cursorRef.current = data.nextCursor;
      setHasNextPage(data.hasNextPage);
    } catch (err) {
      setError(err.message);
    } finally {
      fetchingRef.current = false;
      setLoading(false);
      setLoadingMore(false);
    }
  }, [url, hasNextPage]);

  const loadMore  = useCallback(() => fetchPage(false), [fetchPage]);
  const refresh   = useCallback(() => fetchPage(true),  [fetchPage]);

  return { items, loading, loadingMore, hasNextPage, error, loadMore, refresh };
}

The List Component

// components/PostList.js
import {
  FlatList, View, Text, ActivityIndicator,
  RefreshControl, StyleSheet
} from 'react-native';
import { useEffect } from 'react';
import { usePaginatedFetch } from '../hooks/usePaginatedFetch';

const ITEM_HEIGHT = 80;

const keyExtractor = item => item.id;

const renderItem = ({ item }) => (
  <View style={styles.item}>
    <Text style={styles.title}>{item.title}</Text>
    <Text style={styles.date}>
      {new Date(item.created_at).toLocaleDateString()}
    </Text>
  </View>
);

const getItemLayout = (_, index) => ({
  length: ITEM_HEIGHT,
  offset: ITEM_HEIGHT * index,
  index,
});

export default function PostList() {
  const {
    items, loading, loadingMore,
    hasNextPage, error, loadMore, refresh,
  } = usePaginatedFetch('https://api.yoursite.com/posts');

  // Load the first page on mount
  useEffect(() => { refresh(); }, []);

  if (loading && items.length === 0) {
    return (
      <View style={styles.center}>
        <ActivityIndicator size="large" />
      </View>
    );
  }

  if (error && items.length === 0) {
    return (
      <View style={styles.center}>
        <Text style={styles.error}>Failed to load. Pull to retry.</Text>
      </View>
    );
  }

  return (
    <FlatList
      data={items}
      keyExtractor={keyExtractor}
      renderItem={renderItem}
      getItemLayout={getItemLayout}
      onEndReached={hasNextPage ? loadMore : null}
      onEndReachedThreshold={0.5}
      refreshControl={
        <RefreshControl refreshing={loading} onRefresh={refresh} />
      }
      ListFooterComponent={
        loadingMore
          ? <ActivityIndicator style={styles.footer} />
          : !hasNextPage && items.length > 0
          ? <Text style={styles.end}>You have reached the end</Text>
          : null
      }
    />
  );
}

const styles = StyleSheet.create({
  item: {
    height: ITEM_HEIGHT,
    paddingHorizontal: 16,
    paddingVertical: 12,
    borderBottomWidth: 1,
    borderBottomColor: '#f0f0f0',
    justifyContent: 'center',
  },
  title:  { fontSize: 16, fontWeight: '600', marginBottom: 4 },
  date:   { fontSize: 12, color: '#888' },
  center: { flex: 1, alignItems: 'center', justifyContent: 'center' },
  footer: { paddingVertical: 20 },
  end:    { textAlign: 'center', padding: 20, color: '#aaa', fontSize: 13 },
  error:  { color: '#e33', fontSize: 14 },
});

Handling Race Conditions

The fetchingRef in the hook above is the key guard. Consider what happens without it:

User scrolls to the bottom, loadMore fires
Network is slow, request is in flight
User scrolls up and back down, loadMore fires again
Second response arrives first — state set to page two
First response arrives — page two results are overwritten with a mix

With fetchingRef.current = true set before the fetch and cleared in finally, the second call hits the guard immediately and returns. Only one fetch runs at a time.

The seenIds Set handles the case where a race condition does slip through or where the server returns an item you already have. Before appending any item, you check whether its ID has already been seen. If it has, you skip it. This makes the list resilient to any source of duplicates — race conditions, network retries, or the shifting window problem itself.

Handling Pull to Refresh Correctly

Pull to refresh needs to reset everything — the cursor, the seen IDs, and the list itself — before fetching fresh data. Doing this in the wrong order causes a flash of empty content.

The isRefresh path in the hook clears seenIds and resets cursorRef before the fetch resolves, then replaces items with the fresh data in a single setItems call. One render, no flicker.

When to Use Each Approach

Cursor pagination is the right default for any feed or timeline sorted by recency. It handles scale, handles a live dataset, and costs the same at any depth.

Offset pagination still makes sense in two specific cases. First, when users need to jump to a specific page — search results with page numbers, admin tables, report exports. Second, when the dataset is small and static, such as a settings list or a catalogue that never changes. For everything else, cursors.

Summary

Offset pagination has three fatal flaws at scale: duplicates from a shifting dataset, skipped items when records are deleted, and database scans that get slower with depth. None of these show up in development with small datasets.

Cursor pagination fixes all three by pointing to a specific record rather than a position. The backend fetches limit + 1 rows to detect the next page cheaply, encodes the cursor as an opaque base64 token, and uses a composite cursor of timestamp plus ID to handle ties. The frontend tracks an in-flight guard to prevent duplicate fetches and a seen-IDs Set to deduplicate results before they hit the list. The result is a list that is correct at any scale and costs the same to query whether you are on item 20 or item 200,000.

How to improve FlatList performance for very large lists

Nitish Poonia — Fri, 27 Feb 2026 15:52:41 +0000

You have a FlatList. It works perfectly with 50 items. You test it with real data —
5000 items — and suddenly the app stutters, scrolls feel sticky, and the JS thread
is pegged at 100%. Nothing in your code changed. So what happened?

This post breaks down exactly why FlatList degrades at scale and gives you concrete
fixes ordered from easiest to most impactful.

What FlatList Actually Does

Before fixing anything, you need to understand what FlatList is doing for you.

FlatList is a wrapper around ScrollView that virtualises your list. Virtualisation
means it only renders items that are currently visible on screen plus a small buffer
above and below. Items scrolled past are unmounted from the React tree. Items about
to come into view are mounted just in time.

This sounds perfect. The problem is that "just in time" mounting is expensive, and
at scale several things compound to make it fall apart.

The Real Causes of Slowdown

1. The JS Thread is Single-Threaded

React Native runs your JavaScript on a single thread. Every render, every state
update, every onScroll event handler runs on this one thread. When you scroll fast
through 5000 items, FlatList is simultaneously:

Unmounting items that left the viewport
Mounting new items entering the viewport
Running your renderItem function for each new item
Calculating layout for newly mounted items
Firing onScroll events at up to 60 times per second

All of this competes on the same thread. When the thread is busy rendering, it
cannot respond to your finger gesture. That's the stutter you feel — it's not a slow
scroll, it's the UI waiting for JS to finish work.

2. renderItem Creates New Function References on Every Render

This is the single most common mistake and the easiest to fix.

// ❌ This creates a new function on every parent render
<FlatList
  data={items}
  renderItem={({ item }) => <ItemCard item={item} />}
/>

Every time the parent component re-renders — which happens on every scroll event
if you have any state in the parent — a brand new renderItem function is created.
FlatList sees a new function reference and re-renders every visible item. With 5000
items and scroll events firing 60 times per second, this is catastrophic.

3. keyExtractor is Recalculated Unnecessarily

Same problem as above. If keyExtractor is defined inline, it recreates on every
render and forces FlatList to recheck all item keys.

// ❌ New function reference every render
keyExtractor={(item) => item.id.toString()}

4. Item Components Are Not Memoised

Even with a stable renderItem reference, if your item component is not wrapped in
React.memo, it will re-render whenever the parent renders — regardless of whether
the item's own props changed.

5. The windowSize Is Too Large

FlatList renders a window of items around the viewport. The default windowSize is
21, which means it renders 10 viewport-heights above and 10 below the current
scroll position. With large items or a slow device this is far too much.

6. Images Are Not Cached or Sized Correctly

If your items contain images without explicit width and height, React Native
has to measure them after they load. This triggers layout recalculations that
cascade through the list. Multiply this by hundreds of items entering the viewport
and the layout thread gets overwhelmed.

7. You Are Storing List State in the Parent

If your list items have interactive state — selected, expanded, liked — and you
store that state in the parent component, every interaction re-renders the entire
parent, which cascades down to every visible FlatList item.

The Fixes

Fix 1 — Move renderItem Outside the Component

// ✅ Defined once, stable reference forever
const renderItem = ({ item }) => <ItemCard item={item} />;

export default function MyList({ data }) {
  return (
    <FlatList
      data={data}
      renderItem={renderItem}
      keyExtractor={keyExtractor}
    />
  );
}

If you need props from the parent inside renderItem, use useCallback:

const renderItem = useCallback(({ item }) => (
  <ItemCard item={item} onPress={handlePress} />
), [handlePress]); // only recreates when handlePress changes

Fix 2 — Stabilise keyExtractor

// ✅ Defined outside the component
const keyExtractor = (item) => item.id.toString();

Fix 3 — Memoise Your Item Component

import React, { memo } from 'react';

const ItemCard = memo(({ item }) => {
  return (
    <View>
      <Text>{item.title}</Text>
    </View>
  );
});

export default ItemCard;

memo does a shallow comparison of props. If nothing changed, the component does
not re-render. For a list of 5000 items this is the difference between re-rendering
20 visible items and re-rendering none of them on a parent state change.

If your item has complex props, pass a custom comparison function:

const ItemCard = memo(({ item }) => {
  // ...
}, (prevProps, nextProps) => {
  // Return true if props are equal (skip re-render)
  return prevProps.item.id === nextProps.item.id &&
         prevProps.item.updatedAt === nextProps.item.updatedAt;
});

Fix 4 — Tune the Virtualisation Window

<FlatList
  data={items}
  renderItem={renderItem}
  keyExtractor={keyExtractor}
  windowSize={5}           // default 21 — render 2 viewports above and below
  maxToRenderPerBatch={10} // default 10 — items rendered per JS batch
  initialNumToRender={10}  // default 10 — items rendered on first paint
  updateCellsBatchingPeriod={50} // ms between batch renders, default 50
  removeClippedSubviews={true}   // unmount offscreen items from native view
/>

windowSize={5} is a good starting point for most lists. Go lower if items are
tall, higher if you see blank flashes while scrolling.

removeClippedSubviews={true} unmounts the native view of offscreen items while
keeping the JS component mounted. This reduces memory and GPU pressure but can
cause blank flashes on fast scrolls. Test on a real device before shipping.

Fix 5 — Give Images Explicit Dimensions

// ❌ Forces layout recalculation after image loads
<Image source={{ uri: item.imageUrl }} />

// ✅ Layout calculated immediately, no recalculation
<Image
  source={{ uri: item.imageUrl }}
  style={{ width: 80, height: 80 }}
/>

For dynamic image sizes, use a fixed aspect ratio container:

<View style={{ width: '100%', aspectRatio: 16/9 }}>
  <Image source={{ uri: item.imageUrl }} style={{ flex: 1 }} />
</View>

Fix 6 — Move Item State Into the Item Component

// ❌ Selected state in parent — every selection re-renders everything
const [selectedId, setSelectedId] = useState(null);

// ✅ Selected state inside item — only that item re-renders
const ItemCard = memo(({ item }) => {
  const [selected, setSelected] = useState(false);
  return (
    <Pressable onPress={() => setSelected(s => !s)}>
      <View style={{ backgroundColor: selected ? '#eee' : 'white' }}>
        <Text>{item.title}</Text>
      </View>
    </Pressable>
  );
});

If you genuinely need selected state in the parent (for a submit action), use a
Set ref instead of state so updates do not trigger re-renders:

const selectedIds = useRef(new Set());

const handleSelect = useCallback((id) => {
  if (selectedIds.current.has(id)) {
    selectedIds.current.delete(id);
  } else {
    selectedIds.current.add(id);
  }
}, []);

Fix 7 — Use getItemLayout If Your Items Are Fixed Height

When FlatList needs to scroll to an index or calculate scroll position, it has to
measure every item above that position. With 5000 items this is thousands of
measurements.

If your items have a fixed height, getItemLayout pre-calculates all positions
instantly:

const ITEM_HEIGHT = 72;

<FlatList
  data={items}
  renderItem={renderItem}
  keyExtractor={keyExtractor}
  getItemLayout={(data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  })}
/>

This also makes scrollToIndex instant instead of triggering a measuring pass.

Fix 8 — Consider FlashList for Extreme Cases

If you have done all of the above and still see performance issues above 1000 items,
consider Shopify's FlashList. It is a
drop-in replacement for FlatList that recycles item components instead of
unmounting and remounting them — the same pattern used by RecyclerView on Android
and UICollectionView on iOS.

npm install @shopify/flash-list

import { FlashList } from '@shopify/flash-list';

<FlashList
  data={items}
  renderItem={renderItem}
  estimatedItemSize={72} // required — your approximate item height
  keyExtractor={keyExtractor}
/>

The key difference: FlatList unmounts items that leave the viewport and mounts
fresh ones as new items enter. FlashList takes the unmounted component and reuses
it for the new item, only updating its props. This eliminates the mount/unmount
cost entirely.

Quick Reference Checklist

Before shipping any FlatList with large data:

renderItem defined outside the component or wrapped in useCallback
keyExtractor defined outside the component
Item component wrapped in React.memo
windowSize reduced from 21 to 5–7
getItemLayout provided if items are fixed height
All images have explicit width and height
Item-level state lives inside the item component
Tested on a low-end Android device, not just a simulator

A mid-range Android device is the real benchmark. Simulators run on your Mac's CPU
and will hide every performance problem. If it is smooth on a Redmi or a Samsung A
series device, it is smooth for your users.

Summary

FlatList slowdown at scale is almost never one thing — it is four or five small
mistakes that compound. The JS thread gets overloaded because renderItem creates
new functions on every scroll event, item components re-render unnecessarily because
they are not memoised, and the virtualisation window is rendering far more than what
is visible. Fix these in order and you will see the difference immediately in the
React Native performance monitor.

How to make a Redux Saga flow for API calls?

Nitish Poonia — Sun, 19 Jan 2025 16:30:01 +0000

Working with Redux Saga: Making API Workflows Smooth
First of all, I’m no expert, but I’ll try my best to explain how you can use Redux Saga to handle side effects in your React or React Native project. If your application involves a lot of API calls, Redux Saga can simplify the process and make your code more manageable.

Why Redux Saga?
Redux Saga is a middleware that helps manage side effects like API calls in a clean and predictable way. Instead of cluttering your components or reducers with API logic, you can delegate these tasks to sagas. Sagas allow you to write asynchronous code that looks synchronous, using special JavaScript functions called generators.

Setting Up Folder Structure
Before diving into sagas, it’s important to organize your project for scalability. Here's a basic structure I follow:

Services: Contains the API endpoints and methods for calling them.
Reducers: Manages state changes based on API responses.
Sagas: Handles the side effects (like API calls) and coordinates with reducers.

Services: Handling API Endpoints The Services folder contains reusable functions to make API calls. Here's an example for a "Change Password" API:

// ChangePasswordService.js
import {Constants} from '../../Config';
import Ajax from './base';

const BASE_URL = Constants.IS_DEVELOPING_MODE
  ? Constants.BASE_URL.DEV
  : Constants.BASE_URL.PROD;

export default {
  ChangePassword: async params => {
    return fetch(`${BASE_URL}api/change-password`, {
      method: 'POST',
      body: params,
      headers: {
        Accept: 'multipart/form-data',
      },
    })
      .then(response => Ajax.handleResponse(response))
      .then(data => {
        console.log('Data', data);
        return data;
      });
  },
};

Here, we define a ChangePassword function to make an API call. It uses fetch to send a POST request to the endpoint and handles the response using a helper (Ajax.handleResponse).

Reducers: Updating State Reducers listen for dispatched actions and update the state accordingly. Below is a reducer for managing password changes:

// PasswordChangeSlice.js
import {createSlice} from '@reduxjs/toolkit';

const passwordChangeSlice = createSlice({
  name: 'passwordChange',
  initialState: {
    data: null,
    isChangeSuccess: null,
    error: null,
    message: null,
  },
  reducers: {
    changePassword: state => {
      state.isChangeSuccess = null;
      state.error = null;
      state.message = '';
    },
    changePasswordSuccess: (state, action) => {
      state.data = action.payload;
      state.message = 'Password changed successfully';
      state.isChangeSuccess = true;
    },
    changePasswordFail: (state, action) => {
      state.error = action.payload;
      state.message = 'Something went wrong';
      state.isChangeSuccess = false;
    },
  },
});

export const {changePassword, changePasswordSuccess, changePasswordFail} =
  passwordChangeSlice.actions;

export default passwordChangeSlice.reducer;

This reducer has three actions:

changePassword: Resets the state when a request starts.
changePasswordSuccess: Updates the state with success data.
changePasswordFail: Updates the state with error information.

Sagas: Managing Side Effects Now comes the fun part! Sagas handle the actual API calls and dispatch actions based on the response. Here's a saga for the "Change Password" API:

import {all, call, put, takeEvery} from 'redux-saga/effects';
import API from '../Services/ChangePasswordService';
import {
  changePasswordFail,
  changePasswordSuccess,
} from '../Reducers/PasswordChangeSlice';

function* changePasswordSaga({payload}) {
  try {
    const response = yield call(API.ChangePassword, payload);
    if (response?.data) {
      yield put(changePasswordSuccess(response.data));
    } else if (response?.errors) {
      yield put(changePasswordFail(response.errors));
    }
  } catch (error) {
    yield put(changePasswordFail(error.message));
  }
}

function* passwordSaga() {
  yield all([
    takeEvery('passwordChange/changePassword', changePasswordSaga),
  ]);
}

export default passwordSaga;

call: Invokes the API function (API.ChangePassword) and waits for the result.
put: Dispatches an action to update the state.
takeEvery: Watches for a specific action (changePassword) and triggers the corresponding worker saga (changePasswordSaga).
If the API call is successful, the saga dispatches changePasswordSuccess; if it fails, it dispatches changePasswordFail.

Hooks: Connecting Components To trigger the flow, we create a custom hook that dispatches the changePassword action:

// useChangePasswordActions.js
import {useDispatch, useSelector} from 'react-redux';
import {changePassword} from '../Reducers/PasswordChangeSlice';

export const useChangePasswordActions = () => {
  const dispatch = useDispatch();
  const passwordState = useSelector(state => state?.changePassword);

  const changePasswordCall = params => {
    dispatch(changePassword(params));
  };

  return {
    passwordState,
    changePasswordCall,
  };
};

How It All Works Together
Action Dispatch: A component calls changePasswordCall from the custom hook.
Reducer: The changePassword action updates the state to indicate a pending request.
Saga: The watcher saga listens for changePassword and triggers the worker saga.
API Call: The worker saga calls the ChangePassword API and handles the response.
State Update: The saga dispatches success or failure actions, updating the state via the reducer.
Final Thoughts
This setup organizes your API workflow into clear, manageable steps:

Services handle API logic.
Reducers update the state.
Sagas handle side effects and glue everything together.
Remember, this is just one way to structure your project. If you have more experience or ideas, feel free to comment with your strategies. I’ll cover more about sagas in future articles as I learn and improve.

Happy coding! 😊