Forem: Vivek Lagshetti

🔥 Deep Dive into useCallback: Why Functions Break Memoization & How React Fixes It

Vivek Lagshetti — Fri, 12 Sep 2025 07:44:30 +0000

If you’ve been working with React and performance optimization, you’ve probably heard of React.memo, useMemo, and useCallback.

Most tutorials show you “surface-level” examples, but today we’ll go deeper into useCallback — how JavaScript handles function references, why they cause unnecessary re-renders, and how React solves it under the hood.

Let’s get started. 🚀

🧠 The Root Problem: Functions Are Objects

In JavaScript, functions are objects.

That means every time you declare a function inside a component, a brand-new function object is created in memory on every render.

Even if two functions look the same, they don’t share the same reference.

👉 This becomes a problem when passing functions as props.

🔴 Without useCallback: Function References Break Memoization

👉 What happens here?

Parent re-renders whenever count changes.
Each render creates a new function reference for handleClick.
React.memo in Child compares props → sees onClick as changed (new reference).
Child re-renders unnecessarily

🟢 With useCallback: Stable Function Reference

Now the child doesn’t re-render unless it needs to. 🎉

⚡ How useCallback Works Internally

const fn = useCallback(callback, deps);

React does this internally:
Checks if there’s a previous function stored in the hook state.
Compares the new deps array with the old one (shallow compare)
- If deps are the same → reuse the old function reference.
- If deps changed → create and store a new function reference.

function useCallback(fn, deps) {
  const last = getHookState(); // { fn, deps }
  if (last && shallowEqual(last.deps, deps)) {
    return last.fn; // reuse reference
  }
  setHookState({ fn, deps });
  return fn; // new reference
}

So useCallback is basically a function reference cache.

🎯 The Mystery of the Empty Array []

When you write:

const fn = useCallback(() => {
  console.log("Hello");
}, []);

[] → no dependencies.
React creates the function once and always returns the same reference.
Perfect for callbacks that don’t depend on any state/props.

But ⚠️ watch out for the stale closure trap.

🕳️ The Closure Trap

const [count, setCount] = useState(0);

const logCount = useCallback(() => {
  console.log(count);
}, []); // empty deps

First render: count = 0.
Function is created with count = 0.
Even when count updates → function still closes over old value.

So logs will always show 0.

✅ Fix by adding dependencies:

const logCount = useCallback(() => {
  console.log(count);
}, [count]); // updates with count

Now, the function is recreated whenever count changes.

⚖️ When to Use useCallback

✅ When passing functions to React.memo child components.
✅ When functions are dependencies of other hooks (useEffect, useMemo).
❌ Don’t wrap every function blindly → unnecessary overhead.

🚀 Final Recap

Functions in JS are objects → new reference each render.
React compares references, not contents.
useCallback stabilizes function references until dependencies change.
[] = never change (but beware stale closures).
Works best with React.memo to prevent child re-renders.

🔗 If you’ve mastered useMemo and React.memo, useCallback is the missing piece that completes the optimization trio.

👉 Next time your child keeps re-rendering even though “nothing changed” — check if you forgot useCallback.

⚡ Optimizing React Performance with React.memo (Real-Time Example)

Vivek Lagshetti — Fri, 12 Sep 2025 06:15:36 +0000

We often hear about useMemo, useCallback, and React.memo — but what exactly does React.memo do, and when should you use it?

Let’s explore with a real-time example using a Parent → Child component scenario.

🔴 Without React.memo

Here’s a simple setup:

Parent has two states: count and text
Child always receives a static prop (value="Static Prop")

👉 Problem:

Whenever you click Increase Count, the child re-renders unnecessarily. You can confirm this by checking the console logs.

🟢 With React.memo

Now let’s wrap our Child with React.memo.

This tells React:

“Only re-render this component if its props actually change.”

👉 Now, when you click Increase Count,

The Parent re-renders (as expected)
But the Child does NOT re-render, since its props remain the same

🎉 Check the console — you’ll see that the child only renders once, no matter how many times you increase the count.

✅ Advantages of React.memo

Prevents unnecessary re-renders of child components
Improves performance in large component trees
Works best with pure components (output depends only on props)

⚡ Key Difference (React.memo vs useMemo)

useMemo → Memoizes values/calculations inside a component
React.memo → Memoizes entire components to skip re-rendering when props don’t change

🚀 Takeaway

If you’re passing static props (or props that rarely change) to child components, React.memo is a simple and powerful way to avoid wasteful re-renders.

💡 What about you? Do you use React.memo in your React projects? Have you ever faced unnecessary re-render issues? Let’s discuss!

Even though the child’s props never change, it still re-renders whenever the parent re-renders.

🚀 Optimizing React Performance with useMemo Hook (Real-Time Example)

Vivek Lagshetti — Fri, 12 Sep 2025 05:52:56 +0000

When building React apps, performance optimization often feels like an afterthought — until your app starts lagging. One common issue is expensive re-calculations happening on every render, even when they’re not needed.

In this post, I’ll show you a real-time example of how useMemo can help us optimize our app with proof by comparing two components:

Without useMemo ❌ → Filtering happens on every render
With useMemo ✅ → Filtering only happens when search changes

🐢 Without useMemo

Here’s a simple example where we have 5,000 users and a search bar.

Every time we type something or even click a button unrelated to the search, React re-runs the filtering logic across all 5,000 users.

👉 Try clicking the Increase Count button — even though it has nothing to do with the search, the filter runs again, wasting CPU cycles.

⚡ With useMemo

Now, let’s optimize it with useMemo.

We’ll memoize the filtered list so that React only recomputes when search changes, not when unrelated state (count) changes.

👉 Now, open the console and try again. You’ll notice “Filtering users…” only logs when you change the search input, not when you click the button. 🎉

🧠 When to Use useMemo

✅ Expensive computations (like filtering, sorting, complex calculations)

✅ When you notice re-renders impacting performance

✅ For lists, tables, or search-heavy components

⚠️ Don’t overuse it — useMemo itself adds a small overhead. Use it where you know recalculations are costly.

🚀 Key Takeaway

With just one hook (useMemo), we avoided unnecessary computations and made our app more efficient.

Performance optimizations like this might seem small, but at scale (large data, heavy UI), they make a huge difference.

💡 What about you? Have you faced performance issues in your React apps? Did useMemo or useCallback help you fix them?

👇 Drop your thoughts in the comments!

Understanding Event Delegation in React: Before & After

Vivek Lagshetti — Thu, 11 Sep 2025 13:10:38 +0000

When we build web applications, handling user interactions (like clicks, key presses, or form submissions) is a crucial part of the job. But the way we handle these events has changed a lot over the years. One of the key improvements is something called event delegation.

Let’s walk through this concept step by step — starting from how we used to do it before delegation existed, and how React improved it.

📍 Before Event Delegation: Direct Event Binding

In the early days of JavaScript, if you wanted to make multiple buttons respond to clicks, the straightforward way was to attach an event listener directly to each button.
Example:

👉 What this means:

Every element gets its own event listener.
If you had 1,000 buttons, you’d end up with 1,000 listeners in memory.

⚠️ Problems with this old method:

Performance issues: Too many listeners slow down the page.
Memory overhead: Each listener takes space.
Maintenance headache: If you remove an element, you also need to remove its listener.
Cross-browser quirks: Different browsers handled events differently.

Enter Event Delegation

Here’s where event delegation comes in. Instead of attaching listeners to every element, you attach one listener to a parent element (or even the document).

This works because of event bubbling:

When you click a child element, the event travels (or “bubbles up”) through its ancestors until it reaches the root.
The parent can “catch” that event and figure out which child triggered it.

Example:

👉 What changed:

One single event listener on the parent handles all child button clicks.
Adding or removing buttons doesn’t require attaching/removing new listeners.

✅ Improvements:

Better performance.
Less memory usage.
Easier DOM updates.

📍 React’s Approach: Synthetic Events + Delegation

React takes this idea further. When you write:

…it looks like you’re attaching a listener directly to the button. But under the hood, React does not put a listener on every button.

🔧 What React does instead:

React attaches a single listener (per event type, like click) at the root level.
When a real DOM event happens, React intercepts it.
React creates a SyntheticEvent — a wrapper that normalizes browser differences (so you don’t worry about inconsistencies like event.target vs event.srcElement).
React dispatches the event internally to the correct component’s onClick handler.

🚀 Final Thoughts

Event delegation transformed how we handle user interactions. Instead of cluttering every element with its own event listener, we now rely on bubbling and centralized listeners.

React supercharged this by introducing its Synthetic Event system, making event handling:

Faster
Safer across browsers
Easier to maintain

So next time you write an onClick in React, remember—it’s not attached to your button directly. React is quietly handling it for you through delegation.