DEV Community: Akash Kumawat

Who Actually Builds Your HTML? A Field Guide to CSR, SSR, SSG, ISR and Server Components 🏗️

Akash Kumawat — Mon, 14 Sep 2026 10:56:22 +0000

You've been shipping React for a while. Components, hooks, state, the whole thing. Then someone in a code review drops a casual "is this bit SSR or CSR?" and you nod like you know, then quietly open a new tab.

Been there. 😅

The problem isn't that these concepts are hard — it's that they get explained as a list of acronyms when they're really answers to the same small set of questions. So let's throw out the list and start with the question.

🧐 The One Question That Explains All of It

Every rendering strategy is an answer to this:

When and where does your HTML get built?

That's it. Three possible "whens" — at build time, at request time, or in the browser — and two possible "wheres" — your server or the user's device. Every acronym you've been squinting at is just a combination of those.

Once that clicks, server components vs client components turns out to be a different question entirely (we'll get there), and half the confusion disappears.

🎨 CSR: The Empty Div

Client-Side Rendering is what you get out of the box with Vite, Create React App, or any plain React setup. The server sends the browser this:

<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>

That's your entire page. An empty div and a promise. The browser downloads the JavaScript, runs it, React builds the DOM, and then the user sees something.

Think of it like ordering food and getting a bag of raw ingredients plus a recipe card. Everything you need is in there! You just have to do the cooking.

What's good about it: The server does almost nothing, so it's cheap and easy to host. Once the app boots, navigating between pages is instant — no round trips, just state changes. It's a genuinely great fit for dashboards, editors, and anything behind a login.

What hurts: The user stares at a blank screen until the bundle downloads and parses and runs. On a slow phone on slow data, that's painful. And because the initial HTML is empty, anything that reads your page without running JavaScript — search crawlers, link preview bots, some accessibility tooling — sees nothing.

🍳 SSR: The Kitchen Cooks It For You

Server-Side Rendering flips it. On every request, your server runs your components, produces real HTML, and sends that:

<body>
  <div id="root">
    <h1>Hello, Akash</h1>
    <p>You have 3 new messages</p>
  </div>
  <script src="/bundle.js"></script>
</body>

The user sees content almost immediately. The meal arrives cooked.

But look at that <script> tag — it's still there. The HTML is just a picture. Buttons don't click, inputs don't type, nothing is wired up. The browser still downloads the same bundle, runs React, and React walks the existing DOM attaching event listeners to it.

That process is called hydration, and it's the part everyone skips.

So the meal arrives hot, but the cutlery is delivered separately and you can't actually eat until it shows up. There's a real window where your page looks ready and isn't. Users notice — they click, nothing happens, they click again.

What's good: Fast first paint, fresh data on every request, crawlers get real content.

What hurts: Your server does work on every single request, so it costs more and it's slower to start responding (the server has to fetch data and render before it can send anything). And you've now got a gap between "looks interactive" and "is interactive."

🥡 SSG: Sunday Meal Prep

Static Site Generation builds the HTML once, at build time, and serves the same file to everyone.

// Next.js — no dynamic functions, no per-request data
export default async function BlogPost({ params }) {
  const post = await getPost(params.slug); // runs at build
  return <article>{post.body}</article>;
}

You run next build, it generates one HTML file per blog post, those files go on a CDN, done. The server does zero work per request because there is no per-request work — it's just handing over a file that already exists.

This is unbeatable on speed. Nothing renders faster than a file sitting on a CDN twenty kilometres from the user.

The catch: that file is frozen at build time. Fix a typo? Rebuild. Prices changed? Rebuild. Got 50,000 product pages? Enjoy your 40-minute build. 🙃

Perfect for blogs, docs, marketing pages, changelogs. Anything where the content changes on your schedule, not the user's.

🥖 ISR: The Bakery Model

Incremental Static Regeneration is SSG that admits the real world exists.

The idea: serve the cached static page instantly, but if it's older than some threshold, quietly bake a fresh one in the background for the next person.

// Next.js App Router
export const revalidate = 60; // seconds

Here's the sequence with a 60-second window:

First request → page is generated, cached, served.
Requests within 60s → served from cache. Instant.
Request at 61s → still served the stale cached page (instantly), and a regeneration kicks off in the background.
Next request → gets the fresh one. Nobody ever waits for the rebuild. Somebody just gets slightly old bread. That trade — "instant but maybe a minute stale" — is exactly right for e-commerce listings, news feeds, leaderboards, anything high-traffic where a 60-second delay is invisible to users but a full SSR bill would hurt.

Most frameworks also let you trigger regeneration on demand, so you don't have to guess a number:

// Someone edited a post in your CMS → webhook hits this
revalidatePath('/blog/my-post');

Now it's static and fresh the moment content actually changes. Best of both, honestly. This is the one I'd reach for by default on any content-driven site.

📊 The Cheat Sheet

	HTML built	Per-request server work	First paint	Data freshness
CSR	In the browser	None	Slowest	Fresh (after fetch)
SSR	On the server, per request	Every request	Fast	Always fresh
SSG	At build time	None	Fastest	Stale until rebuild
ISR	Build time + background refresh	Occasional	Fastest	Stale by up to N seconds

And the thing that actually matters: these are per-route, not per-app. Your marketing page can be SSG, your product listing ISR, your dashboard CSR, your checkout SSR. Modern frameworks let you mix all four in one codebase, and you should.

🧩 Now The Other Axis: Server vs Client Components

Here's where people get tangled, so let's be blunt about it:

SSR vs CSR is about where HTML is generated. Server vs Client Components is about where your component's code lives.

Different questions. You can have both at once. A React Server Component is not "a component that gets SSR'd" — plenty of client components get SSR'd too.

What a Server Component actually does

A Server Component runs on the server and its JavaScript never reaches the browser at all.

// No 'use client' — this is a Server Component by default (App Router)
import { marked } from 'marked'; // a chunky markdown library

export default async function Post({ id }) {
  const post = await db.posts.find(id); // talk to the DB directly
  return <article dangerouslySetInnerHTML={{ __html: marked(post.body) }} />;
}

Two things just happened that are genuinely new:

You queried your database inside a component. No API route, no useEffect, no loading state.
That marked library — all 40-ish KB of it — never ships to the user. It ran on the server and only the resulting HTML crossed the wire. That second point is the whole pitch. With SSR, your bundle contains every component on the page. With Server Components, it contains only the interactive ones.

What Client Components actually are

'use client';

import { useState } from 'react';

export default function LikeButton({ initialCount }) {
  const [count, setCount] = useState(initialCount);
  return <button onClick={() => setCount(count + 1)}>❤️ {count}</button>;
}

'use client' is the thing everyone misreads. It does not mean "render this only in the browser." This component still gets rendered on the server into HTML, same as always — it just also ships its JavaScript so it can hydrate and become interactive.

So the label is really: "this component needs to exist on the client too."

You need it whenever you use:

useState, useEffect, useReducer, or any hook with state
Event handlers — onClick, onChange, onSubmit
Browser-only APIs — window, localStorage, IntersectionObserver
Most third-party UI libraries (they're full of the above) ### It's a boundary, not a label

This is the part worth tattooing somewhere:

'use client' marks a boundary. Everything imported from a client component becomes a client component too.

Put 'use client' at the top of your root layout and congratulations — you've just opted your entire app back into the old model. 😬

The instinct is to fight this by hoisting 'use client' upward. Do the opposite: push it down to the leaves. Don't mark the whole page as a client component because there's one button on it. Mark the button.

And when a client component needs to wrap server content, pass it through as children rather than importing it:

// ✅ Accordion is a client component, but Post stays on the server
<Accordion>
  <Post id={1} />
</Accordion>

The <Post /> element is created on the server and handed to Accordion as an already-rendered child. Accordion never imports it, so it never drags it into the client bundle. This pattern will save you more kilobytes than any other single thing you do.

The rules you'll trip over

Props crossing from server → client have to be serializable. Strings, numbers, arrays, objects, dates — fine. Functions, class instances, Symbol — not fine, and you'll get an error that takes a minute to decode.

// ❌ Can't send a function across the boundary
<ClientThing onSave={(data) => db.save(data)} />

The escape hatch is Server Actions, which are functions the server exposes and the client calls by reference — but that's a whole post of its own.

😱 Pitfalls: The Five Everyone Hits

1. Thinking 'use client' means client-only. It doesn't. It means "also on the client." Your component still renders on the server, so window is not defined will still bite you at the top level.

2. Slapping 'use client' on the root layout. One directive, entire app back to full hydration. Push it to the leaves.

3. Assuming SSR is automatically faster. SSR improves first paint but delays time-to-first-byte (server has to fetch and render first). For an app that's already behind a login screen, CSR is often the better call.

4. Ignoring the hydration gap. The window where the page looks ready but isn't is real, and it's where confused double-clicks live. Streaming and Suspense boundaries are how you shrink it.

5. Picking one strategy for the whole app. This is the big one. These are route-level decisions. Mix them.

🚀 So What Do You Actually Pick?

Rough heuristics that hold up well:

Content that rarely changes (blog, docs, landing) → SSG
Content that changes but not per-user (product pages, feeds) → ISR
Personalized or always-fresh (dashboards with server data, search results) → SSR
Heavily interactive, behind auth, SEO irrelevant (editors, admin panels) → CSR is fine, genuinely
Components → server by default, client only where you need interaction, boundary as low as possible And the same advice I'd give about any optimization: measure before you commit. Ship it, look at your actual TTFB and FCP and bundle size, then decide. The right answer for a Bengaluru user on a mid-range Android and a reviewer on a MacBook are not always the same answer. 📱

🎉 Wrapping Up

Strip the acronyms away and there are only two questions:

When does the HTML get built? → build time (SSG), build time + refresh (ISR), per request (SSR), or in the browser (CSR)
Does this component's code need to ship to the browser? → no (server component) or yes (client component) Everything else is detail. And the nice part is you don't have to pick one and live with it — pick per route, pick per component, and change your mind when the numbers tell you to.

Happy Coding :))

useCallback: Keeping Your Functions in Check, Literally 🧑‍💻

Akash Kumawat — Sun, 13 Oct 2024 05:18:31 +0000

You know the feeling — everything’s working great, but then, your app starts slowing down, and you’re left wondering: "Why, React? Why are you like this?" One of the sneaky culprits? React loves recreating functions every time it re-renders a component, like it’s some kind of hobby. But here comes useCallback to save the day, keeping your functions in line and making sure React doesn’t go overboard.

Let’s break it down!

Why Does React Keep Making New Functions? 🤔

So here’s the deal. Every time React re-renders a component, it creates brand-new functions — even if those functions do the exact same thing as before. This happens because React doesn’t remember function references between renders. Every single time React runs, it's like, "Let’s create a fresh one, just in case."

Seems harmless, right? But it can cause performance issues, especially when you’re passing those new functions down to child components. React thinks, “Oh, new function? Must be new props!”—and then it triggers a re-render of the child component, even when it doesn’t need to.

Enter `useCallback`: Your Function Stabilizer 🦸‍♂️

This is where useCallback steps in like the hero React didn’t know it needed. Instead of creating new functions on every render, useCallback lets you say, “Hey React, unless something important changes, just keep using the same function.”

How does it work? Like this:

const myFunction = useCallback(() => {
  // Logic goes here
}, [dependencies]);

That dependencies array is the key. React will only create a new version of the function if something in the array changes. Otherwise, it’s the same trusty function from the last render. Smooth sailing from here! 🚢

When to Call in `useCallback` ⚙️

Here are some situations where useCallback really shines:

1. Passing Functions to Child Components

If you’re passing a function as a prop to a child component, React will recreate that function every time the parent re-renders. This means the child component will also re-render because React thinks the function prop is different.

With useCallback, you can tell React to use the same function unless something in the dependencies changes. No more unnecessary re-renders for your child components!

2. Memoized Components + Functions

Using React.memo to prevent unnecessary re-renders? Awesome. But if you’re passing a fresh function every time, you’re still gonna get those re-renders. Pair React.memo with useCallback, and you’ve got yourself a super team to block unwanted re-renders.

3. Event Handlers that Depend on State

Imagine you’ve got a button with an onClick handler that relies on state. Normally, React will recreate that handler every time the state updates. But with useCallback, you’re telling React, “Hey, no need to recreate this function unless the state it depends on actually changes.”

But Don’t Go Overboard 🚨

Now, before you wrap useCallback around every function like it’s the answer to life, the universe, and everything, here’s the deal: Not every function needs it. If your component doesn’t re-render often or the performance gains are negligible, you’re better off skipping useCallback. In fact, using it unnecessarily can make your code more complicated and even take up extra memory.

Use it where it counts — like with functions that are passed down as props or in heavy components that need some optimization love.

Wrapping it Up 🎁

At the end of the day, useCallback is like your function stabilizer, making sure React doesn’t go wild recreating functions on every render. It’s a lifesaver when you’re trying to optimize performance, but it’s not a tool for every situation. Use it where it makes sense, and your app will thank you for it.

With useCallback, your functions don’t have to be the cause of unnecessary re-renders anymore. It’s time to get those functions under control! 😎

Happy Coding :))

React.memo: The Bouncer for Unnecessary Re-renders 💃

Akash Kumawat — Mon, 07 Oct 2024 18:23:16 +0000

Imagine your React app is like a busy nightclub. Everything’s going great — music’s bumping, people are having fun—until suddenly, the crowd grows, and things slow down. You’re thinking, “Whoa, this party’s getting out of hand!” That’s when React.memo steps in, acting like the club bouncer. It only lets in the folks (or props) that actually need to be there, keeping the party smooth without the unnecessary chaos of extra re-renders.

Let’s check out how React.memo works its magic and when it’s time to call in this re-rendering bouncer!

Putting Up the Velvet Rope with React.memo 🛑

By default, React’s like the friend who invites everyone to the party—re-rendering components left and right, just to make sure everything’s updated. Even if nothing’s really changed, React’s still like, “Better safe than sorry, let’s re-render!” 😅

That’s where React.memo comes in. It’s like, “Hold up! If the props haven’t changed, you’re not getting in. No need for a re-render.”

Example:

const CoolComponent = React.memo((props) => {
  // Your awesome component logic here
});

Now, with React.memo, your component won’t re-render unless its props actually change. No more extra partygoers slowing down the fun! 🎉

When to Use React.memo Like a Boss 💼

So, when should you bring in React.memo? The golden rule: use it when you’ve got components that rely heavily on props and don’t need to re-render unless those props change.

But hey, don’t go wild! React.memo isn’t meant for every single component. If your component is small, has simple props, or doesn’t re-render often, you can skip it. React already knows what it’s doing most of the time. 🧘‍♂️

Here’s when React.memo really shines:

Pure components: Components that only rely on props to render.
Expensive components: If rendering takes a lot of effort, like heavy calculations or complex UI elements.
Lists or grids: When you have items that don’t change often. Let those list items sit back and relax without re-rendering constantly.

The Kryptonite: Where React.memo Might Let You Down 🦸‍♂️💔

Even the best bouncers can make mistakes, and React.memo is no different. It has a few weaknesses:

Objects and arrays as props: React.memo doesn’t do a deep dive into your objects and arrays—it just checks the reference. So, if you create a new array or object on every render (even if it’s identical), React.memo will think it’s different and still re-render.

Pro tip: Use useCallback or useMemo to prevent new object or array references from being created unless necessary.

Heavy logic inside your component: If your component does a ton of calculations or has expensive logic, React.memo might not help much. Even if it skips a render, you’ll still pay the price of that logic running. In cases like this, you may want to rethink where your logic lives.

Don’t Overdo It! 🧘‍♀️

It might be tempting to wrap every component in React.memo to speed things up, but honestly? That’s overkill. If your component is simple and doesn’t suffer from frequent re-renders, React.memo can actually slow things down a bit because it has to check the props every time.

Remember: React is already pretty smart at handling updates, so you don’t need to throw React.memo everywhere. Use it wisely, like a VIP pass for your more complex or frequently updated components.

Wrapping It Up 🎁

React.memo is like the perfect party bouncer — stopping those unnecessary re-renders from getting into your component and messing things up. But like any good bouncer, it’s important to know when you actually need it. For most components, React’s got things covered, but when you need that extra bit of control, React.memo is your go-to.

So, next time your app starts feeling a little sluggish, check out React.memo to keep things running smoothly — and maybe even a bit cooler. 😎

Stay tuned for more tips on managing re-renders like a pro! 🎉

Happy Coding :))

Why So Many Re-renders, React? 🤔

Akash Kumawat — Wed, 02 Oct 2024 14:21:07 +0000

We’ve all been there — your React app is running smoothly, you’re feeling good, and then... BAM! Suddenly, everything slows down and you’re thinking, “What’s going on here?” 🧐 Unnecessary re-renders, my friend! They’re like those unexpected guests at a party: no one invited them, but here they are, eating your snacks and slowing everything down.

Let’s break down why React loves to re-render (a little too much sometimes) and what’s really going on under the hood.

1. State Changes: The Serial Re-render Offender

Whenever you update state in React, it’s like hitting refresh on your whole component. React’s like, “Oh, you changed something? Let me just re-render EVERYTHING.” Even if it’s a tiny update, React is all in. It’s like the over-enthusiastic friend who keeps tidying up the room while you’re still hanging out.

Example:

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

const increment = () => setCount(count + 1);

Every time you hit setCount, React’s like, “Let’s re-render the whole component, just in case!” Sure, it means your state’s always up-to-date, but all this re-rendering can lead to performance hits if your app is doing some heavy lifting. It's like overreacting to a small spill by cleaning the entire house. 🧹

2. Props Change: React’s Like, “New Props, Who Dis?”

React is super reactive (no pun intended) to prop changes. The moment a prop changes, React goes, “Wait, is that a new prop? Better re-render the child component, just to be safe.” Even if the child doesn’t care about the new prop, React re-renders it like it’s the end of the world.

Example:

<ChildComponent data={someArray} />

Whenever someArray changes (even if it’s just adding one item), React’s like, “Time to re-render the whole ChildComponent!” It’s basically that one overprotective friend who jumps at every minor inconvenience: “Oh, new data? Let’s redo everything!” 🙃

3. Parent Component Re-renders: The Domino Effect

This is the ultimate React drama. If the parent component re-renders, React drags all the kids along for the ride, even if they had nothing to do with the change. It’s like inviting yourself to a party and bringing a bunch of friends who didn’t even want to come. 😅

Example:

function ParentComponent() {
  const [parentState, setParentState] = useState(0);

  return (
    <>
      <ChildComponent />
      <AnotherChildComponent />
    </>
  );
}

Every time the parent re-renders, both ChildComponent and AnotherChildComponent are like, “Wait, what did we do? Why are we here?” This can be fine for small apps, but in a larger, more complex app, this over-enthusiasm can really slow things down.

4. Inline Functions & Objects: The Sneaky Culprits

Inline functions and objects might look innocent, but they're secretly wreaking havoc. Every time React re-renders, it creates new instances of these functions and objects, even if they’re technically doing the same thing. React looks at them and goes, “New reference? Must be different. Better re-render!”

Example:

<ChildComponent onClick={() => doSomething()} />

Each time the parent re-renders, React sees the new inline function as a completely new prop for ChildComponent. It’s like you just gave React a shiny new toy, and it has no idea that the toy is actually the same one it had before. So it re-renders. React’s just trying its best, okay? 😅

5. React’s Motto: Better Safe Than Sorry

React’s philosophy is pretty much “better safe than sorry.” It would rather re-render too much than risk missing something important. It’s like that overly cautious friend who triple-checks everything before heading out the door. This keeps the UI in sync with the state, but can lead to React doing way more than it needs to.

Conclusion

So, why all the re-renders? It’s because React just wants everything to stay updated and correct. But sometimes, it can be a little too cautious, leading to unnecessary performance issues. Don’t worry, though! We’ve got plenty of tricks up our sleeves to tame React’s re-rendering habits — like React.memo, useCallback, and other optimization tools.

Stay tuned for the next part, where we dive into the hacks to calm React down and stop the re-renders from crashing your app's party. 🎉

Happy Coding :))

React Re-render Saga: Stopping the Madness, One Trick at a Time 🤯

Akash Kumawat — Thu, 26 Sep 2024 13:01:19 +0000

Welcome to the React Re-render Saga, where we go full throttle into optimizing your React app and stopping those sneaky re-renders from ruining your vibe. We’ll break it down into bite-sized, meme-worthy posts to help you level up your React game. Let’s keep things smooth and fast, because ain’t nobody got time for laggy apps! 🏃‍♂️💨

Post 1: Why So Many Re-renders, React? 🤔

Let’s kick things off by answering the big question: Why does React re-render so much?!

In this post, we’ll dive into:

How state and props make React trigger happy.
Why even a small change can cause React to re-render like it’s got something to prove.
The classic parent-child re-render domino effect (seriously, it’s like React thinks we’re building a chain reaction for fun).

By the end, you'll know exactly what’s causing all these rerenders and be pumped for the solutions that are coming next. Time to flex those React muscles 💪!

Post 2: 🛡️ React.memo: The Bouncer for Unnecessary Re-renders

In this post, we’re rolling out the big guns. React.memo is like the bouncer at a club, stopping any unnecessary re-renders at the door.

We’ll cover:

How React.memo puts up the velvet rope so only changed props get through.
When to use React.memo like a pro (and when to chill out with it).
Avoiding common pitfalls, because even React.memo has its kryptonite.

Post 3: 🔗 useCallback: Keeping Your Functions in Line, Literally

Functions, right? React loves recreating them like it’s a hobby. useCallback is here to stop that madness and keep your functions in check.

In this post:

We’ll break down why React loves creating fresh functions on every render (like, why tho?).
How useCallback keeps your functions from being “new” every time (stability, baby!).
Real-life scenarios where useCallback is the MVP of performance.

Post 4: 💾 useMemo: Let’s Remember the Important Stuff

Expensive calculations? 😰 You need useMemo, the ultimate memory keeper! It saves those heavy-lifting operations for when you really need them.

We’ll dive into:

How useMemo saves you from recalculating the same stuff over and over.
When useMemo is your best friend (and when you can just wing it).
Perfect use cases that’ll make your app lightning fast ⚡.

Post 5: 🕵️‍♂️ useRef: The Sneaky Sidekick That Keeps Quiet

useRef is like that friend who’s always there, watching things quietly but never causing any drama. You can store stuff in it, but unlike useState, it won’t make React freak out and re-render!

In this post:

We’ll show you when useRef is better than useState (hint: when you want to store stuff without re-renders).
How to use it to keep track of DOM elements or store previous state without causing React panic.
A bunch of sneaky tricks to make your app perform smoother than ever.

Post 6: 👶 Combining React.memo & useCallback: The Dynamic Duo

When React.memo and useCallback team up, it’s like Batman and Robin—together, they’re unstoppable at preventing rerenders! 🦇🦸‍♂️

In this post:

We’ll show you how to combine these two for ultimate child component efficiency.
Examples where the parent-child rerender drama finally ends (spoiler: peace restored ✌️).
How to make sure neither parent nor child re-renders unnecessarily.

Post 7: 🎟️ Keys in Lists: Give Each Item a VIP Pass

Without unique keys, React's like, “Who’s who?”—and boom! Everything re-renders. Let’s stop that.

In this post:

Learn why unique keys are like VIP passes for your list items 🎫.
Why not having keys is like inviting chaos (or re-renders) into your life.
Best practices to ensure smooth rendering of dynamic lists.

Post 8: 🚫 Avoid Inline Functions & Objects: Silent Performance Killers

Creating inline functions or objects in your JSX is a trap! It seems harmless, but it’s like inviting React to re-render everything for no reason. 😵‍💫

In this post:

We’ll break down why inline functions and objects are bad news for performance.
How to refactor your code so React doesn’t lose its cool.
Real-world examples to make sure you’re never caught in the inline trap again.

Post 9: ⏳ Lazy Loading: Why Do Today What You Can Do Tomorrow?

Finally, let’s talk about Lazy Loading. React’s motto here: “Why render the whole thing when you can do it later?” ⌛

In this post:

How to use React.lazy and Suspense to load components only when you actually need them.
How lazy loading helps with performance by not overloading your app at once.
Examples to show how chill React becomes when you don’t make it do everything at once.

🎉 Final Words: The React Re-render Saga Awaits!

Over this series, we’re going to unlock all the secrets to stop unnecessary re-renders in their tracks. By the end, you’ll be the master of React performance, zipping through your app without breaking a sweat. Each post will arm you with new React powers—use them wisely!

Stay tuned for all the React goodness coming your way! ✨ Let’s make React work for us, not against us. Happy optimizing, fellow devs! 🚀

Happy Coding :))

Turbocharging React with useMemo and useCallback: No More Slow Renders! 💨

Akash Kumawat — Tue, 24 Sep 2024 17:07:52 +0000

If you're anything like me, you love how smooth React can be... until it isn't! Yep, as your app grows and becomes more complex, you might start noticing some performance slowdowns. But fear not! React gives us a couple of awesome tools useMemo and useCallback to keep things running fast and smooth.

In this guide, we’ll break down these two hooks in a fun, friendly way, so you can optimize your app without breaking a sweat!

🧐 Wait, Why Bother? Isn’t React Fast Enough?

Great question! React is usually blazing fast. But sometimes, if you’re running expensive calculations or passing a lot of functions through your component tree, things can start to drag a bit. Every time your app re-renders (because props or state changed), React has to re-do a lot of stuff.

That’s where useMemo and useCallback come in. They basically let React “remember” stuff so it doesn’t have to re-do unnecessary work!

🧠 `useMemo`: Making React Remember the Hard Stuff!

Think of useMemo as a smart assistant. It keeps track of the result of a function and only recalculates it if something important changes. Why bother re-doing a calculation when the inputs haven’t even changed? Exactly.

The Basics:

const memoizedValue = useMemo(() => {
  return calculateSomethingExpensive(a, b);
}, [a, b]);

In this example, calculateSomethingExpensive will only run if a or b change. Otherwise, React says, "No need to redo that work — I’ve got it saved right here!"

A Fun Example:

Let’s say we’re building a component that calculates the total value of a shopping cart. Every time the component re-renders, it recalculates that total. Now, if you’re shopping a lot (which we all do!), this calculation might slow down the app:

function ShoppingCart({ items }) {
  const totalValue = items.reduce((sum, item) => sum + item.price, 0);

  return <div>Total: {totalValue}</div>;
}

Even if the items haven’t changed, we’re still doing the math every time! With useMemo, we can tell React to only recalculate when the items array changes:

function ShoppingCart({ items }) {
  const totalValue = useMemo(() => {
    return items.reduce((sum, item) => sum + item.price, 0);
  }, [items]);

  return <div>Total: {totalValue}</div>;
}

Boom! Now your app only recalculates when there’s actually something new in your cart. It’s like React saying, “I’ve got this covered.”

🔥 `useCallback`: No More New Functions Every Second!

Now let’s talk about useCallback. If useMemo is about remembering values, useCallback is about remembering functions. This is super useful when you’re passing a function as a prop to a child component.

Without useCallback, React recreates your function on every render — this can cause your child components to re-render unnecessarily. And we all know how annoying that can be!

The Basics:

const memoizedCallback = useCallback(() => {
  doSomething(a, b);
}, [a, b]);

This tells React to only recreate the doSomething function if a or b change. If not, React just reuses the previous function!

Let’s Break It Down:

Here’s a common scenario: You have a parent component passing down a handleClick function to a child component. But every time the parent re-renders, the function gets recreated, forcing the child to re-render too:

function ParentComponent() {
  const handleClick = () => {
    console.log('Button clicked!');
  };

  return <ChildComponent onClick={handleClick} />;
}

Even if nothing has changed, the child component thinks it needs to re-render because the handleClick function is "new" every time.

Now, let’s be clever and use useCallback to avoid this:

function ParentComponent() {
  const handleClick = useCallback(() => {
    console.log('Button clicked!');
  }, []);

  return <ChildComponent onClick={handleClick} />;
}

Tada! Now the handleClick function only changes if its dependencies change, and the child component doesn’t re-render unnecessarily.

🤔 `useMemo` vs. `useCallback`: What’s the Difference? (Spoiler: Both are Awesome!)

Okay, so now you’re probably thinking, “These two sound pretty similar—what’s the difference?”

useMemo: Caches the result of a function. It’s great when you have some expensive calculation that doesn’t need to be recalculated all the time.
useCallback: Caches the function itself. Perfect when you’re passing functions down as props and want to avoid unnecessary re-renders.

Quick Recap:

Use useMemo to avoid recalculating something unless it’s necessary.
Use useCallback to prevent creating new functions unless their dependencies have changed.

🚀 When Should You Actually Use These Hooks?

Here’s the golden rule: Don’t overuse useMemo and useCallback. Seriously! React is already fast enough for most apps, and using these hooks everywhere can add unnecessary complexity.

When to Use useMemo:

You’re doing something heavy, like filtering or sorting a large list, or performing complex math.

When to Use useCallback:

You’re passing functions down to child components, and you notice those components are re-rendering more than they need to (especially if they’re wrapped in React.memo).

Measure performance before and after using these hooks. If you notice a speed boost, great! If not, maybe it’s not worth the extra complexity.

😱 Pitfalls: Don’t Be That Person!

Overuse: Please, don’t slap useMemo or useCallback on every single function or calculation. It can actually hurt performance if used excessively. Only memoize when you need to.
Wrong Dependencies: If you forget to include the right dependencies in your dependency array, your memoized function might not update correctly. Always double-check what variables your function depends on.

🎉 Wrapping Up: Keep it Fun and Fast!

So there you have it! useMemo and useCallback are awesome tools to keep your React app snappy, but remember—React is already super fast. Use these hooks when you need to optimize performance, but don’t go overboard. Simplicity is key!

With that, go out there and make your app lightning-fast (and have fun while doing it)

DEV Community: Akash Kumawat

Who Actually Builds Your HTML? A Field Guide to CSR, SSR, SSG, ISR and Server Components 🏗️

🧐 The One Question That Explains All of It

🎨 CSR: The Empty Div

🍳 SSR: The Kitchen Cooks It For You

🥡 SSG: Sunday Meal Prep

🥖 ISR: The Bakery Model

📊 The Cheat Sheet

🧩 Now The Other Axis: Server vs Client Components

What a Server Component actually does

What Client Components actually are

The rules you'll trip over

😱 Pitfalls: The Five Everyone Hits

🚀 So What Do You Actually Pick?

🎉 Wrapping Up

Happy Coding :))

useCallback: Keeping Your Functions in Check, Literally 🧑‍💻

Why Does React Keep Making New Functions? 🤔

Enter useCallback: Your Function Stabilizer 🦸‍♂️

When to Call in useCallback ⚙️

1. Passing Functions to Child Components

2. Memoized Components + Functions

3. Event Handlers that Depend on State

But Don’t Go Overboard 🚨

Wrapping it Up 🎁

Happy Coding :))

React.memo: The Bouncer for Unnecessary Re-renders 💃

Putting Up the Velvet Rope with React.memo 🛑

When to Use React.memo Like a Boss 💼

The Kryptonite: Where React.memo Might Let You Down 🦸‍♂️💔

Don’t Overdo It! 🧘‍♀️

Wrapping It Up 🎁

Happy Coding :))

Why So Many Re-renders, React? 🤔

1. State Changes: The Serial Re-render Offender

Example:

2. Props Change: React’s Like, “New Props, Who Dis?”

Example:

3. Parent Component Re-renders: The Domino Effect

Example:

4. Inline Functions & Objects: The Sneaky Culprits

Example:

5. React’s Motto: Better Safe Than Sorry

Conclusion

Happy Coding :))

React Re-render Saga: Stopping the Madness, One Trick at a Time 🤯

Post 1: Why So Many Re-renders, React? 🤔

Post 2: 🛡️ React.memo: The Bouncer for Unnecessary Re-renders

Post 3: 🔗 useCallback: Keeping Your Functions in Line, Literally

Post 4: 💾 useMemo: Let’s Remember the Important Stuff

Post 5: 🕵️‍♂️ useRef: The Sneaky Sidekick That Keeps Quiet

Post 6: 👶 Combining React.memo & useCallback: The Dynamic Duo

Post 7: 🎟️ Keys in Lists: Give Each Item a VIP Pass

Post 8: 🚫 Avoid Inline Functions & Objects: Silent Performance Killers

Post 9: ⏳ Lazy Loading: Why Do Today What You Can Do Tomorrow?

🎉 Final Words: The React Re-render Saga Awaits!

Happy Coding :))

Turbocharging React with useMemo and useCallback: No More Slow Renders! 💨

🧐 Wait, Why Bother? Isn’t React Fast Enough?

🧠 useMemo: Making React Remember the Hard Stuff!

The Basics:

A Fun Example:

🔥 useCallback: No More New Functions Every Second!

The Basics:

Let’s Break It Down:

🤔 useMemo vs. useCallback: What’s the Difference? (Spoiler: Both are Awesome!)

Quick Recap:

🚀 When Should You Actually Use These Hooks?

😱 Pitfalls: Don’t Be That Person!

🎉 Wrapping Up: Keep it Fun and Fast!

Happy Coding :))

Enter `useCallback`: Your Function Stabilizer 🦸‍♂️

When to Call in `useCallback` ⚙️

🧠 `useMemo`: Making React Remember the Hard Stuff!

🔥 `useCallback`: No More New Functions Every Second!

🤔 `useMemo` vs. `useCallback`: What’s the Difference? (Spoiler: Both are Awesome!)