DEV Community: Muhammed Fayaz T S

useSyncExternalStore: The Right Way to Sync React with localStorage

Muhammed Fayaz T S — Fri, 09 Jan 2026 04:00:00 +0000

React 18 introduced a low-level hook that most developers never touch directly, but almost every modern state library depends on:

useSyncExternalStore

It is React’s official way to connect components to external state sources — state that lives outside React.

Examples:

localStorage
Redux / Zustand stores
browser APIs
WebSocket data

What problem does it solve?

Before React 18, we usually subscribed to stores like this:

useEffect(() => store.subscribe(forceUpdate), []);

This breaks under concurrent rendering.

useSyncExternalStore fixes this by letting React control how it:

subscribes to changes
reads the current value
triggers re-renders safely

The API

const value = useSyncExternalStore(
  subscribe,
  getSnapshot,
  getServerSnapshot?
);

subscribe → how React listens for updates
getSnapshot → how React reads current state

When the snapshot changes, React re-renders.

Example: persistent state with localStorage

1. Create a tiny external store

function createLocalStorageStore(key, initialValue) {
  const listeners = new Set();

  const getSnapshot = () => {
    const data = localStorage.getItem(key);
    return data ? JSON.parse(data) : initialValue;
  };

  const setValue = (value) => {
    localStorage.setItem(key, JSON.stringify(value));
    listeners.forEach((l) => l());
  };

  const subscribe = (listener) => {
    listeners.add(listener);

    const onStorage = (e) => {
      if (e.key === key) listener();
    };

    window.addEventListener("storage", onStorage);

    return () => {
      listeners.delete(listener);
      window.removeEventListener("storage", onStorage);
    };
  };

  return { getSnapshot, setValue, subscribe };
}

2. Connect it to React

import { useSyncExternalStore } from "react";

function useExternalStore(store) {
  return useSyncExternalStore(
    store.subscribe,
    store.getSnapshot,
    store.getSnapshot
  );
}

3. Use it

const counterStore = createLocalStorageStore("counter", 0);

function Counter() {
  const count = useExternalStore(counterStore);

  return (
    <>
      <p>Count: {count}</p>
      <button onClick={() => counterStore.setValue(count + 1)}>
        +
      </button>
    </>
  );
}

Now your state is:

persistent
shared
cross-tab synced
concurrent-safe

When should you use this?

Use useSyncExternalStore when:

state lives outside React
many components share the same data
you’re building a store, persistence layer, or library

For normal component state, useState is still the right tool.

Final takeaway

useState manages React-owned state.
useSyncExternalStore connects React to the outside world.

If you’re building anything beyond local component state, this hook is the foundation.

Proxy State in React: What It Is and How It Differs from useState

Muhammed Fayaz T S — Tue, 06 Jan 2026 09:36:32 +0000

When building React apps, state management is unavoidable. Most of us start with useState, and for good reason — it’s simple, predictable, and built into React.

But as applications grow, you may hear about something called “proxy state.” Libraries like MobX and Valtio often come up in this context.

So what exactly is proxy state?
How does it differ from useState?
And when should you care?

Let’s break it down.

Understanding `useState` first

useState works on a snapshot model.

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

Each update:

does not mutate existing state
replaces it with a new value
triggers a component re-render

With objects, this usually means copying:

const [user, setUser] = useState({ name: "Alex", age: 20 });

setUser(prev => ({
  ...prev,
  age: 21
}));

React only knows something changed because the reference changed. It does not track which property changed.

This approach is:

predictable
aligned with functional programming
extremely well optimized

But it can get verbose and inefficient in large applications.

What “proxy state” means

React itself does not provide proxy state.

The term usually refers to state management libraries that use JavaScript Proxies under the hood.

Examples:

MobX
Valtio
reactive store systems inspired by Solid or Vue

A JavaScript Proxy can intercept operations like:

reading a property
writing a property

This allows libraries to automatically track:

what parts of state a component used
what exactly changed

So instead of replacing state, you mutate it directly.

state.count++;
state.user.name = "Fayaz";

The proxy detects the mutation and notifies only the components that depend on those properties.

The mental model shift

The biggest difference is how you think about state.

`useState` → snapshot-based

state is immutable
updates replace values
re-render happens at the component level

Proxy state → reactive objects

state is mutable
updates are property-level
re-render happens at the usage level

You stop thinking about “setting state” and start thinking about “changing state.”

Example: same logic, two styles

With `useState`

const [cart, setCart] = useState({ items: [], total: 0 });

function addItem(item) {
  setCart(prev => ({
    ...prev,
    items: [...prev.items, item],
    total: prev.total + item.price
  }));
}

You must:

copy objects
replace state
manually keep values in sync

With proxy state (conceptual)

cart.items.push(item);
cart.total += item.price;

The proxy system:

detects the mutation
tracks dependencies
re-renders only what actually used cart.items or cart.total

Your code feels closer to plain JavaScript.

Dependency tracking: the real power

React with useState doesn’t know which properties you accessed.

const name = user.profile.name;

If any part of user changes, the entire component re-renders.

Proxy-based systems track access at runtime:

Component A reads user.name
Component B reads user.age
Only the component that depends on the changed property updates

This is called fine-grained reactivity, and it’s the main technical advantage of proxy state.

Performance implications

useState → coarse-grained updates
Proxy state → fine-grained updates

In large apps with deeply nested global state, proxy systems can significantly reduce unnecessary re-renders.

That said, useState is:

simpler to debug
fully aligned with concurrent React
more than fast enough for most UI state

When proxy state shines

Proxy state is especially useful when:

your app has a large global store
many components read tiny slices of state
state is deeply nested
performance tuning becomes difficult
you prefer mutation-style APIs

When `useState` is still the best choice

Stick with useState when:

state is local to a component
you’re managing UI concerns (forms, modals, toggles)
you want to rely only on core React APIs
explicit, predictable updates matter most

For most UI logic, useState is still the cleanest solution.

Proxy state is not Immer

A common confusion: Immer also uses proxies, but it does not create reactive state.

setState(draft => {
  draft.count++;
});

Immer lets you write mutable code while still producing an immutable snapshot.

Proxy state libraries keep the proxy object alive and make it reactive.

Final takeaway

Proxy state differs from useState because it uses JavaScript Proxies to:

track property access
detect mutations
trigger fine-grained updates

useState works by replacing values and re-rendering components.
Proxy state works by mutating objects and letting a reactive system decide what should update.

Neither is better.
They solve different problems at different scales.

SSR, SSG, and ISR in Next.js – What, Why, and When to Use

Muhammed Fayaz T S — Wed, 26 Mar 2025 06:32:46 +0000

Title: Understanding SSR, SSG, and ISR in Next.js – What, Why, and When to Use

If you’ve been exploring Next.js, you’ve likely come across terms like SSR, SSG, and ISR. These are different rendering strategies that can drastically affect your app’s performance, SEO, and scalability. In this blog, we’ll dive into what these strategies mean, how they work, and when to use each of them.

1. SSR (Server-Side Rendering)

What is SSR?

SSR stands for Server-Side Rendering. In this strategy, the HTML for a page is generated on the server at the time of each request. This means the user always gets the most updated content.

How it works:

When a user visits the page, Next.js runs a function (getServerSideProps) on the server to fetch data and render the HTML. That freshly generated page is then sent to the browser.

Example use case:

export async function getServerSideProps(context) {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: { data },
  };
}

When to use SSR:

Your content changes frequently or in real-time.
You need up-to-date data for every page request.
Your page depends on user-specific data (like user dashboards or authenticated content).
SEO is important, and the content must always be fresh.

2. SSG (Static Site Generation)

What is SSG?

Static Site Generation means that your HTML is generated at build time and served as a static file. Once the page is built, it remains unchanged until you rebuild your application.

How it works:

Next.js uses getStaticProps to fetch data during the build process. The rendered HTML is saved and served to all users from the CDN—making it extremely fast.

Example use case:

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: { data },
  };
}

When to use SSG:

Your content doesn’t change often (e.g., blogs, documentation, landing pages).
You want the fastest page load times.
You want to maximize scalability with static hosting.
SEO is important, and you can work with slightly older data.

3. ISR (Incremental Static Regeneration)

What is ISR?

ISR is a hybrid between SSG and SSR. It allows you to build static pages at build time, and then regenerate them periodically in the background without rebuilding the whole site.

How it works:

Pages are generated like SSG, but you can set a revalidate interval. After that interval, the next request will trigger a regeneration of the page in the background. The newly updated page is then served to future users.

Example use case:

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();

  return {
    props: { data },
    revalidate: 60, // Regenerate the page every 60 seconds
  };
}

When to use ISR:

Your content updates occasionally, but not every second.
You want the speed of SSG with the flexibility of updates.
You’re fetching data from a CMS like WordPress, Strapi, or Contentful.
You want a balance between performance and data freshness.

Quick Comparison

Rendering Method	HTML Generation Time	Best For	Performance	SEO
SSR	On every request	Real-time, dynamic content	Medium	Excellent
SSG	At build time	Static content, blogs	Fastest	Excellent
ISR	Build time + background update	CMS content, product pages	Fast + flexible	Excellent

Real-World Examples

A blog using content from a CMS like Strapi or Contentful → ISR
A pricing page that rarely changes → SSG
A real-time analytics dashboard → SSR
A news site homepage → ISR or SSR depending on update frequency

Final Thoughts

Next.js gives you the power to choose the best rendering method per page. You’re not restricted to one option — you can combine them based on the needs of your application.

To recap:

Use SSR when content is highly dynamic and real-time.
Use SSG when content is mostly static and performance is key.
Use ISR when content changes periodically and you want to avoid full rebuilds.

Choosing the right strategy ensures your app is fast, scalable, and SEO-friendly, giving your users the best experience possible.

Web Workers vs. Service Workers in React: A Complete Guide with Use Cases

Muhammed Fayaz T S — Wed, 26 Mar 2025 05:11:39 +0000

Modern web applications require high performance and smooth user experiences. However, long-running operations like heavy computations, image processing, or background syncing can slow down the UI and degrade performance. This is where Web Workers and Service Workers come in.

In this blog, we’ll explore:

What are Web Workers and Service Workers?
How to use them in a React application?
Real-world use cases with examples.

What is a Web Worker?

A Web Worker is a JavaScript script that runs in the background without affecting the main UI thread. This means you can perform expensive operations like large data processing, image transformations, or complex calculations without freezing the UI.

Use Case: Processing a 10MB Image Without Blocking the UI
Let's say you have a React app where users upload a 10MB image, and you need to apply filters to it. Doing this directly in the main thread would block the UI, making the app unresponsive.

Instead, we can use a Web Worker to handle the processing in the background.

Step 1: Create a Web Worker file (imageWorker.js)
Create a separate file for the worker:

self.onmessage = async (event) => {
  const imageData = event.data;

  // Simulate a heavy image processing task
  const processedImage = await applyFilter(imageData);

  // Send the processed image back to the main thread
  self.postMessage(processedImage);
};

// Simulated image processing function
const applyFilter = async (imageData) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(`Filtered version of ${imageData}`);
    }, 3000); // Simulate processing delay
  });
};

Step 2: Use the Worker in a React Component
Now, let's integrate the worker into a React component:


import { useState } from "react";

const ImageProcessor = () => {
  const [image, setImage] = useState(null);
  const [filteredImage, setFilteredImage] = useState(null);

  const handleImageUpload = (event) => {
    const file = event.target.files[0];

    if (file) {
      const worker = new Worker(new URL("./imageWorker.js", import.meta.url));

      worker.postMessage(file.name);

      worker.onmessage = (e) => {
        setFilteredImage(e.data);
        worker.terminate();
      };
    }
  };

  return (
    <div>
      <input type="file" onChange={handleImageUpload} />
      {filteredImage && <p>Processed Image: {filteredImage}</p>}
    </div>
  );
};

export default ImageProcessor;

How This Works?

The worker receives the image and applies the filter in the background.
The UI remains responsive while the worker processes the image.
Once processing is done, the worker sends the processed image back to React.

What is a Service Worker?

A Service Worker is a background script that acts as a proxy between your web app and the network. It enables functionalities like:

Push Notifications
Background Syncing
Offline Support & Caching

Unlike Web Workers, Service Workers persist beyond page reloads and can work even when the app is closed.

Use Case: Implementing Push Notifications in React
Let’s build a simple push notification feature using a Service Worker.

Step 1: Register the Service Worker
Inside src/serviceWorker.js, add:

self.addEventListener("push", (event) => {
  const options = {
    body: "New update available!",
    icon: "/logo.png",
    badge: "/badge.png",
  };

  event.waitUntil(self.registration.showNotification("React App", options));
});

Step 2: Register the Service Worker in React
Inside index.js, register the service worker:

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/serviceWorker.js")
    .then(() => console.log("Service Worker Registered"))
    .catch((error) => console.log("Service Worker Registration Failed:", error));
}

Step 3: Trigger Push Notification
You can trigger a push notification from your backend or manually using:

navigator.serviceWorker.ready.then((registration) => {
  registration.showNotification("Hello! This is a test notification.");
});

How This Works?

The service worker listens for push events in the background.
When a new event (like an update) occurs, it displays a notification.
The user is notified even when the app is closed or running in the background.

Key Differences: Web Worker vs. Service Worker

Feature	Web Worker	Service Worker
Runs in Background	✅ Yes	✅ Yes
Persists After Page Reload	❌ No	✅ Yes
Blocks UI?	❌ No	❌ No
Handles Network Requests	❌ No	✅ Yes

Use Cases CPU-intensive tasks (e.g., image processing) Push notifications, caching, background sync
Final Thoughts
Both Web Workers and Service Workers are powerful tools that improve performance and user experience in modern web applications.

Use Web Workers when you need to perform heavy computations like image processing, data parsing, or mathematical calculations.
Use Service Workers when you need background tasks like push notifications, offline caching, or background sync.

By leveraging these tools, you can build highly performant and interactive React applications. 🚀

Would you like me to expand this with a real-world project that combines both Web Workers and Service Workers in a single app? Let me know!

7 Useful Custom Hooks Every React Beginner Should Know

Muhammed Fayaz T S — Fri, 14 Mar 2025 07:08:06 +0000

If you've recently started your journey into the world of React, you've probably come across the term "custom hooks." These powerful abstractions allow you to extract reusable logic from components and make your code cleaner, more readable, and easier to maintain.

In this post, we’ll explore 7 beginner-friendly custom hooks that can significantly enhance your React development experience. Let’s dive in!

1️⃣ `useMediaQuery` – Reactively Handle Screen Sizes

Modern applications must be responsive. useMediaQuery helps you reactively check if a specific CSS media query matches the current screen size.

import { useState, useEffect } from "react";

const useMediaQuery = (query) => {
  const [matches, setMatches] = useState(false);

  useEffect(() => {
    const media = window.matchMedia(query);
    setMatches(media.matches);

    const listener = () => setMatches(media.matches);
    media.addEventListener("change", listener);
    return () => media.removeEventListener("change", listener);
  }, [query]);

  return matches;
};

// Usage
const isMobile = useMediaQuery("(max-width: 768px)");

✅ Great for conditional rendering based on screen width.

2️⃣ `useBreakpoint` – Responsive Design Made Easy

Building on useMediaQuery, you can create a more organized hook to detect specific breakpoints (like xs, sm, md, lg, etc.).

const useBreakpoint = () => {
  const isXs = useMediaQuery('(max-width: 576px)');
  const isSm = useMediaQuery('(min-width: 577px) and (max-width: 768px)');
  const isMd = useMediaQuery('(min-width: 769px) and (max-width: 992px)');
  const isLg = useMediaQuery('(min-width: 993px) and (max-width: 1200px)');
  const isXl = useMediaQuery('(min-width: 1201px)');

  return { isXs, isSm, isMd, isLg, isXl };
};

✅ Helps you apply screen-specific logic easily.

3️⃣ `useDebounce` – Delay Rapid Function Calls

Debouncing prevents a function from being called too frequently—very useful for search inputs, API calls, and filters.

import { useState, useEffect } from "react";

const useDebounce = (value, delay = 300) => {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const handler = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(handler);
  }, [value, delay]);

  return debounced;
};

// Usage
const debouncedSearchTerm = useDebounce(searchTerm, 500);

✅ Improve performance and reduce unnecessary calls.

4️⃣ `useThrottle` – Limit Function Execution Rate

Similar to debounce, but throttle ensures the function is only executed once every fixed interval, no matter how many times it's triggered.

import { useRef, useState, useEffect } from "react";

const useThrottle = (value, limit = 300) => {
  const [throttledValue, setThrottledValue] = useState(value);
  const lastRan = useRef(Date.now());

  useEffect(() => {
    const handler = setTimeout(() => {
      if (Date.now() - lastRan.current >= limit) {
        setThrottledValue(value);
        lastRan.current = Date.now();
      }
    }, limit - (Date.now() - lastRan.current));

    return () => clearTimeout(handler);
  }, [value, limit]);

  return throttledValue;
};

✅ Great for scroll events or resize listeners.

5️⃣ `useLocalStorage` – Persist Data Across Sessions

Want to remember user preferences? useLocalStorage provides a simple way to get and set values in the browser’s localStorage.

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

  const setValue = (value) => {
    setStoredValue(value);
    window.localStorage.setItem(key, JSON.stringify(value));
  };

  return [storedValue, setValue];
};

✅ Perfect for themes, login tokens, or settings.

6️⃣ `useClickOutside` – Detect Outside Clicks

Very helpful for modals, dropdowns, and popups. It triggers an action when a user clicks outside of a given ref.

const useClickOutside = (ref, callback) => {
  useEffect(() => {
    const handleClick = (event) => {
      if (ref.current && !ref.current.contains(event.target)) {
        callback();
      }
    };
    document.addEventListener("mousedown", handleClick);
    return () => document.removeEventListener("mousedown", handleClick);
  }, [ref, callback]);
};

✅ Keeps your UI interactions intuitive.

7️⃣ `usePrevious` – Get Previous State Value

Ever needed to compare current and previous values? This hook stores and returns the previous state or prop.

import { useEffect, useRef } from "react";

const usePrevious = (value) => {
  const ref = useRef();
  useEffect(() => {
    ref.current = value;
  }, [value]);
  return ref.current;
};

✅ Useful for tracking value changes or animations.

📌 Final Thoughts

Custom hooks are like secret tools in your React toolbox. As a beginner, learning to build and use them not only makes you more productive but also deepens your understanding of React’s powerful hook system.

👉 Start by copying and customizing the examples above. Over time, you’ll build your own set of reusable hooks tailored to your projects.

DEV Community: Muhammed Fayaz T S

useSyncExternalStore: The Right Way to Sync React with localStorage

What problem does it solve?

The API

Example: persistent state with localStorage

1. Create a tiny external store

2. Connect it to React

3. Use it

When should you use this?

Final takeaway

Proxy State in React: What It Is and How It Differs from useState

Understanding useState first

What “proxy state” means

The mental model shift

useState → snapshot-based

Proxy state → reactive objects

Example: same logic, two styles

With useState

With proxy state (conceptual)

Dependency tracking: the real power

Performance implications

When proxy state shines

When useState is still the best choice

Proxy state is not Immer

Final takeaway

SSR, SSG, and ISR in Next.js – What, Why, and When to Use

Title: Understanding SSR, SSG, and ISR in Next.js – What, Why, and When to Use

1. SSR (Server-Side Rendering)

2. SSG (Static Site Generation)

3. ISR (Incremental Static Regeneration)

Quick Comparison

Real-World Examples

Final Thoughts

Web Workers vs. Service Workers in React: A Complete Guide with Use Cases

What is a Web Worker?

What is a Service Worker?

7 Useful Custom Hooks Every React Beginner Should Know

1️⃣ useMediaQuery – Reactively Handle Screen Sizes

2️⃣ useBreakpoint – Responsive Design Made Easy

3️⃣ useDebounce – Delay Rapid Function Calls

4️⃣ useThrottle – Limit Function Execution Rate

5️⃣ useLocalStorage – Persist Data Across Sessions

6️⃣ useClickOutside – Detect Outside Clicks

7️⃣ usePrevious – Get Previous State Value

📌 Final Thoughts

Understanding `useState` first

`useState` → snapshot-based

With `useState`

When `useState` is still the best choice

1️⃣ `useMediaQuery` – Reactively Handle Screen Sizes

2️⃣ `useBreakpoint` – Responsive Design Made Easy

3️⃣ `useDebounce` – Delay Rapid Function Calls

4️⃣ `useThrottle` – Limit Function Execution Rate

5️⃣ `useLocalStorage` – Persist Data Across Sessions

6️⃣ `useClickOutside` – Detect Outside Clicks

7️⃣ `usePrevious` – Get Previous State Value