Forem: Mohammad Rajaei Monfared

🚖 Building a Scalable Frontend Mock Architecture with MSW, Factories, and Services (Uber-Like Example)

Mohammad Rajaei Monfared — Thu, 16 Oct 2025 21:30:01 +0000

If you’ve ever built an app that depends on complex backend APIs — like a ride-sharing or delivery platform — you know the pain:

“The backend isn’t ready yet… but I still need to test my UI, maps, and user flows.”

Frontend developers often get stuck waiting for endpoints or using rigid JSON mocks that quickly become outdated.
There’s a better way.

In this article, we’ll explore how to build a scalable mock architecture for your frontend using Mock Service Worker (MSW) — the modern way to simulate APIs directly in the browser or test environment.

We’ll model a simplified Uber-like app with entities like User, Drivers, Vehicles, Wallet, MyLastTrips, and more.

🧠 Note: The entities and examples here are simplified to illustrate the architecture.
Real ride-sharing systems have more complex relationships and data flows.

🧩 Why Traditional Mocks Don’t Scale

Most frontend teams start with something simple:

// mocks/handlers.ts
rest.get('/api/drivers', (req, res, ctx) => {
  return res(ctx.json([{ id: 1, name: 'John', rating: 4.9 }]));
});

It works… until it doesn’t.
When your app grows — filters, pagination, dynamic routes, price estimates, and user-specific logic — this flat mock structure becomes unmaintainable.

The solution?
Design your mocks like a real backend, with clear layers and responsibilities.

🏗 The Layered Mock Architecture

Here’s the folder structure we’ll use:

src/
  mocks/
    handlers/
      driversHandlers.ts
      ridesHandlers.ts
    factories/
      userFactory.ts
      driversFactory.ts
      vehiclesFactory.ts
      walletFactory.ts
      myLocationsFactory.ts
      myLastTripsFactory.ts
    generators/
      carLocationsGenerator.ts
      rideRequestsGenerator.ts
      priceEstimatesGenerator.ts
      routesGenerator.ts
    services/
      ridesService.ts
      driversService.ts
      walletService.ts
    browser.ts
    server.ts

Each layer has a specific purpose:

Layer	Role	Description
`factories/`	Static seed data	Acts as your “mock database”
`generators/`	Dynamic or computed data	Produces live, random, or rule-based data
`services/`	Business logic	Simulates backend operations (search, filters, etc.)
`handlers/`	API interface	Connects MSW routes to your mock services

🧱 Step 1: Factories — The Mock Database

Factories provide static, consistent seed data.
They act like an in-memory database for your mocks.

Here’s a reusable base factory:

// factories/BaseFactory.ts
export class BaseFactory {
  constructor(seed = []) {
    this.seed = seed;
  }

  clone(value) {
    return typeof structuredClone === 'function'
      ? structuredClone(value)
      : JSON.parse(JSON.stringify(value));
  }

  createMany() {
    return this.seed.map((item) => this.clone(item));
  }

  createOne() {
    if (!this.seed.length)
      throw new Error(`${this.constructor.name} has no seed data`);
    return this.clone(this.seed[0]);
  }
}

Then, define your domain factories:

// factories/driversFactory.ts
import { BaseFactory } from './BaseFactory';

export class DriversFactory extends BaseFactory {
  constructor() {
    super([
      { id: 1, name: 'Alice', vehicleId: 101, rating: 4.9 },
      { id: 2, name: 'Bob', vehicleId: 102, rating: 4.7 },
    ]);
  }
}

Other factories might include:

UserFactory – the logged-in user data
VehiclesFactory – registered vehicles
WalletFactory – balance and transactions
MyLocationsFactory – user’s saved addresses
MyLastTripsFactory – trip history

✅ Tip: Keep this data simple and clean. It doesn’t need to be “real” — just realistic.

⚙️ Step 2: Generators — Dynamic or Computed Data

Some data can’t be static. Think about:

A driver’s live location
Price estimates that change with distance
Routes generated from coordinates

That’s where generators come in.

// generators/carLocationsGenerator.ts
import { faker } from '@faker-js/faker';

export function generateCarLocations(count = 5) {
  return Array.from({ length: count }, () => ({
    driverId: faker.number.int({ min: 1, max: 5 }),
    lat: faker.location.latitude(),
    lng: faker.location.longitude(),
    updatedAt: faker.date.recent().toISOString(),
  }));
}

You can build similar ones for:

rideRequestsGenerator – mock incoming ride requests
priceEstimatesGenerator – calculate approximate fares
routesGenerator – fake polyline routes between points

✅ Why it matters:
Generators make your mocks feel alive, perfect for testing live maps, dynamic UI updates, or ride-status screens.

🧠 Step 3: Services — Mock Backend Logic

Services combine factories and generators into domain-specific logic.

// services/ridesService.ts
import { MyLastTripsFactory } from '../factories/myLastTripsFactory';
import { generateRideRequests } from '../generators/rideRequestsGenerator';
import { generatePriceEstimates } from '../generators/priceEstimatesGenerator';

export class RidesService {
  constructor() {
    this.trips = new MyLastTripsFactory().createMany();
  }

  listMyTrips(userId) {
    return this.trips.filter((trip) => trip.userId === userId);
  }

  getActiveRideRequests() {
    return generateRideRequests(3);
  }

  getPriceEstimate(pickup, dropoff) {
    return generatePriceEstimates(pickup, dropoff);
  }
}

✅ Why it matters:
This mirrors how a real backend behaves — filtering, calculating, and combining data logically — not just serving static JSON.

🌐 Step 4: Handlers — The MSW API Layer

Now we wire everything together using Mock Service Worker (MSW):

// handlers/ridesHandlers.ts
import { rest } from 'msw';
import { RidesService } from '../services/ridesService';

const ridesService = new RidesService();

export const ridesHandlers = [
  rest.get('/api/trips', (req, res, ctx) => {
    const userId = Number(req.url.searchParams.get('userId') || 1);
    const trips = ridesService.listMyTrips(userId);
    return res(ctx.status(200), ctx.json(trips));
  }),

  rest.get('/api/price-estimate', (req, res, ctx) => {
    const pickup = req.url.searchParams.get('pickup');
    const dropoff = req.url.searchParams.get('dropoff');
    const price = ridesService.getPriceEstimate(pickup, dropoff);
    return res(ctx.status(200), ctx.json(price));
  }),
];

And connect it to your dev environment:

// mocks/browser.ts
import { setupWorker } from 'msw';
import { ridesHandlers } from './handlers/ridesHandlers';
import { driversHandlers } from './handlers/driversHandlers';

export const worker = setupWorker(...ridesHandlers, ...driversHandlers);

Start it automatically in dev mode:

if (import.meta.env.DEV) {
  const { worker } = await import('./mocks/browser');
  worker.start({ onUnhandledRequest: 'bypass' });
}

🧰 Bonus: Works in Tests and Storybook Too

This architecture is not just for local development — it also powers:

Unit/Integration Tests (via setupServer from msw/node)
Storybook (via msw-storybook-addon)
End-to-End Prototyping without a real backend

Example Storybook config:

import { initialize, mswDecorator } from 'msw-storybook-addon';
initialize();
export const decorators = [mswDecorator];

🌱 Why This Architecture Works

Benefit	Description
🧩 Separation of Concerns	Each layer (factory, generator, service) does one job
⚙️ Backend-Like Simulation	Services handle filtering, routes, and price logic
🔁 Reusability	Works in dev, tests, and Storybook
💡 Flexibility	Add or override scenarios easily (e.g., surge pricing, no drivers)
🧱 Maintainability	Add new entities (e.g., Wallet, Vehicles) without rewriting mocks

✅ Conclusion

This architecture gives you production-like realism without depending on real APIs.
Your frontend becomes faster to develop, test, and demo — even before the backend exists.

By organizing your mocks into:

🧱 Factories (static seeds)
⚙️ Generators (dynamic data)
🧠 Services (logic layer)

…and connecting them through MSW handlers, you create a self-contained virtual backend for your app.

This example used Uber-like entities such as Drivers, Vehicles, MyLocations, Wallet, and RideRequests, but the same pattern applies to any complex domain — e-commerce, fintech, IoT, you name it.

Click the links below to follow me on all platforms:

🔗 Connect on LinkedIn

📝 Follow on Medium

💻 Follow on Dev.to

A Guide to Modern Browser Storage And Data Sharing Capabilities

Mohammad Rajaei Monfared — Thu, 16 Oct 2025 20:54:50 +0000

Choosing the right browser storage can make or break your app's performance and security—here's how to get it right.

In the early days of the web, browsers were simple document viewers. Today, they are powerful application platforms. Modern web apps often feel as responsive and capable as their native counterparts, and a key reason for this is their ability to store data directly on the client-side. But with great power comes great responsibility. The choice of where and how you store data in the browser has profound implications for your application's user experience, security, and overall performance.

It's a common pitfall to reach for a familiar tool like localStorage for every problem, but not all storage mechanisms are created equal. Some are synchronous, blocking the main thread and creating a janky user experience. Others are asynchronous and scalable but come with a steeper learning curve. Some are vulnerable to cross-site scripting (XSS) attacks, while others offer a more secure, sandboxed environment. Making the wrong choice can lead to anything from a sluggish UI to a critical security breach.

This article is a practical guide to navigating the complex landscape of modern browser storage. We'll move beyond the familiar localStorage and explore the full spectrum of tools at your disposal, including SessionStorage, Cookies, IndexedDB, Service Workers, and more. For each, we'll analyze the critical trade-offs between performance and security, and establish clear best practices. By the end, you'll be equipped to choose the right storage for the right job, building faster, more secure, and more reliable web applications.

The Classics: localstorage, sessionstorage, and cookies
- LocalStorage: The Persistent Key-Value Store
- SessionStorage: The Tab-Specific Store
- Cookies: The Server's Messenger
- Quick Comparison: The Classics
The Modern Powerhouse: raw-indexeddb-endraw
- Performance: Asynchronous and Scalable
- Security: Origin-Isolated with Potential for More
- The Catch: A Complex API
- Best Practices: Use a Wrapper!
Specialized Tools for Specific Jobs
- In-Memory Storage: The Need for Speed
- URL Query Parameters: The Shareable State
- BroadcastChannel API: The Cross-Tab Communicator
Powering Offline Experiences: Service Workers and the Cache API
- The Service Worker: Your App's Network Proxy
- The Cache API: The Service Worker's Storage
Tying It All Together: Comparison and Best Practices
- At a Glance: A Comparison of Browser Storage
- Unified Best Practices
- Key Takeaways
Conclusion: Build Smarter, Not Harder

The Classics: `LocalStorage`, `SessionStorage`, and `Cookies`

Before we dive into the heavy-duty storage solutions, let's revisit the three tools that have been the bedrock of browser data persistence for years. While still useful in specific scenarios, their limitations are what drove the need for more modern APIs.

`LocalStorage`: The Persistent Key-Value Store

LocalStorage is often the first tool developers reach for when they need to save data across browser sessions. It offers a simple, synchronous API for storing key-value pairs as strings.

Performance: The biggest drawback of LocalStorage is its synchronous API. Every read or write operation blocks the main thread, which can lead to a frozen UI if you're working with large amounts of data. With a typical limit of 5-10 MB, it's easy to run into performance bottlenecks.
Security: Data in LocalStorage is accessible to any JavaScript running on the same origin. This makes it a prime target for Cross-Site Scripting (XSS) attacks. If a malicious script finds its way onto your page, it can read everything in LocalStorage. For this reason, you should never store sensitive information like JWTs, API keys, or personal user data here.
Best For: Non-sensitive, infrequently updated data, such as user interface preferences (like a theme choice) or remembering that a welcome modal has been closed.

`SessionStorage`: The Tab-Specific Store

SessionStorage is nearly identical to LocalStorage in its API, with one critical difference: its scope. Data stored in SessionStorage is isolated to the current browser tab and is cleared the moment the tab is closed.

Performance & Security: It shares the same synchronous, blocking API and XSS vulnerabilities as LocalStorage. The tab-specific isolation provides a minor security benefit by preventing scripts in other tabs from accessing the data, but the core risks remain.
Best For: Storing transient data related to a single user session within one tab. A classic example is saving partially filled form data to prevent loss on an accidental reload.

`Cookies`: The Server's Messenger

Unlike LocalStorage and SessionStorage, cookies were designed primarily for server-client communication, not client-side storage. They are automatically sent with every HTTP request to the same domain.

Performance: Because they are attached to every request, large cookies can bloat request headers and slow down your application. Their small size limit (around 4KB) also makes them unsuitable for storing any significant amount of data.
Security: Cookies are the traditional way to manage user sessions, but they come with their own set of security risks, most notably Cross-Site Request Forgery (CSRF). To mitigate this, modern applications must use the HttpOnly, Secure, and SameSite=Strict attributes. The HttpOnly flag is particularly important, as it makes the cookie inaccessible to JavaScript, providing a strong defense against XSS-based token theft.
Best For: Storing server-issued session identifiers. Use them for authentication tokens, but keep them small and secure them with the right flags. Avoid using them as a general-purpose data store.

Quick Comparison: The Classics

Feature	`LocalStorage`	`SessionStorage`	`Cookies`
Persistence	Until cleared by user	Per tab/session	Expires or session-based
Scope	Origin-wide	Tab-specific	Domain/path specific
API	Synchronous	Synchronous	N/A (sent via HTTP headers)
Capacity	~5-10 MB	~5 MB	~4 KB
Security	High XSS risk	High XSS risk	CSRF/XSS risk (mitigable)
Main Use	UI preferences	Temporary form data	Server authentication

The Modern Powerhouse: `IndexedDB`

When your application's storage needs grow beyond simple key-value pairs, or when the performance cost of LocalStorage becomes too high, it's time to turn to IndexedDB. This is a true client-side database, offering capabilities far beyond the simple storage mechanisms we've discussed so far.

IndexedDB is a low-level API for client-side storage of significant amounts of structured data, including files/blobs. It's the browser's answer to the limitations of LocalStorage and is the foundation for most modern, data-intensive web applications.

Performance: Asynchronous and Scalable

The single most important feature of IndexedDB is its asynchronous API. Unlike LocalStorage, operations in IndexedDB do not block the main thread. This means you can read or write large amounts of data without freezing the user interface, resulting in a smooth and responsive application. It's designed for scale, with storage limits typically in the hundreds of megabytes or even gigabytes, depending on the browser and available disk space.

Furthermore, IndexedDB stores structured data—JavaScript objects—natively. This means you don't have the overhead of serializing and deserializing JSON for every operation, which can be a significant performance gain in applications with frequent data access.

Security: Origin-Isolated with Potential for More

Like other browser storage, IndexedDB is isolated by origin, which prevents other websites from accessing your data. However, it is still accessible to any JavaScript running on your page, which means it's vulnerable to XSS attacks if your application has a security flaw.

For sensitive data, the best practice is to add a layer of client-side encryption. You can use the built-in Web Crypto API to encrypt data before you store it in IndexedDB, ensuring that even if an attacker gains access to the database, the data remains unreadable.

The Catch: A Complex API

With great power comes... a more complex API. The native IndexedDB API is event-based and requires you to manage transactions, versioning, and schemas manually. It can be cumbersome to work with directly, which has led to the development of several excellent wrapper libraries.

Best Practices: Use a Wrapper!

For almost all use cases, it's highly recommended to use a library like Dexie.js or idb. These wrappers provide a clean, modern, Promise-based API that handles the underlying complexity of IndexedDB transactions and schema management. They make working with IndexedDB feel almost as simple as working with LocalStorage, while retaining all of its performance benefits.

Best For:

Applications that need to store large amounts of structured data.
Offline-first Progressive Web Apps (PWAs).
Caching complex API responses to reduce network requests.
Any scenario where the synchronous nature of LocalStorage would cause performance issues.

Specialized Tools for Specific Jobs

While IndexedDB is the champion of large-scale persistent storage, not all data needs to be stored in a database. Sometimes you need the fastest possible access for temporary data, a way to share state in a URL, or a method to communicate between open tabs. For these jobs, we have a set of specialized tools.

In-Memory Storage: The Need for Speed

Not all data needs to survive a page refresh. The fastest storage available is the computer's RAM, which you can access directly by storing data in JavaScript variables or more structured state management solutions like Redux or Zustand stores.

Performance: Unbeatable. Access is nearly instantaneous, with no serialization overhead. This is where your application's active state should live.
Security & Persistence: Being volatile is its key feature. Since the data is wiped on every page load, the security exposure is minimal. It's perfect for data that is fetched and used in a single session.
Best For: Caching frequently accessed data that can be easily re-fetched, managing the real-time state of your UI, and holding temporary data that doesn't need to be persisted.

URL Query Parameters: The Shareable State

Sometimes, the state of your application needs to be shareable. Think of applying a set of filters on an e-commerce site and wanting to send the results to a friend. This is the perfect use case for URL query parameters.

Performance: There's no real I/O cost, but be mindful of URL length limits (generally around 2000 characters), as excessively long URLs can cause issues.
Security: This is the most public form of state. The data is visible in the user's browser history, server logs, and to anyone they share the link with. Never, ever put sensitive information in a URL.
Best For: Small, non-sensitive pieces of data that make a page's state shareable and bookmarkable, such as search queries, filter settings, or pagination info (?page=2).

`BroadcastChannel` API: The Cross-Tab Communicator

What happens when a user logs out in one tab? Ideally, they should be logged out in all other open tabs of your application as well. This is the problem the BroadcastChannel API was designed to solve.

Performance: It's a lightweight, event-driven API that allows different browser tabs, windows, or iframes of the same origin to send and receive messages.
Security: Channels are scoped to a single origin, but any script on that origin can listen in. Therefore, you should never broadcast sensitive data. Instead, send simple signals or notifications, like "user-logged-out" or "theme-changed-to-dark".
Best For: Syncing state across multiple open tabs. It's the modern, efficient way to ensure a consistent user experience, especially for actions like authentication, theme changes, or real-time notifications.

For more detailed information, please visit Mastering Cross-Window Communication in JavaScript: postMessage vs BroadcastChannel Explained

Powering Offline Experiences: Service Workers and the Cache API

What truly separates a modern web app from a traditional website is the ability to function without a network connection. This is the domain of the Service Worker, a powerful technology that acts as a programmable proxy between your application, the browser, and the network.

The Service Worker: Your App's Network Proxy

A Service Worker is a type of Web Worker that runs on a separate thread from your main application. It can intercept and handle network requests, manage a cache of responses, and enable push notifications. Because it runs independently of your UI, it can continue to work even when the user has closed the application's tab, enabling features like background sync.

Service Workers are the cornerstone of Progressive Web Apps (PWAs), allowing them to provide a reliable, app-like experience even on a flaky network connection or when completely offline.

The `Cache API`: The Service Worker's Storage

While a Service Worker can use IndexedDB, its primary storage tool is the Cache API. This is a specialized storage mechanism designed for holding HTTP request and response pairs. It allows you to programmatically save network responses and serve them directly from the cache, bypassing the network entirely.

Performance: The performance implications are massive. By serving assets and API responses from the cache, you can make your application load almost instantly on repeat visits. Caching strategies like stale-while-revalidate (serving from the cache while fetching an update in the background) provide the perfect balance of speed and freshness.
Security: Service Workers are highly secure. They can only be registered on pages served over HTTPS, which prevents man-in-the-middle attacks. They run in a sandboxed environment and have no direct access to the DOM, which limits their exposure to XSS attacks. However, you must still be careful not to cache sensitive, user-specific data, as the cache is persistent and could be accessed if the application's security is compromised.
Best For:
- Creating offline-first applications.
- Caching application shell assets (HTML, CSS, JS) for instant loading.
- Caching API responses to reduce network dependency and improve perceived performance.

Tying It All Together: Comparison and Best Practices

We've explored a wide range of browser storage options, each with its own strengths and weaknesses. Choosing the right one depends on a careful balance of performance, security, and persistence requirements. To make this easier, let's summarize our findings.

At a Glance: A Comparison of Browser Storage

Storage Type	Security Level	Performance Impact	Persistence	Size Limit	Async	Typical Use Case
In-Memory	✅ Secure (Volatile)	⚡ Fastest	❌ None	RAM Limit	✅ N/A	Temporary UI State
LocalStorage	❌ High XSS Risk	🚫 Blocking I/O	✅ Permanent	~5MB	❌ No	Non-sensitive Preferences
SessionStorage	⚠️ High XSS Risk	🚫 Blocking I/O	⚪ Per Tab	~5MB	❌ No	Single-tab Session Data
Cookies	⚠️ CSRF/XSS Risk	🚫 Slows HTTP	✅ Expires	~4KB	✅ N/A	Server Session Tokens
IndexedDB	⚪ XSS Risk (Encrypt!)	✅ Async, Scalable	✅ Permanent	100MB+	✅ Yes	Large/Structured Data
Cache API	✅ Sandboxed (HTTPS)	✅ Async, Fast	✅ Evictable	Large	✅ Yes	Offline Assets & Responses
URL Params	❌ Publicly Visible	⚡ Light	⚪ Shareable	~2KB	✅ N/A	Shareable Filter State
BroadcastChannel	⚠️ Cross-tab Exposure	⚡ Fast (Events)	❌ None	N/A	✅ Yes	Cross-tab Syncing

Unified Best Practices

Regardless of the tool you choose, a few universal principles will help you build more secure and performant applications.

🧱 Security Principles

Never Store Sensitive Data in Client-Accessible Storage: This includes JWTs, API keys, passwords, or personal information. LocalStorage, SessionStorage, and IndexedDB are all readable by any JavaScript on the page.
Use HttpOnly Cookies for Auth Tokens: This is the single most effective defense against token theft via XSS, as it makes the cookie inaccessible to JavaScript.
Encrypt Sensitive Local Data: If you must store sensitive information client-side (e.g., in IndexedDB for an offline app), use the Web Crypto API to encrypt it first.
Assume All Client-Side Data Can Be Manipulated: Always validate data on the server before processing it.

⚡ Performance Principles

Async Over Sync: Always prefer asynchronous APIs like IndexedDB and the Cache API over synchronous ones like LocalStorage to avoid blocking the main thread.
Lazy Load Your Data: Don't eagerly load large amounts of data into storage. Fetch and cache it as needed.
Use In-Memory for Hot Data: For data that is accessed frequently, keep it in an in-memory state variable for the fastest possible access. Persist it to storage only when necessary.
Be Mindful of Quotas: Monitor storage usage with navigator.storage.estimate() and be prepared to handle quota errors gracefully.

Key Takeaways

LocalStorage is not your default: Its synchronous nature and security risks make it a poor choice for anything but the simplest, non-sensitive data.
IndexedDB is the modern standard: For any significant amount of client-side data, IndexedDB (used with a wrapper like Dexie.js) is the best choice for performance and scalability.
HttpOnly cookies are for authentication: They are the most secure place to store session tokens.
Service Workers are for offline: The Cache API combined with a Service Worker is the key to building reliable, offline-first applications.
Security is paramount: Never trust the client. Encrypt sensitive data and use HttpOnly cookies for authentication.

Conclusion: Build Smarter, Not Harder

The landscape of browser storage is far richer and more nuanced than just localStorage. Choosing the right storage solution is not about finding a single tool that does everything; it's about understanding the trade-offs and composing a strategy that fits your application's unique needs. The modern web is built on a foundation of smart, hybrid approaches.

An application might use HttpOnly cookies for authentication, IndexedDB to store complex data for offline use, in-memory variables for real-time UI state, and the BroadcastChannel API to keep multiple tabs in sync. This is not over-engineering; it's a sign of a mature, robust architecture.

As browsers continue to evolve, the trend is clear: we are moving towards more secure, asynchronous, and origin-isolated storage models. By embracing these modern APIs and understanding their underlying principles, you can build the next generation of web applications—apps that are not only fast and feature-rich but also secure and reliable, no matter the user's device or network condition. The power is in your hands; it's time to build smarter.

Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

Your support and engagement mean the world to me.

Let's create a community of knowledge enthusiasts and professionals striving for excellence and continuous learning.

Click the links below to follow me on all platforms:
🔗 Connect on LinkedIn

📝 Follow on Medium

💻 Follow on Dev.to

#WebSecurity #WebPerformance #WebDevelopment #BrowserAPIs #Frontend #JavaScript #IndexedDB #Cookies #LocalStorage #PWAs #WebDevTips

The Ultimate Guide to Mastering `useEffect`

Mohammad Rajaei Monfared — Wed, 15 Oct 2025 14:24:38 +0000

From lifecycle chaos to declarative harmony, this guide demystifies React's most powerful Hook.

Introduction

The useEffect Hook is arguably one of the most important yet misunderstood parts of modern React. For developers coming from class-based components, it feels like a strange new paradigm. For newcomers, it can seem like a magic box where you put any code that "doesn't fit" in the render. But useEffect is far more than that—it's a precise tool for synchronizing your component with external systems.

This guide breaks down everything you need to know, from the fundamentals of component lifecycles to advanced patterns and common pitfalls. By the end, you'll not only understand how useEffect works but also why it was designed and when to use it effectively. Let's dive in and transform useEffect from a source of confusion into your most reliable ally.

1. Understanding the React Component Lifecycle
- Before Hooks: The Classic Lifecycle Methods
- After Hooks: useEffect Unifies the Lifecycle
- A Visual Timeline of the Functional Component Lifecycle
- Why Was useEffect Introduced?
2. The Purpose of useEffect — What It Really Does
- Common Examples of Side Effects
- It Runs After the Paint
- Misconception: It’s Not for All Logic
3. The Dependencies Array Demystified
- The Three Modes of useEffect
- How React Compares Dependencies
- How to Fix Shallow Comparison Issues
- Tips to Avoid Common Pitfalls
4. Cleanup Functions and the “Return” Mystery
- Why useEffect Can Return a Function
- When Does the Cleanup Function Run?
- Real-World Cases for Cleanup
- Why Cleanup Prevents Memory Leaks
5. Multiple useEffects: Execution and Cleanup Order
- Execution Order: Top to Bottom
- Cleanup Order: Bottom to Top (Reverse Order)
- Why Splitting Concerns is Cleaner
6. Debugging useEffect Like a Pro
- Common Pitfalls and How to Spot Them
- Use the ESLint Rule (and When to Ignore It)
- Tracing with Logs and Custom Hooks
- React DevTools Profiler
- Tips: useRef for Tracking
7. When Not to Use useEffect
- Anti-Pattern: Unnecessary State Mirroring
- Anti-Pattern: Computations and Derived State
- Prefer Event Handlers for User Actions
8. Practical Examples & Patterns
- Pattern: Data Fetching with AbortController
- Pattern: Syncing the Browser Tab Title
- Pattern: Custom Hooks Abstraction (e.g., useLocalStorage)
9. Wrap-Up
- useEffect Cheat Sheet
- Visual Summary
- The Future of Effects
Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

1. Understanding the React Component Lifecycle

Before we can master useEffect, we need to travel back in time to the era of class components. The component lifecycle was a set of distinct methods that gave us hooks into a component's life, from birth to death.

Before Hooks: The Classic Lifecycle Methods

In class components, side effects like fetching data, setting up subscriptions, or manually changing the DOM were handled by specific lifecycle methods:

componentDidMount(): Fired only once, immediately after the component is mounted (inserted into the tree). This was the perfect place for initial data fetches or setting up subscriptions.
componentDidUpdate(prevProps, prevState): Called on every re-render, but not for the initial render. Logic here often required checking if props or state had changed to avoid unnecessary re-fetches.
componentWillUnmount(): Called right before the component is destroyed. This was the place to clean up subscriptions, timers, or any other lingering side effects to prevent memory leaks.

This separation often led to related logic being split across different methods, making components harder to follow.

After Hooks: `useEffect` Unifies the Lifecycle

The useEffect Hook simplifies this by unifying these concepts into a single API. It runs after React renders the component, allowing you to perform side effects without blocking the browser paint.

Here’s how it maps to the old lifecycle methods:

componentDidMount: An effect with an empty dependency array ([]) runs only once, after the initial render.
componentDidUpdate: An effect with dependencies in its array ([prop, state]) runs after the initial render and any time those dependencies change.
componentWillUnmount: The cleanup function returned from an effect serves this purpose.

This new model encourages you to group related logic together, not by lifecycle event, but by concern.

A Visual Timeline of the Functional Component Lifecycle

Why Was `useEffect` Introduced?

The shift to Hooks wasn't just for a cleaner syntax. It solved fundamental problems with class components:

Separation of Concerns: In classes, a single componentDidMount might contain logic for data fetching, setting up event listeners, and logging. useEffect allows you to split these into separate, independent effects. Each effect handles one concern, making the code more modular and readable.
Declarative Side Effects: Instead of issuing imperative commands at different points in time (mount, update), you declare the side effects that should be synchronized with your component's state. You tell React, “When this data changes, run this effect.” React handles the when and how, making your code less error-prone and easier to reason about.

2. The Purpose of `useEffect` — What It Really Does

The official React documentation defines useEffect as a way to perform side effects in function components. But what exactly is a “side effect”?

Definition: A side effect is any interaction with the “outside world” that occurs outside of a component’s render. If your component is a pure function, its only job is to return JSX based on its props and state. Anything else is a side effect.

Common Examples of Side Effects

useEffect is your go-to tool for managing these interactions. Here are the most common use cases:

Fetching data from an API: Retrieving remote data and updating component state.
Setting up subscriptions: Connecting to a WebSocket or listening to a real-time service.
Manual DOM manipulation: Directly changing the DOM, like focusing an input field or integrating with a non-React library.
Logging: Sending analytics or error reports to a logging service.
Using browser APIs: Interacting with localStorage, Cookies, document.title, or timers like setTimeout and setInterval.

It Runs After the Paint

A critical detail that often trips up developers is when useEffect runs. Unlike componentDidMount and componentDidUpdate, which could block the browser from painting, useEffect is deferred. It runs after React has rendered your component and the browser has painted the result to the screen.

This is a huge performance benefit. It ensures that side effects, which can be slow, don't make your UI feel sluggish. The user sees the updated UI first, and then the effect runs in the background.

Misconception: It’s Not for All Logic

Because useEffect is so versatile, it's tempting to put any and all logic inside it. This is a common anti-pattern. useEffect is for synchronizing with external systems. If you can calculate a value or derive state directly during the render, you don't need an effect. Using it for simple computations adds unnecessary complexity and can lead to bugs.

Rule of Thumb: If your logic doesn't interact with the outside world, it probably doesn't belong in useEffect.

3. The Dependencies Array Demystified

The second argument to useEffect is the dependencies array. This array is the key to controlling when your effect runs. Get it right, and your components will be efficient and predictable. Get it wrong, and you'll face bugs like infinite loops and stale data.

The Three Modes of `useEffect`

You can think of the dependency array as having three primary modes:

No Dependency Array: useEffect(() => { ... })
- When it runs: After the initial render and every single re-render.
- Why it's often bad: This can be inefficient and dangerous. If the effect triggers a state update, it will cause a re-render, which will trigger the effect again, leading to an infinite loop. Use this mode with extreme caution.
Empty Array: useEffect(() => { ... }, [])
- When it runs: Only once, after the initial render.
- This is the equivalent of componentDidMount. It’s perfect for one-time setup logic, like fetching initial data or setting up a subscription that doesn't depend on any props or state.
Array with Dependencies: useEffect(() => { ... }, [prop1, stateValue])
- When it runs: After the initial render and any time a value in the dependency array changes.
- This is the most common and powerful mode. It lets you synchronize your component with a specific piece of data.

How React Compares Dependencies

React performs a shallow comparison of the items in the dependency array. It checks if oldValue === newValue for each dependency.

For primitive values (strings, numbers, booleans), this works as you'd expect. 5 === 5 is true, but 5 === 6 is false.
For reference values (objects, arrays, functions), it checks if the reference itself has changed, not the contents. A new object or array is created on every render, so {} !== {}. This is a classic source of infinite loops.

// ⚠️ Anti-pattern: This will cause an infinite loop!
function MyComponent() {
  const [options, setOptions] = useState({});
  useEffect(() => {
    // Some logic
  }, [options]); // `options` is a new object on every render
}

How to Fix Shallow Comparison Issues

So, how do you depend on an object or array without causing an infinite loop? Here are the recommended solutions:

1. Memoize the Dependency with useMemo

If you need to depend on an object or array that is calculated during render, wrap it in useMemo. This ensures that the object's reference only changes when its own underlying dependencies change.

// ✅ Correct: Memoize the object
function MyComponent({ filterSettings }) {
  // `options` will only be a new object when `filterSettings` changes
  const options = useMemo(() => ({
    filter: filterSettings,
    includeDrafts: false,
  }), [filterSettings]);

  useEffect(() => {
    // This effect now only runs when `options` actually changes
  }, [options]);
}

2. Depend on Primitive Values

The simplest solution is often the best. If your effect only needs a few properties from an object, depend on those properties directly. Primitives are compared by value, so this is always safe.

// ✅ Correct: Depend on the primitive value
function MyComponent({ user }) {
  useEffect(() => {
    console.log(`User ID is: ${user.id}`);
  }, [user.id]); // Depend on `user.id`, not the whole `user` object
}

3. Other Advanced Solutions

JSON.stringify: As a quick fix, you can serialize the object into a string: [JSON.stringify(options)]. This works but can be inefficient for large objects and may not handle all edge cases (like key order).
Deep Comparison Hooks: You can find or create a custom hook (e.g., useDeepCompareEffect) that uses a utility like lodash.isEqual to perform a deep comparison instead of a shallow one. This is a powerful but often unnecessary abstraction.

Tips to Avoid Common Pitfalls

Stale Closures: If you use a state variable or prop inside an effect but forget to include it in the dependency array, the effect will “close over” the initial value of that variable. It will never see the updated value, leading to bugs. The eslint-plugin-react-hooks package is essential for catching this.
Infinite Loops: Always be careful with objects, arrays, and functions in the dependency array. If you must use them, ensure they are stable between renders. Use useCallback for functions and useMemo for objects/arrays to memoize them. > Pro Tip: If your effect doesn't use any props or state, give it an empty dependency array []. If it does, include every one of them in the array. Let the linter guide you.

4. Cleanup Functions and the “Return” Mystery

Many side effects need to be undone. If you set up a subscription, you need to unsubscribe. If you start a timer, you need to clear it. This is where the useEffect cleanup function comes in. It’s the componentWillUnmount of the Hooks world, but much more powerful.

Why `useEffect` Can Return a Function

If you return a function from your useEffect callback, React will store it and run it at the appropriate time. This design is brilliant because it keeps the logic for setting up and tearing down an effect right next to each other.

useEffect(() => {
  // The effect logic: runs after every render where dependencies change
  const timerId = setTimeout(() => {
    console.log("Timer fired!");
  }, 1000);

  // The cleanup function: returned by the effect
  return () => {
    console.log("Clearing timer...");
    clearTimeout(timerId);
  };
}, []); // Empty array means this effect runs once

When Does the Cleanup Function Run?

This is a key point of confusion. The cleanup function runs in two scenarios:

Before the effect runs again: If your dependencies change and the effect is about to re-run, React first runs the cleanup function from the previous render. This ensures you don't have multiple subscriptions or timers running at once.
On unmount: When the component is removed from the DOM, React runs the cleanup function from the last render.

This behavior ensures that your effects are always cleaned up, preventing what are sometimes called “zombie effects”—lingering side effects from a component that is no longer on the screen.

Real-World Cases for Cleanup

Clearing timeouts or intervals: As shown above, clearTimeout and clearInterval are essential to prevent timers from firing after a component has unmounted.
Unsubscribing from events or sockets: If you use addEventListener or connect to a WebSocket, you must remove the listener or close the connection to avoid memory leaks and unnecessary processing.
Canceling pending requests: For data fetching, you can use an AbortController to cancel a network request if the component unmounts or the dependencies change before the request completes. This prevents you from trying to update the state of an unmounted component.

Why Cleanup Prevents Memory Leaks

Without cleanup, your application would slowly degrade. Event listeners would pile up, subscriptions would remain active, and timers would fire unexpectedly, all consuming memory and CPU cycles for components that no longer exist. The useEffect cleanup function provides a simple, reliable pattern to keep your application healthy and performant.

5. Multiple `useEffect`s: Execution and Cleanup Order

A single component can have multiple useEffect hooks. This is a powerful feature for separating unrelated logic. But when you have more than one, it's important to understand the order in which they run.

Execution Order: Top to Bottom

React executes useEffect hooks in the same order they are declared in your component.

function MyComponent() {
  useEffect(() => {
    console.log("First effect runs");
  }, []);

  useEffect(() => {
    console.log("Second effect runs");
  }, []);

  return <div>...</div>;
}

// Console output on mount:
// "First effect runs"
// "Second effect runs"

This predictable, top-to-bottom order allows you to orchestrate side effects that might depend on each other, although it's generally better to keep them independent.

Cleanup Order: Bottom to Top (Reverse Order)

Here's the interesting part: the cleanup functions run in the reverse order of the effects. When the component unmounts (or before a re-run), React will clean up the second effect, then the first.

function MyComponent() {
  useEffect(() => {
    console.log("First effect setup");
    return () => console.log("First effect cleanup");
  }, []);

  useEffect(() => {
    console.log("Second effect setup");
    return () => console.log("Second effect cleanup");
  }, []);

  return <div>...</div>;
}

// On mount:
// "First effect setup"
// "Second effect setup"

// On unmount:
// "Second effect cleanup"
// "First effect cleanup"

Think of it like a stack: the last effect that was set up is the first one to be torn down. This LIFO (Last-In, First-Out) order ensures that dependencies are cleaned up correctly.

Why Splitting Concerns is Cleaner

The ability to use multiple useEffect hooks is the primary reason Hooks are so good at promoting separation of concerns. Instead of a monolithic componentDidMount that does everything, you can have a dedicated effect for each piece of side-effect logic.

Example: Separating Data Fetching from UI Updates

Imagine you need to fetch data and also update the document title based on that data.

function Post({ postId }) {
  const [post, setPost] = useState(null);

  // Effect 1: Handles data fetching
  useEffect(() => {
    const controller = new AbortController();
    fetch(`/api/posts/${postId}`, { signal: controller.signal })
      .then(res => res.json())
      .then(data => setPost(data));

    return () => controller.abort(); // Cleanup for this effect
  }, [postId]);

  // Effect 2: Handles updating the document title
  useEffect(() => {
    if (post) {
      document.title = post.title;
    }
  }, [post]); // Runs only when the `post` state changes

  if (!post) {
    return <div>Loading...</div>;
  }

  return <h1>{post.title}</h1>;
}

This is incredibly clean:

The first effect is solely responsible for fetching data. Its dependency is postId.
The second effect is solely responsible for a UI side effect (updating the title). Its dependency is post. The two pieces of logic are completely decoupled.

6. Debugging `useEffect` Like a Pro

Even with a solid understanding, useEffect can still be a source of bugs. Knowing how to debug it effectively is a superpower. Here are common issues and how to solve them.

Common Pitfalls and How to Spot Them

Infinite Loops:
- Symptom: Your app becomes unresponsive, the fan kicks on, and the browser might crash.
- Cause: An effect is updating state, which causes a re-render, which triggers the effect again. This usually happens when a dependency is an object, array, or function that is re-created on every render.
- Fix: Memoize reference-type dependencies with useMemo or useCallback. For state updates, use the functional update form (setState(prev => ...)), which can sometimes remove the need to depend on the state itself.
Missing Dependencies:
- Symptom: The effect doesn't re-run when you expect it to. Data becomes stale.
- Cause: You used a prop or state variable inside the effect but didn't add it to the dependency array. The effect has a "stale closure" over the old value.
- Fix: Turn on the react-hooks/exhaustive-deps ESLint rule. It's your best friend for catching this. Trust the linter; it's almost always right.
Stale State in Async Operations:
- Symptom: An async function (like a setTimeout callback) reads a state variable, but it sees an old value.
- Cause: The closure was created when the effect ran, capturing the state at that moment.
- Fix: Use useRef to store a mutable value that can be read at any time without re-triggering the effect. Or, refactor to include the state in the dependency array and properly clean up the effect.

Use the ESLint Rule (and When to Ignore It)

The react-hooks/exhaustive-deps ESLint rule is a lifesaver. It statically analyzes your useEffect calls and warns you about missing dependencies.

99% of the time, you should follow its advice.

When is it okay to ignore it? Very rarely. One legitimate case is when you intentionally want to capture the initial value of a prop and never react to its changes. Even then, it's often cleaner to store that value in a useRef.

// To ignore, add this comment. But think twice!
// eslint-disable-next-line react-hooks/exhaustive-deps

Tracing with Logs and Custom Hooks

Simple Logging: The easiest way to see when an effect runs and cleans up.

useEffect(() => {
  console.log('Effect ran with value:', myValue);
  return () => {
    console.log('Cleanup for value:', myValue);
  };
}, [myValue]);

Custom useTraceUpdate Hook: Create a custom hook to see exactly which prop caused an effect to re-run.

import { useEffect, useRef } from 'react';

function useTraceUpdate(props) {
  const prev = useRef(props);
  useEffect(() => {
    const changedProps = Object.entries(props).reduce((ps, [k, v]) => {
      if (prev.current[k] !== v) {
        ps[k] = [prev.current[k], v];
      }
      return ps;
    }, {});
    if (Object.keys(changedProps).length > 0) {
      console.log('Changed props:', changedProps);
    }
    prev.current = props;
  });
}

React DevTools Profiler

The React DevTools are indispensable. Use the Profiler to record a user interaction and see exactly why your components re-rendered. The "Why did this render?" checkbox in the component inspector is a great starting point. For effects, the Profiler's flamegraph can help you spot long-running effects that might be slowing down your app.

Image Ref: https://legacy.reactjs.org

Tips: `useRef` for Tracking

Sometimes you need to access the previous value of a prop or state inside an effect. useRef is perfect for this. Since updating a ref doesn't trigger a re-render, you can use it to store values across renders without affecting the component's lifecycle.

function MyComponent({ count }) {
  const prevCountRef = useRef();

  useEffect(() => {
    prevCountRef.current = count; // Store the current count for the next render
  }); // No dependency array, so this runs on every render

  const prevCount = prevCountRef.current;
  return <h1>Now: {count}, before: {prevCount}</h1>;
}

7. When Not to Use `useEffect`

The most powerful lesson is often learning what a tool is not for. Overusing useEffect can lead to complex, inefficient, and buggy components. The golden rule is: if it can be done during render, don’t put it in useEffect.

Anti-Pattern: Unnecessary State Mirroring

A common mistake is to use useEffect to update a state variable in response to a prop change.

// ❌ Anti-pattern
function UserProfile({ user }) {
  const [name, setName] = useState(user.name);

  useEffect(() => {
    setName(user.name); // Mirrors the prop in state
  }, [user.name]);

  return <h1>{name}</h1>;
}

This is redundant. You already have user.name from props. The effect adds an unnecessary re-render and makes the data flow confusing.

// ✅ Correct: Derive state directly from props
function UserProfile({ user }) {
  // No need for an effect or separate state
  return <h1>{user.name}</h1>;
}

Anti-Pattern: Computations and Derived State

Don't use effects for calculations that can be done directly during rendering.

// ❌ Anti-pattern
function ShoppingCart({ items }) {
  const [total, setTotal] = useState(0);

  useEffect(() => {
    const newTotal = items.reduce((sum, item) => sum + item.price, 0);
    setTotal(newTotal);
  }, [items]);

  return <div>Total: ${total}</div>;
}

This is overly complex. The total can be calculated on every render. If the calculation is expensive, use useMemo to memoize it, but still don't use useEffect.

// ✅ Correct: Calculate during render
function ShoppingCart({ items }) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  return <div>Total: ${total}</div>;
}

// ✅ Correct (for expensive calculations)
function ShoppingCart({ items }) {
  const total = useMemo(() => {
    return items.reduce((sum, item) => sum + item.price, 0);
  }, [items]);
  return <div>Total: ${total}</div>;
}

Prefer Event Handlers for User Actions

Side effects should be caused by a render, not a user event. If a user action (like clicking a button) needs to trigger a state change, do it directly in the event handler.

// ❌ Anti-pattern
function MyForm() {
  const [value, setValue] = useState('');
  const [submittedValue, setSubmittedValue] = useState('');

  useEffect(() => {
    if (submittedValue) {
      // send to API
    }
  }, [submittedValue]);

  return <button onClick={() => setSubmittedValue(value)}>Submit</button>;
}

This is indirect. The state change is just a trigger for the effect. The logic belongs in the event handler itself.

// ✅ Correct
function MyForm() {
  const [value, setValue] = useState('');

  function handleSubmit() {
    // send to API directly
  }

  return <button onClick={handleSubmit}>Submit</button>;
}

By avoiding these anti-patterns, you keep your components simpler, more predictable, and more performant.

8. Practical Examples & Patterns

Theory is great, but code is better. Let's look at some common, production-ready patterns for useEffect.

Pattern: Data Fetching with `AbortController`

This is the canonical example of a robust data fetching effect. It handles loading and error states, and it cancels the request if the component unmounts or the userId changes.

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const controller = new AbortController();
    const { signal } = controller;

    setLoading(true);
    setError(null);

    fetch(`https://api.example.com/users/${userId}`, { signal })
      .then(res => {
        if (!res.ok) throw new Error('Failed to fetch');
        return res.json();
      })
      .then(data => setUser(data))
      .catch(err => {
        if (err.name !== 'AbortError') {
          setError(err.message);
        }
      })
      .finally(() => setLoading(false));

    // Cleanup function to abort the request
    return () => controller.abort();
  }, [userId]);

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

  return <h1>{user?.name}</h1>;
}

Pattern: Syncing the Browser Tab Title

A simple but effective use case. This effect synchronizes an external part of the browser (the tab title) with the component's state.

function useDocumentTitle(title) {
  useEffect(() => {
    // Store the original title so we can restore it on unmount
    const originalTitle = document.title;
    document.title = title;

    return () => {
      document.title = originalTitle;
    };
  }, [title]);
}

// Usage in a component
function MyPage() {
  useDocumentTitle('My Awesome Page');
  return <div>...</div>;
}

Pattern: Custom Hooks Abstraction (e.g., `useLocalStorage`)

If you find yourself writing the same useEffect logic repeatedly, it's time to extract it into a custom hook. This is one of the most powerful features of Hooks.

import { useState, useEffect } from 'react';

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    try {
      const item = window.localStorage.getItem(key);
      return item ? JSON.parse(item) : initialValue;
    } catch (error) {
      console.log(error);
      return initialValue;
    }
  });

  useEffect(() => {
    try {
      window.localStorage.setItem(key, JSON.stringify(storedValue));
    } catch (error) {
      console.log(error);
    }
  }, [key, storedValue]);

  return [storedValue, setStoredValue];
}

// Usage in a component
function Settings() {
  const [theme, setTheme] = useLocalStorage('theme', 'light');

  return (
    <select value={theme} onChange={e => setTheme(e.target.value)}>
      <option value="light">Light</option>
      <option value="dark">Dark</option>    </select>
  );
}

9. Wrap-Up

Mastering useEffect is a journey from understanding its rules to developing an intuition for its purpose. It’s not just a replacement for lifecycle methods; it’s a fundamentally different way of thinking about synchronizing your component with the world outside React.

`useEffect` Cheat Sheet

Use it for: Side effects (data fetching, subscriptions, manual DOM changes).
How to control it: The dependency array is key.
- []: Runs once on mount.
- [dep]: Runs when dep changes.
- No array: Runs on every render (use with caution!).
How to clean up: Return a function from the effect. It runs before the next effect or on unmount.
When to avoid it: For derived state or simple computations. If you can calculate it during render, do it.

Visual Summary

The Future of Effects

The React team is always exploring ways to make effects even better. While nothing is set in stone, future versions of React might introduce new APIs or refine the behavior of useEffect to make it even more intuitive and less error-prone. Staying engaged with the React community will keep you prepared for what's next.

By following these principles, you can write cleaner, more efficient, and more predictable React components. Happy coding!

Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

Your support and engagement mean the world to me.

Let's create a community of knowledge enthusiasts and professionals striving for excellence and continuous learning.

Click the links below to follow me on all platforms:
🔗 Connect on LinkedIn

📝 Follow on Medium

💻 Follow on Dev.to

I’m committed to providing the most up-to-date and relevant information.

As things evolve or new insights emerge, I may revisit and update this article to ensure it remains a valuable resource.

Forem: Mohammad Rajaei Monfared

🚖 Building a Scalable Frontend Mock Architecture with MSW, Factories, and Services (Uber-Like Example)

🧩 Why Traditional Mocks Don’t Scale

🏗 The Layered Mock Architecture

🧱 Step 1: Factories — The Mock Database

⚙️ Step 2: Generators — Dynamic or Computed Data

🧠 Step 3: Services — Mock Backend Logic

🌐 Step 4: Handlers — The MSW API Layer

🧰 Bonus: Works in Tests and Storybook Too

🌱 Why This Architecture Works

✅ Conclusion

A Guide to Modern Browser Storage And Data Sharing Capabilities

Table of Contents

The Classics: LocalStorage, SessionStorage, and Cookies

LocalStorage: The Persistent Key-Value Store

SessionStorage: The Tab-Specific Store

Cookies: The Server's Messenger

Quick Comparison: The Classics

The Modern Powerhouse: IndexedDB

Performance: Asynchronous and Scalable

Security: Origin-Isolated with Potential for More

The Catch: A Complex API

Best Practices: Use a Wrapper!

Specialized Tools for Specific Jobs

In-Memory Storage: The Need for Speed

URL Query Parameters: The Shareable State

BroadcastChannel API: The Cross-Tab Communicator

Powering Offline Experiences: Service Workers and the Cache API

The Service Worker: Your App's Network Proxy

The Cache API: The Service Worker's Storage

Tying It All Together: Comparison and Best Practices

At a Glance: A Comparison of Browser Storage

Unified Best Practices

🧱 Security Principles

⚡ Performance Principles

Key Takeaways

Conclusion: Build Smarter, Not Harder

Follow Me on Medium, Dev.to, and LinkedIn! 🚀😊

The Ultimate Guide to Mastering `useEffect`

Introduction

Table of Contents

1. Understanding the React Component Lifecycle

Before Hooks: The Classic Lifecycle Methods

After Hooks: useEffect Unifies the Lifecycle

A Visual Timeline of the Functional Component Lifecycle

Why Was useEffect Introduced?

2. The Purpose of useEffect — What It Really Does

Common Examples of Side Effects

It Runs After the Paint

Misconception: It’s Not for All Logic

3. The Dependencies Array Demystified

The Three Modes of useEffect

How React Compares Dependencies

How to Fix Shallow Comparison Issues

Tips to Avoid Common Pitfalls

4. Cleanup Functions and the “Return” Mystery

Why useEffect Can Return a Function

When Does the Cleanup Function Run?

Real-World Cases for Cleanup

Why Cleanup Prevents Memory Leaks

5. Multiple useEffects: Execution and Cleanup Order

Execution Order: Top to Bottom

Cleanup Order: Bottom to Top (Reverse Order)

Why Splitting Concerns is Cleaner

6. Debugging useEffect Like a Pro

Common Pitfalls and How to Spot Them

Use the ESLint Rule (and When to Ignore It)

Tracing with Logs and Custom Hooks

React DevTools Profiler

Tips: useRef for Tracking

7. When Not to Use useEffect

Anti-Pattern: Unnecessary State Mirroring

Anti-Pattern: Computations and Derived State

Prefer Event Handlers for User Actions

8. Practical Examples & Patterns

Pattern: Data Fetching with AbortController

Pattern: Syncing the Browser Tab Title

Pattern: Custom Hooks Abstraction (e.g., useLocalStorage)

9. Wrap-Up

useEffect Cheat Sheet

The Classics: `LocalStorage`, `SessionStorage`, and `Cookies`

`LocalStorage`: The Persistent Key-Value Store

`SessionStorage`: The Tab-Specific Store

`Cookies`: The Server's Messenger

The Modern Powerhouse: `IndexedDB`

`BroadcastChannel` API: The Cross-Tab Communicator

The `Cache API`: The Service Worker's Storage

After Hooks: `useEffect` Unifies the Lifecycle

Why Was `useEffect` Introduced?

2. The Purpose of `useEffect` — What It Really Does

The Three Modes of `useEffect`

Why `useEffect` Can Return a Function

5. Multiple `useEffect`s: Execution and Cleanup Order

6. Debugging `useEffect` Like a Pro

Tips: `useRef` for Tracking

7. When Not to Use `useEffect`

Pattern: Data Fetching with `AbortController`

Pattern: Custom Hooks Abstraction (e.g., `useLocalStorage`)

`useEffect` Cheat Sheet