DEV Community: Raghuveer Bharadwaj

⚡ React-Redux Optimization: Common Mistakes That Trigger Unnecessary Rerenders

Raghuveer Bharadwaj — Fri, 25 Jul 2025 11:17:46 +0000

If your Redux-connected React components are mysteriously rerendering like they’ve had five cups of coffee ☕ — chances are you're making one of these common but sneaky mistakes.

Let’s explore what not to do, why it causes performance issues, and the sharpest ways to fix it.

❌ 1. Destructuring Redux Objects Inside Components

const { name, email } = useSelector((state) => state.user); // ❌

Looks clean, but this subscribes to the entire user object. So if any field inside user changes — even user.avatarUrl — your component rerenders.

🧠 Redux selectors use reference equality (===). Destructuring causes you to compare new objects every render.

✅ Instead, pick only the fields you need:

const name = useSelector((state) => state.user.name); // ✅
const email = useSelector((state) => state.user.email);

❌ 2. Selecting the Whole Object, Then Accessing Inside

const user = useSelector((state) => state.user); // ❌
const name = user.name;

Even though you're only using name, you've subscribed to the whole user object. Any change (e.g., password update, login status) triggers a rerender.

✅ Better:

const name = useSelector((state) => state.user.name); // ✅

❌ 3. Pulling Unfiltered Data You Don’t Need

Let’s say you're rendering a widget layout:

const layout = [{ id: 'w1' }, { id: 'w3' }];

Now:

const widgets = useSelector((state) => state.widgets); // ❌ bad idea

You just subscribed to every widget in the store, even if your component only displays two.

✅ Fix: Filter only what’s relevant + use a custom equality function

const widgetsInLayout = useSelector(
  (state) => {
    const allWidgets = state.widgets;
    const ids = layout.map((l) => l.id);

    return ids.reduce((acc, id) => {
      if (allWidgets[id]) acc[id] = allWidgets[id];
      return acc;
    }, {});
  },
  (prev, next) => {
    const prevKeys = Object.keys(prev);
    const nextKeys = Object.keys(next);

    if (prevKeys.length !== nextKeys.length) return false;

    return prevKeys.every((key) => {
      return (
        prev[key]?.config === next[key]?.config &&
        prev[key]?.data === next[key]?.data
      );
    });
  }
);

Now your component only rerenders when widgets used in the current layout actually change — not on every widget update.

❌ 4. Returning Objects in Selectors Without Equality Check

const userInfo = useSelector((state) => ({
  name: state.user.name,
  age: state.user.age,
})); // ❌ causes rerenders

Even if values don’t change, this object is new on every render — causing unnecessary updates.

✅ Fix: Use shallow equality

import { shallowEqual, useSelector } from 'react-redux';

const userInfo = useSelector(
  (state) => ({
    name: state.user.name,
    age: state.user.age,
  }),
  shallowEqual // ✅ avoids rerenders if values don’t change
);

❌ 5. Creating Selectors Inside Components

const selectUserName = (state) => state.user.name;

const MyComponent = () => {
  const name = useSelector(selectUserName); // ❌ Looks okay, but can re-run unnecessarily
}

If the selector isn’t memoized or reused, it could lead to recomputation or unstable results across renders.

✅ TL;DR Cheat Sheet

❌ Don’t	✅ Do
Destructure full Redux slices	Pick exact fields in `useSelector`
Return whole objects in selectors	Return only required keys
Skip equality checks	Use `shallowEqual` or custom compare
Create selectors inside components	Define them outside
Pull entire state trees	Filter context-specific slices only

🧠 Pro Tip: Always Think in Terms of React's Rerender Triggers

React only rerenders when props or state change. If you're feeding it fresh objects or large slices from Redux, you're making it think something has changed — even when it hasn't.

Keep your selectors pure, focused, and stable. Use tools like shallowEqual and custom equality checks only when needed, and never fetch more than you actually use.

With a little precision, your Redux-connected components will stay fast, predictable, and frustration-free. 🚀

📝 Disclaimer:
This post was assisted by AI (ChatGPT) for clarity and structure.

🧠 Redux on Steroids: Persisting State in IndexedDB Without Breaking the Browser

Raghuveer Bharadwaj — Sat, 10 May 2025 19:32:12 +0000

💾 Storing 50MB in Redux Persist — With IndexedDB & Compression

In modern React applications, state persistence is often essential. Whether you're caching page data, user sessions, or complex app states — you'll hit limitations with localStorage and sessionStorage pretty quickly.

I recently had to implement a solution for saving cached page data in a React + Redux application. The kicker? I needed to store up to 50MB of page data persistently without slowing down the app or crashing the browser. Here's the journey that led me to combine Redux, redux-persist, IndexedDB, and compression via fflate — plus how I handled the dark side of storing too much.

💡 The Problem: Memory vs Persistence

Most apps use localStorage because it's easy, synchronous, and simple. But it has hard limits (around 5MB) and doesn’t work well for large datasets like deeply nested Redux state or offline-heavy apps.

For this use case, I wanted to:

Persist Redux state across sessions.
Store up to 50MB of data (especially cached pages).
Optimize payload size using compression.
Avoid the dreaded QuotaExceededError in the browser.

✅ The Solution: Redux Persist + IndexedDB + Compression

Using redux-persist with redux-persist-indexeddb-storage gave me the ability to use IndexedDB as the backend for persistence.

But to push performance even further, I added fflate — a blazing fast compression library. With it, I compressed the Redux state before storing it and decompressed it when rehydrating.

🔧 Setting Up the Store with Compression

Here’s how I configured the Redux store with IndexedDB + fflate compression:

// store.ts
import { configureStore } from "@reduxjs/toolkit";
import { persistStore, persistReducer } from "redux-persist";
import createIdbStorage from "redux-persist-indexeddb-storage";
import rootReducer from "./rootReducer";
import fflateTransform from "./persistTransform"; // Compression transform
import { DEVELOPMENT } from "utils/constants/generic.constants";
import { REACT_INDEXED_DB, REACT_REDUX_PERSIST } from "utils/constants/auth.constants";

// Setup IndexedDB storage
const idbStorage = createIdbStorage(REACT_INDEXED_DB, {
  version: 1,
  storeName: REACT_INDEXED_DB,
  description: "Redux Persist Store"
});

const persistConfig = {
  key: REACT_REDUX_PERSIST,
  storage: idbStorage,
  transforms: [fflateTransform], // Apply compression
  whitelist: ["cachedPages"]
};

const persistedReducer = persistReducer(persistConfig, rootReducer);

const store = configureStore({
  reducer: persistedReducer,
  devTools: process.env.REACT_APP_NODE_ENV === DEVELOPMENT,
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware({
      serializableCheck: false
    })
});

const persistor = persistStore(store);

export { store, persistor };

🧬 persistTransform with fflate

I used a custom transform to compress and decompress the state using fflate. Here's what it looks like:

// persistTransform.ts
import { createTransform } from "redux-persist";
import { strToU8, decompressSync, compressSync, strFromU8 } from "fflate";

const fflateTransform = createTransform(
  // Compress state on save
  (inboundState) => {
    const json = JSON.stringify(inboundState);
    const compressed = compressSync(strToU8(json));
    return Array.from(compressed); // Store as array for IndexedDB
  },

  // Decompress state on rehydration
  (outboundState) => {
    const compressed = new Uint8Array(outboundState);
    const json = strFromU8(decompressSync(compressed));
    return JSON.parse(json);
  }
);

export default fflateTransform;

🔥 This reduced my persisted state size by 40–60% depending on the complexity of data.

🧪 Testing Limits — and Hitting Them

Even with compression, browsers behave unpredictably when IndexedDB crosses ~50MB. Sometimes you’ll hit a QuotaExceededError, sometimes hydration just fails silently.

So, I wrote a recursive eviction function to remove the oldest cached data when space runs out.

🧹 Auto-Clearing the Oldest Cached Data

async function getIndexedDB() {
  try {
    const db = await openDatabase();
    const data = await getData(db, REACT_INDEXED_DB_STORE_KEY);
    const size = new Blob([data], { type: "text/plain" }).size;
    return size > 52428800; // 50MB
  } catch (error) {
    console.error("Error accessing IndexedDB:", error);
  }
  return false;
}

const clearOverFlowingData = async () => {
  const isIndexedDBFull = await getIndexedDB();

  if (isIndexedDBFull) {
    const cachedPages = store.getState().cachedPages;
    const { oldestPageID } = Object.entries(cachedPages).reduce(
      (acc, [pageID, { date }]) => {
        const currentDate = new Date(date);
        if (!acc.oldestDate || currentDate < acc.oldestDate) {
          return { oldestPageID: pageID, oldestDate: currentDate };
        }
        return acc;
      },
      { oldestPageID: null, oldestDate: null }
    );
    dispatch(deleteCachedPage({ pageID: oldestPageID }));
    clearOverFlowingData(); // Recursively call until memory is under threshold
  }
};

And I triggered this with:

useEffect(() => {
  clearOverFlowingData();
}, [pageID]);

This kept the IndexedDB size under control — safely below 45MB.

⚖️ Tradeoffs: IndexedDB vs localStorage (with Compression)

Feature	IndexedDB (w/ fflate)	localStorage
Storage limit	~50MB	~5MB
Compression support	✅ Manual (fflate)	✅ Manual
Speed of hydration	🐢 Slower (compressed)	⚡ Fast
Data structure support	✅ Complex objects	❌ Strings only
Ideal for	Big, offline state	Small, fast config

🧩 Conclusion

If your Redux state is outgrowing localStorage, using IndexedDB with compression is a powerful pattern. With redux-persist, redux-persist-indexeddb-storage, and fflate, I was able to build a robust, scalable, and space-efficient caching mechanism.

✅ Store big data
✅ Shrink payload size
✅ Keep browsers happy

This architecture is reusable across any React project dealing with offline data, caching, or large persisted state.

📌 TL;DR

Use redux-persist-indexeddb-storage for large Redux state.
Compress data with fflate to reduce size by ~50%.
Add a recursive cleanup function to stay under quota.
Expect slightly slower hydration, but much larger capacity.

🙏 Thanks for Reading

If you're building apps with large Redux states, give this setup a try and see the impact on performance and reliability.
Happy coding! 💻🚀

📝 Disclaimer:
This blog post was written with the assistance of AI (ChatGPT by OpenAI) to help structure the narrative, clarify technical concepts, and polish the content. The code examples and architectural decisions are based on real-world implementation.

Mastering React Query: A Comprehensive Guide

Raghuveer Bharadwaj — Wed, 22 May 2024 17:04:34 +0000

Tired of juggling Axios and useEffects for API calls and managing dependencies? Say hello to React Query! 🎉 It makes your life easier with automatic caching, synchronization, background updates, and so much more. 🚀

Traditional Way of API Calling

In the traditional way, you typically use Axios inside a useEffect hook to make API calls and manage state manually. Here's an example:

import React, { useState, useEffect } from 'react';
import axios from 'axios';

const TraditionalAPIComponent = () => {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await axios.get('https://api.example.com/data');
        setData(response.data);
        setIsLoading(false);
      } catch (error) {
        setError(error);
        setIsLoading(false);
      }
    };

    fetchData();
  }, []);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <h1>Data:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default TraditionalAPIComponent;

Using React Query (useQuery)

React Query simplifies data fetching by providing hooks that manage caching, synchronization, and background updates out of the box. Here's how you can do the same thing with React Query:

import React from 'react';
import { useQuery } from 'react-query';
import axios from 'axios';

const fetchData = async () => {
  const { data } = await axios.get('https://api.example.com/data');
  return data;
};

const ReactQueryComponent = () => {
  const { data, error, isLoading } = useQuery('fetchData', fetchData);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;

  return (
    <div>
      <h1>Data:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default ReactQueryComponent;

Adding Dependencies with useQuery

Sometimes, you need to fetch data based on certain dependencies. In the traditional way, you'd do this with useEffect like so:

useEffect(() => {
    // Your fechUserData API call

    fetchUserData(userId);
  }, [userId]);

With React Query, you can handle dependencies by using the queryKey and enabled option:

const { data, error, isLoading } = useQuery(['userData', userId], () => fetchUserData(userId), {
    enabled: !!userId, // Ensure query is enabled only if userId is truthy
  });

Control Cache Time

To control cache timing in React Query, you can utilize the cacheTime option within the useQuery hook. This option dictates how long the fetched data remains in the cache before it's considered outdated and possibly removed. Here's how to implement it:

const { data, error, isLoading } = useQuery('fetchData', fetchData, {
    cacheTime: 3600000, // Cache data for 1 hour (3600000 milliseconds)
  });

Invalidation with useInvalidateQuery

React Query provides the useInvalidateQuery hook to invalidate specific queries. This is useful when you want to refetch data based on certain events, such as user actions or changes in application state.

const { data, error, isLoading } = useQuery('fetchData', fetchData);
  const invalidateQuery = useInvalidateQuery('fetchData');

  const handleButtonClick = () => {
    // Invalidates the 'fetchData' query, triggering a refetch
    invalidateQuery();
  };

Using useMutation for update calls

useMutation is a hook provided by React Query that simplifies data mutation operations in your React components. It encapsulates common tasks such as making HTTP requests, handling loading and error states, and updating data in response to mutations.

const updateUser = async (userData) => {
  const response = await axios.put('https://api.example.com/users', userData);
  return response.data; // Updated user data
};

const [mutate, { isLoading, isError, error, data }] = useMutation(updateUser);

// Execute mutation
const handleUpdateUser = async () => {
  try {
  await mutate({ id: 123, name: 'John Doe', email: 'john@example.com' });
  } catch (error) {
    console.error('An error occurred:', error);
  }
};

Using useInfiniteQuery for paginated API calls

useInfiniteQuery is a hook provided by React Query that simplifies pagination operations in your React components. It enables infinite scrolling by fetching data in chunks as the user scrolls, providing a seamless and efficient browsing experience.

import React from 'react';
import { useInfiniteQuery } from 'react-query';
import axios from 'axios';

// Define fetch function
const fetchPosts = async ({ pageParam = 1 }) => {
  const response = await axios.get(`https://api.example.com/posts?page=${pageParam}`);
  return response.data;
};

const PostList = () => {
  const {
    data,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
    isError,
    error,
  } = useInfiniteQuery('posts', fetchPosts, {
    getNextPageParam: (lastPage, allPages) => lastPage.nextPage, // Extract next page number
  });

  return (
    <div>
      {data.pages.map((page, index) => (
        <React.Fragment key={index}>
          {page.posts.map((post) => (
            <div key={post.id}>{post.title}</div>
          ))}
        </React.Fragment>
      ))}
      {isError && <div>Error: {error.message}</div>}
      {hasNextPage && (
        <button onClick={() => fetchNextPage()} disabled={isFetchingNextPage}>
          {isFetchingNextPage ? 'Loading more...' : 'Load More'}
        </button>
      )}
    </div>
  );
};

export default PostList;

Conclusion

In wrapping up, React Query's hooks are like magic wands for handling data in React apps! Whether it's fetching data with useQuery, updating with useMutation, or endless scrolling with useInfiniteQuery, React Query simplifies everything. It's the secret sauce that makes building React apps a breeze, freeing you to focus on creating awesome user experiences. So wave goodbye to data headaches and hello to smooth sailing with React Query! ✨🚀