Skip to content
BSWEN
Blog

How do I prevent re-render cascades when managing server state in React?

Cowrie
Cowrie
Dev @ Bswen

I spent an entire afternoon debugging why my React app felt sluggish. The culprit? A single state update was triggering re-renders across twenty-three components. I was managing server state wrong, and my component tree was paying the price.

Here’s what I learned about preventing re-render cascades when dealing with server state in React.

What is a re-render cascade?

A re-render cascade happens when one state change ripples through your component tree, triggering unnecessary renders in components that don’t actually need to update.

I discovered this the hard way. My App component fetched user data and passed it down through props. Every time the user data refreshed (every 30 seconds via polling), every child component re-rendered—even components that only displayed the user’s name.

App re-renders (user data updated)
  -> Header re-renders (receives user prop)
    -> UserAvatar re-renders (receives user.avatar)
    -> UserName re-renders (receives user.name)
  -> Sidebar re-renders (receives user prop)
    -> UserStats re-renders (receives user.stats)
    -> RecentActivity re-renders (receives user.activity)
  -> MainContent re-renders (receives user prop)
    -> ... 15 more components

The user’s name hadn’t changed. The avatar URL was the same. But React doesn’t know that—it just sees new props and re-renders everything.

The root cause: mixing server and client state

I realized my mistake: I was treating server state the same as client state.

Server state comes from APIs. It’s asynchronous, can become stale, and is owned by the server. Think: user profiles, product listings, todo items.

Client state is local to the browser. It’s synchronous, doesn’t go stale, and is owned by the client. Think: form inputs, UI toggles, selected items.

I was using Redux for everything—storing API responses, UI state, user preferences, all in one giant store. When the API data refreshed, everything that subscribed to the Redux store re-rendered.

The fix? Separate them.

Server state -> React Query (caching, deduplication, background updates)
Client state -> Redux or Zustand (normalized, predictable updates)
UI state     -> Local useState (component-scoped, not shared)

Using React Query for server state

React Query was built specifically for server state. It handles caching, deduplication, background updates, and—most importantly—only re-renders components when their specific data changes.

Query keys control re-render scope

I restructured my queries to use hierarchical keys:

useUser.ts
// Fine-grained query keys prevent over-broad re-renders
export function useUser(userId: string) {
  return useQuery({
    queryKey: ['user', userId],
    queryFn: () => api.getUser(userId)
  })
}


export function useUserName(userId: string) {
  return useQuery({
    queryKey: ['user', userId],
    queryFn: () => api.getUser(userId),
    select: (user) => user.name  // Only subscribe to name changes
  })
}

Now useUserName only re-renders when the name field actually changes. If the user’s email or avatar updates, this component stays put.

The select option is your friend

The select option became my favorite React Query feature. It lets components subscribe to exactly the data they need:

UserProfile.tsx
function UserAvatar({ userId }: { userId: string }) {
  const { data: avatar } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => api.getUser(userId),
    select: (user) => user.avatar
  })
  return <img src={avatar} />
}


function UserName({ userId }: { userId: string }) {
  const { data: name } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => api.getUser(userId),
    select: (user) => user.name
  })
  return <span>{name}</span>
}

Two components, same query key, different subscriptions. When the user’s email changes, only components subscribed to email re-render. The avatar and name components are unaffected.

Disable aggressive refetching

React Query’s defaults are aggressive—it refetches on window focus, on mount, on reconnect. For most apps, this is overkill.

queryClient.ts
export const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 5 * 60 * 1000,     // Consider fresh for 5 minutes
      gcTime: 30 * 60 * 1000,       // Keep in cache for 30 minutes
      refetchOnWindowFocus: false,  // Don't refetch on tab switch
      refetchOnMount: false         // Use cached data on mount
    }
  }
})

I set staleTime to 5 minutes because my data doesn’t change that frequently. This prevents unnecessary background fetches that trigger re-renders.

Selective invalidation

When mutations happen, I learned to invalidate surgically:

useUpdateUser.ts
export function useUpdateUser() {
  const queryClient = useQueryClient()


  return useMutation({
    mutationFn: (updates) => api.updateUser(updates),
    onSuccess: (_, variables) => {
      // Only invalidate the specific user, not all users
      queryClient.invalidateQueries({
        queryKey: ['user', variables.id]
      })
    }
  })
}

I used to invalidate ['users'] after any user update. That caused every component displaying any user data to re-render. Now I invalidate only ['user', specificId], and only components subscribed to that specific user update.

Redux optimizations for client state

For client state (user preferences, UI state, local drafts), Redux with proper patterns prevents cascades.

Normalized state structure

I stopped nesting data deeply. Normalized state means flat entities with relationships by ID:

usersSlice.ts
// BEFORE: Nested structure (bad)
const badState = {
  users: [
    { id: 1, name: 'Alice', posts: [...] },
    { id: 2, name: 'Bob', posts: [...] }
  ]
}


// AFTER: Normalized structure (good)
const goodState = {
  users: {
    ids: [1, 2],
    entities: {
      1: { id: 1, name: 'Alice' },
      2: { id: 2, name: 'Bob' }
    }
  },
  posts: {
    ids: [101, 102],
    entities: {
      101: { id: 101, userId: 1, title: 'Post 1' },
      102: { id: 102, userId: 1, title: 'Post 2' }
    }
  }
}

When Bob’s name updates, only the entities[2] reference changes. Components subscribed to Alice (entities[1]) don’t re-render because their reference is unchanged.

Memoized selectors with createSelector

The createSelector function from Redux Toolkit memoizes derived data:

usersSlice.ts
import { createSelector } from '@reduxjs/toolkit'


const selectUserEntities = (state: RootState) => state.users.entities
const selectUserIds = (state: RootState) => state.users.ids


// Memoized: only recalculates when entities or ids change
export const selectAllUsers = createSelector(
  [selectUserIds, selectUserEntities],
  (ids, entities) => ids.map(id => entities[id])
)


// Parameterized selector for individual users
export const selectUserById = (id: string) => createSelector(
  [selectUserEntities],
  (entities) => entities[id]
)

In components:

UserItem.tsx
const UserItem = React.memo(function UserItem({ userId }: { userId: string }) {
  const user = useSelector(selectUserById(userId))
  return <li>{user?.name}</li>
})

Each UserItem only re-renders when its specific user entity changes. If another user updates, this component stays stable.

Avoid selector anti-patterns

I made this mistake early on:

badSelector.ts
// BAD: Returns new array on every call
const selectUserNames = (state) => state.users.map(user => user.name)


// The selector creates a new array reference every time,
// causing all components using this selector to re-render
// on ANY state change, even unrelated ones.

The fix is memoization:

goodSelector.ts
const selectUserNames = createSelector(
  [(state) => state.users],
  (users) => users.map(user => user.name)
)

Component-level optimizations

Even with proper state architecture, component patterns matter.

React.memo for prop-based components

I use React.memo for components that receive props from parent components that might re-render frequently:

UserCard.tsx
const UserCard = React.memo(function UserCard({ user, onUpdate }) {
  return (
    <div>
      <h3>{user.name}</h3>
      <button onClick={() => onUpdate(user.id)}>Update</button>
    </div>
  )
})

useCallback for stable function references

A common issue: parent re-renders, creates new function, child re-renders because props changed.

ParentComponent.tsx
function ParentComponent() {
  const [count, setCount] = useState(0)
  const users = useSelector(selectAllUsers)


  // Stable reference prevents UserCard re-renders
  const handleUpdate = useCallback((userId) => {
    console.log('Update user:', userId)
  }, [])


  return (
    <div>
      <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>
      {users.map(user => (
        <UserCard key={user.id} user={user} onUpdate={handleUpdate} />
      ))}
    </div>
  )
}

Without useCallback, clicking the count button creates a new handleUpdate function, causing all UserCard components to re-render—even though the users data hasn’t changed.

Debugging re-render cascades

When performance issues appear, I reach for these tools:

React DevTools Profiler

The Profiler shows which components rendered and why. I record an interaction, then check “Why did this render?” for clues.

Custom debugging hook

I built a simple hook to track what changed:

useWhyDidYouRender.ts
function useWhyDidYouRender(name: string, props: Record<string, unknown>) {
  const previous = useRef(props)


  useEffect(() => {
    const changed = Object.keys(props).filter(
      key => props[key] !== previous.current[key]
    )
    if (changed.length > 0) {
      console.log(`${name} re-rendered due to:`, changed)
    }
    previous.current = props
  })
}

Usage:

Component.tsx
function MyComponent({ user, onUpdate }) {
  useWhyDidYouRender('MyComponent', { user, onUpdate })
  // ... rest of component
}

React Query DevTools

The built-in devtools show query status, cache state, and fetch timings. Essential for understanding when and why queries refetch.

Common pitfalls I encountered

Over-fetching without select

Fetching entire objects when only one field is needed:

pitfall.ts
// BAD: Subscribes to entire user object
const { data } = useQuery({ queryKey: ['user', id], queryFn: fetchUser })


// GOOD: Subscribe only to needed field
const { data: name } = useQuery({
  queryKey: ['user', id],
  queryFn: fetchUser,
  select: (user) => user.name
})

Inline functions in JSX

inlineFunction.ts
// BAD: New function on every render
<UserCard user={user} onClick={() => console.log(user.id)} />


// GOOD: Stable reference
const handleClick = useCallback(() => {
  console.log(user.id)
}, [user.id])
<UserCard user={user} onClick={handleClick} />

Context over-subscription

Using one context for everything causes all consumers to re-render on any change:

contextPitfall.ts
// BAD: All consumers re-render on any value change
<AppContext.Provider value={{ user, theme, notifications }}>


// GOOD: Split by update frequency
<UserContext.Provider value={user}>
  <ThemeContext.Provider value={theme}>
    <NotificationsContext.Provider value={notifications}>

Summary

Preventing re-render cascades requires thinking about state differently:

  1. Separate server state from client state - React Query for server data, Redux/Zustand for client data
  2. Use React Query’s select option - Subscribe to only the data each component needs
  3. Normalize Redux state - Flat entities with ID references, not nested structures
  4. Memoize selectors with createSelector - Prevent recalculating derived data unnecessarily
  5. Apply React.memo, useMemo, and useCallback - But strategically, not everywhere

The real job, as I discovered, is “learning how to manage complex server state without triggering massive re-render cascades.” This skill separates production-ready React developers from those who only know the basics.

Start by auditing your current state management. Use React DevTools Profiler to identify unnecessary re-renders. Then apply these patterns incrementally where they have the most impact.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: