DEV Community: Ogasawara Kakeru

React.js ~use() hook Rules and Gotchas~

Ogasawara Kakeru — Sun, 31 May 2026 08:30:24 +0000

use() can be called conditionally
Unlike every other hook, use() works inside if, for, and after early returns. React's linter is aware of this exception.

use() cannot be called in try-catch
Rejected promises are caught by Error Boundaries, not by try-catch blocks. If you wap use() in a try-catch, React throws a "Suspense Exception" error.

// This will crash
try {
  const data = use(promise);
} catch (e) {
  // Never reaches here
}

If you need to provide a fallback value for a rejected promise, use .catch() on promise itself:

const safePromise = riskyFetch().catch(() => defaultValue);
const data = use(safePromise);

Resolved values must be serialization(Server to Client)
When passing a promise from a Server Component to a Client Component, the resolved value must be serializable, no functions, no class instance, no symbols, plain objects, and arrays are fine.

Don't mix patterns for the same data
If you read a promise with use(), don't also fetch the same data in a useEffect. Pick one source of truth for each piece of data.

React.js ~Migrating Away from useEffect + setState~

Ogasawara Kakeru — Fri, 29 May 2026 06:15:12 +0000

If you have an existing codebase full of useEffect-fetch-setState pattern, you don't need to rewrite everything at once. Here is a practical migration path:

**Step 1: Extract to a Custom Hook
Before changing the data fetching mechanism, encapsulate the exisiting pattern:

function useUser(id: string) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    let cancelled = false;
    setIsLoading(true);
    fetchUser(id)
      .then((data) => {
        if (!cancelled) setUser(data);
      })
      .catch((err) => {
        if (!cancelled) setError(err);
      })
      .finally(() => {
        if (!cancelled) setIsLoading(false);
      });
    return () => {
      cancelled = true;
    };
  }, [id]);

  return { user, isLoading, error };
}

**Step 2: Add Suspense Boundaries
Wrap the consuming components in Suspense and Error Boundaries. This is safe even before switching to use(): the boundaries just don't trigger yet:

<ErrorBoundary fallback={<ErrorMessage />}>
  <Suspense fallback={<Skeleton />}>
    <UserProfile userId={userId} />
  </Suspense>
</ErrorBoundary>

**Step 3:Swap the Internals
Now change the custom hook(or the component) to accept a promise and use use(). The consuming components don't change; they already have Suspense boundaries:

function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <ProfileCard user={user} />;
}

**Step 4:Move the Fetch Up
Push promise creation to Server Components or to a caching layer. This is the real architectural shift, data initiation moves from the component that needs it to the component(or server) that can create a stable reference.

React.js ~The landscape of data fetching in React~

Ogasawara Kakeru — Wed, 27 May 2026 08:32:05 +0000

The landscape of data fetching in React has more options than ever. Here is when each one is the right choice:

Scenario	Approach
Server Component fetching data	`async` / `await` directly in the component
Passing async data from Server to Client Component	Create promise on server, `use()` on client with Suspense
Simple client-side fetch (popup, dialog, one-off display)	`use()` with a cached promise + Suspense
Complex client state (auto-refetch, pagination, mutations)	TanStack Query or SWR
Computed/derived state from props or other state	`useMemo` or direct calculation during render
Reading context conditionally	`use(SomeContext)`
Reading context unconditionally	`useContext(SomeContext)` : simpler, more familiar
Subscribing to an external store (Redux, Zustand, browser API)	`useSyncExternalStore`
DOM measurements, event listeners, timers	`useEffect` : this is what it's actually for

React.js ~use() for Context~

Ogasawara Kakeru — Mon, 25 May 2026 23:28:42 +0000

use() can also read Context, and this is where it breaks a rule that every other hook follows.

Every React hook must be called at the top level of a component, never inside conditions, loops, or early returns. use() is the exception. It can be called conditionally:

function Greeting({ showFormal }: { showFormal: boolean }) {
  if (showFormal) {
    const { locale } = use(I18nContext);
    return <p>{locale === "de" ? "Guten Tag" : "Good day"}</p>;
  }
  return <p>Hey!</p>;
}

With useContext, this code would violate the rules of hooks. With use() lets you skip reading it entirely when the condition is false. With useContext, the component subscribes to that context unconditionally, even when it doesn't need the value.

React.js ~use() hook for Caching Problem~

Ogasawara Kakeru — Sun, 24 May 2026 01:26:26 +0000

This is where most tutorials stop. But if you try to use use() with a promise created inside a Client Component, you will hit a subtle and frustrating bug.

// Bug: creates a new promise on every render
function UserProfile({ userId }: { userId: string }) {
  const user = use(fetchUser(userId)); // new promise every render
  return <ProfileCard user={user} />;
}

fetchUser(userId) returns a new Promise object on every render. React sees a new promise, suspends again, and the component re-renders, creates another new promise, suspends again, infinite loop.

use() does not fetch data. It reads a promise. The promise must have a stable identity across renders. If you create a new promise on every render, you get an infinite suspension loop.

How to Stabilize the Promise
There are several approaches, each suited to a different archtecture:

1. Create the promise in a parent component or Server Component

// Server Component - promise created once, stable across renders
export default function UserPage({ params }: { params: { id: string } }) {
  const userPromise = fetchUser(params.id);

  return (
    <Suspense fallback={<Skeleton />}>
      <UserProfile userPromise={userPromise} />
    </Suspense>
  );
}

No async/await needed, the promise is passed down unresolved. The Client Component unwraps it with use(). Server Components don't re-render, so the promise reference is inherently stable.

2. Use a module-level cache

For Client Components that need to initiate fetches, cache the promise so the same reference is returned on subsequent calls:

const cache = new Map<string, Promise<User>>();

function fetchUserCached(id: string): Promise<User> {
  if (!cache.has(id)) {
    cache.set(id, fetchUser(id));
  }
  return cache.get(id)!;
}

function UserProfile({ userId }: { userId: string }) {
  const user = use(fetchUserCached(userId));
  return <ProfileCard user={user} />;
}

Same arguments produce the same promise reference. No infinite loop.

Avoid async in Cache Wrappers

Do not mark your cache function as async. The async keyword always creates a new promise, even if you return a cached value. Use a synchronous function that stores and returns the original promise object.

3. Use a data fetching library

Libraries like TanStack Query or SWR handle caching, deduplication, and revalidation out of the box. They predate use() and solve a much broader problem - but they also add ~13kB gzipped and a provider wrapper. For a simple "fetch once, display result" pattern, use() with a 5-line cache function (option 2 above) does the job without the extra dependency. The library earns its keep when your UI has long-lived client state that needs to stay fresh: think dashboards that refetch on tab focus, lists with pagination, or mutations that should optimistically update related queries.

4. Use React's cache() in Server Components
React provides a built-in cache() function for Server Components. It memoizes a function's return value for the lifetime of a single server request:

import { cache } from "react";

const getUser = cache(async (id: string): Promise<User> => {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
});

Multiple components calling getUser("123") during the same render will share one fetch. The cache is scoped to the request, it resets on every new page load.

cache() vs. useMemo
Both memoize. But cache() works across components in a server render (deduplication), while useMemo works within a single component across re-renders. cache() is for data fetching. useMemo is for computations. Different tools, different jobs.

React.js ~use() hook for loading/error guards~

Ogasawara Kakeru — Thu, 21 May 2026 04:13:16 +0000

The Pattern It replaces

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    /* ... fetch, cancelled flag, setState ... */
  }, [userId]);

  if (isLoading) return <Skeleton />;
  if (error) return <ErrorMessage error={error} />;
  if (!user) return null;

  return <ProfileCard user={user} />;
}

Three state declareations, one effect, three conditional returns: all before you reach the actual UI.Every component that fetches data repeats this structure.

Here is the same component with use():

// Client Component - only the happy path
"use client";

import { use } from "react";

function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <ProfileCard user={user} />;
}

// Server Component - creates the promise and defines the boundaries
import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";

export default function UserPage({ params }: { params: { id: string } }) {
  const userPromise = fetchUser(params.id);

  return (
    <ErrorBoundary fallback={<ErrorMessage />}>
      <Suspense fallback={<Skeleton />}>
        <UserProfile userPromise={userPromise} />
      </Suspense>
    </ErrorBoundary>
  );
}

The loading state is handled by <Suspense>.The error state is handled by <ErrorBoundary>(from the react-error-boundary package). The component itself only contains the happy path - the code that runs when data is available. The state machine has been moved from your code into React's runtime.

Because UserPage is a Server Component, it does not re-render. The promise reference is created once and passed down as a stable prop, no caching gymnastics needed.

Separation of Concerns

Notice how the component that uses the data (UserProfile) is separated from the component that initiates the fetch and defines the loading/error UI (UserPage). This is intentional. The consumer doesn't know where the promise came from or what to show while waiting.

React.js ~use() hook~

Ogasawara Kakeru — Tue, 19 May 2026 21:48:40 +0000

Every React developer has written this code:

const [data, setData] = useState<User | null>(null);
const [isLoading, setIsLoading] = useState(true);
const [error, setError] = useState<Error | null>(null);

useEffect(() => {
  let cancelled = false;
  setIsLoading(true);

  fetchUser(id)
    .then((user) => {
      if (!cancelled) setData(user);
    })
    .catch((err) => {
      if (!cancelled) setError(err);
    })
    .finally(() => {
      if (!cancelled) setIsLoading(false);
    });

  return () => {
    cancelled = true;
  };
}, [id]);

Three state variables. A cleanup flag. A dependency array. A race condition you have to think about every single time. And this is the correct version: most codebases skip the canceled flag and the error handling entirely.

This pattern is not wrong. It works. But it is boilerplate that exists because React had no built-in way to say "wait for this promise, then render." Every component that etches data had to reinvent the same loading/error/data state machine from scratch.

React 19 introduced use() to fix this. It is the first hook that can be called inside conditionals and loops, it integrates directly with Suspense, and it turns the fetch-then-setState pattern into a single line.

**What use() Does

use() reads a value from a resource at render time. The resource can be a Promise or a Context.

import { use } from "react";

// Read a promise - suspends until resolved
const user = use(userPromise);

// Read context - like useContext, but callable in conditionals
const theme = use(ThemeContext);

That is the entire API. One function, two use cases.

When you pass a Promise, use() integrates with the nearest <Suspense> boundary. While the promise is pending, the component suspends. React shows the Suspense fallback. When it resolves, React re-renders with the resolved value. When it rejects, the nearest Error Boundary catches the error.

No useState. No useEffect. No isLoading. No setData. React handles all of it.

use() does not fetch data. It unwraps a promise that someone else created. The distinction matters.

**The Pattern It Replaces
Wrap the snippet from above into a component and add the obligatory loading/error guards:

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    /* ... fetch, cancelled flag, setState ... */
  }, [userId]);

  if (isLoading) return <Skeleton />;
  if (error) return <ErrorMessage error={error} />;
  if (!user) return null;

  return <ProfileCard user={user} />;
}

Three state declarations, one effect, three conditional returns: all before you reach the actual UI. Every component that fetches data repeats this structure.

Here is the same component with use():

// Client Component - only the happy path
"use client";

import { use } from "react";

function UserProfile({ userPromise }: { userPromise: Promise<User> }) {
  const user = use(userPromise);
  return <ProfileCard user={user} />;
}

// Server Component - creates the promise and defines the boundaries
import { Suspense } from "react";
import { ErrorBoundary } from "react-error-boundary";

export default function UserPage({ params }: { params: { id: string } }) {
  const userPromise = fetchUser(params.id);

  return (
    <ErrorBoundary fallback={<ErrorMessage />}>
      <Suspense fallback={<Skeleton />}>
        <UserProfile userPromise={userPromise} />
      </Suspense>
    </ErrorBoundary>
  );
}

The loading state is handled by <Suspense>. The error state is handled by <ErrorBoundary> (from the react-error-boundarypackage). The component itself only contains the happy path - the code that runs when data is available. The state machine has been moved from your code into React's runtime.

Because UserPage is a Server Component, it does not re-render. The promise reference is created once and passed down as a stable prop, no caching gymnastics needed.

**Separation of Concerns
Notice how the component that uses the data (UserProfile) is separated from the component that initiates the fetch and defines the loading/error UI (UserPage). This is intentional. The consumer doesn't know where the promise came from or what to show while waiting.

React.js ~Life Cycle~

Ogasawara Kakeru — Thu, 14 May 2026 21:29:06 +0000

In React, the life cycle is composed of Mount(create), Update(update) and Unmount(delete).

The life cycle method is defined as those of method.

componentDidMount
- created when the first render once.
- Used when API connection, DOM manipulation.
componentDidUpdate
- Run when updating DOM.
- Used in every time updating such as DOM manipulation.
componentWillUnmount
- Run when deleting components.
- Used in eventListner, timer, and closing API connection.

Side Effect Hook
useEffect hook can replace the life cycle method instead.
useEffect can be used for componentDidMount(runs when generate component), componentDidUpdate(runs every time update) and componentWillUnmount(runs when delete component).

**componentDidMount

useEffect( () => {
    // Runs when initial render
}, []);

**componentDidUpdate

useEffect( () => {
    // Runs every time when rendering
});

**componentWillUnmount

useEffect( () => {
    // Runs every time when rendering
    return (
        // Cleanup something
    );
});

The lifecycle refers to the sequence of events through which a React component is created, updated, and eventually destroyed.
The useEffect method in hooks allows you to perform operations similar to those of lifecycle methods within a single function.

ReactJs Performance ~ Server-Side Rendering (SSR) and Static Generation ~

Ogasawara Kakeru — Sun, 10 May 2026 22:23:26 +0000

SSR and Static Site Generation (SSG) shift page rendering from the client to the server, allowing users to receive pre-rendered HTML immediately. This approach significantly enhances loading speed, user experience, and search engine visibility.

Rendering Strategy Comparison

Client-Side Rendering (CSR)

The browser first downloads JavaScript files
JavaScript runs and generates the UI in the browser
Users see content only after rendering completes
Estimated load time: around 2–4 seconds

Server-Side Rendering (SSR)

The server generates complete HTML before sending it
The browser can display content right away
JavaScript then adds interactive functionality through hydration
Estimated load time: around 0.5–1.5 seconds

Static Site Generation (SSG)

Pages are generated as static HTML during the build process
Content is delivered instantly through a CDN
JavaScript hydrates the page to enable interactions
Estimated load time: around 0.2–0.8 seconds

Next.js SSR Implementation

// pages/products/[id].js

// This function runs on the server each time the page is requested
export async function getServerSideProps({ params }) {
  const product = await fetchProduct(params.id);

  return {
    props: {
      product,
    },
  };
}

// The component receives product data before the page is rendered
export default function ProductPage({ product }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <button>Add to Cart</button>
    </div>
  );
}

Next.js SSG Implementation

// pages/blog/[slug].js

// This function executes during the build process
export async function getStaticPaths() {
  const posts = await fetchAllPosts();

  return {
    paths: posts.map((post) => ({
      params: { slug: post.slug },
    })),
    fallback: "blocking", // Generate pages dynamically when needed
  };
}

// Fetch data and generate static pages ahead of time
export async function getStaticProps({ params }) {
  const post = await fetchPost(params.slug);

  return {
    props: {
      post,
    },
    revalidate: 3600, // Refresh the page every hour
  };
}

// The page is served as pre-rendered HTML
export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

**Rendering Strategy Performance**
| Rendering Strategy | Initial Server Response | First Visual Display | Fully Usable State | SEO Performance | Best Fit |
|---|---|---|---|---|---|
| CSR (Client-Side Rendering) | Around 100–200ms | Usually 2–4 seconds | Around 2.5–5 seconds | Weak for search engines | Apps that require authentication or heavy client-side interaction |
| SSR (Server-Side Rendering) | Around 200–500ms | Roughly 0.5–1.5 seconds | About 1–2.5 seconds | Very strong | Frequently updated pages and dynamic data |
| SSG (Static Site Generation) | Around 50–100ms | Roughly 0.2–0.8 seconds | Around 0.5–1.5 seconds | Excellent | Fully static websites and landing pages |
| ISR (Incremental Static Regeneration) | Around 50–150ms | Roughly 0.2–1 second | Around 0.5–1.8 seconds | Excellent | Pages that are mostly static but occasionally updated |
| Partial Hydration | Around 50–150ms | Roughly 0.2–0.8 seconds | Around 0.3–1.2 seconds | Excellent | Applications combining static and interactive sections |

## Incremental Static Regeneration (ISR)

ISR combines the speed of static generation with the flexibility of dynamic updates. Pages are pre-rendered as static HTML, but they can be regenerated automatically after a specified interval.

javascript
export async function getStaticProps() {
const data = await fetchData();

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




After the revalidation period expires, the first visitor triggers a background regeneration process. That user still receives the existing cached page while the updated version is being rebuilt. Once regeneration finishes, future visitors receive the newly updated page.

This approach provides the speed advantages of static pages while still keeping content regularly updated.

Popular frameworks that support SSR and SSG include Next.js, Remix, Gatsby, and Astro. Although each framework has its own rendering strategy and optimization techniques, all aim to improve initial page loading performance compared to traditional Client-Side Rendering (CSR).

For content-focused websites, SSG can reduce loading times by roughly 60–80% compared to CSR. In highly dynamic applications, SSR often improves perceived performance by around 40–60%. However, these benefits usually come with additional server complexity and potentially higher infrastructure costs.

**Implementation Roadmap**
Rolling out all 15 optimizations at once overwhelms teams. Here's a practical implementation sequence based on effort vs. impact:

**Phase 1 - Quick Wins (Week 1-2):**

-Enable React Compiler (automatic memoization)
-Implement route-based code splitting
-Add image optimization and lazy loading
-Configure bundle analyzer

**Phase 2 - Foundation (Week 3-4):**

-Optimize state management (switch to Zustand if using Context)
-Implement virtualization for large lists
-Set up performance monitoring
-Add database query optimization

**Phase 3 - Advanced (Week 5-8):**

-Implement tree shaking and bundle optimization
-Add PWA capabilities with service workers
-Optimize CSS and defer third-party scripts
-Implement memory leak prevention

**Phase 4 - Architecture (Week 9-12):**

-Move to SSR/SSG where appropriate
-Implement Web Workers for heavy computations
-Full performance audit and tuning

# Frontend Optimization Priorities

| Optimization | Effort | Impact | Priority | Prerequisites |
|---|---|---|---|---|
| React Compiler | Low | Very High | 1 | React 19+ |
| Code splitting | Low | Very High | 1 | None |
| Image optimization | Low | High | 1 | None |
| State management | Medium | Very High | 2 | Architecture review |
| Virtualization | Medium | High | 2 | Large lists identified |
| Performance monitoring | Low | High | 2 | Analytics setup |
| Database optimization | Medium | Very High | 2 | Backend access |
| Bundle analysis | Low | High | 3 | Build pipeline |
| PWA features | Medium | Medium | 3 | Service worker knowledge |
| CSS optimization | Medium | Medium | 3 | CSS audit |
| Third-party optimization | Low | High | 3 | Script inventory |
| Memory leak prevention | Medium | Medium | 4 | Development practices |
| Web Workers | High | Medium | 4 | Heavy computation identified |
| SSR/SSG | Very High | Very High | 4 | Framework migration |

ReactJs Performance ~ Memory Leak Prevention ~

Ogasawara Kakeru — Thu, 07 May 2026 01:36:20 +0000

Memory leaks gradually reduce the responsiveness of React applications. At first everything feels normal, but after extended usage — around 10 to 15 minutes — the UI may start lagging, animations become choppy, and in severe cases the application can freeze or crash completely.

Frequent Causes of Memory Leaks in React

1. Timers and intervals that are never cleared

// ❌ Risky: interval continues even after component removal
function AutoCounter() {
  const [value, setValue] = useState(0);

  useEffect(() => {
    window.setInterval(() => {
      setValue((previous) => previous + 1);
    }, 1000);

    // No interval cleanup
  }, []);

  return <div>{value}</div>;
}

// ✅ Better: clear interval during unmount
function ManagedAutoCounter() {
  const [value, setValue] = useState(0);

  useEffect(() => {
    const timer = window.setInterval(() => {
      setValue((previous) => previous + 1);
    }, 1000);

    return () => {
      window.clearInterval(timer);
    };
  }, []);

  return <div>{value}</div>;
}

2. Event handlers that remain attached:

// ❌ Incorrect: listener remains active after unmount
function ResponsiveLayout() {
  useEffect(() => {
    window.addEventListener('resize', updateViewportSize);

    // Cleanup is missing
  }, []);

  return <div>Responsive page</div>;
}

// ✅ Correct: unregister listener during cleanup
function SafeResponsiveLayout() {
  useEffect(() => {
    window.addEventListener('resize', updateViewportSize);

    return () => {
      window.removeEventListener('resize', updateViewportSize);
    };
  }, []);

  return <div>Responsive page</div>;
}

3. WebSocket sessions left active:

// ❌ Problematic: socket connection is never terminated
function RealtimeFeed() {
  useEffect(() => {
    const socket = new WebSocket('wss://stream.example.dev');

    socket.onmessage = receiveLiveUpdate;

    // No cleanup logic
  }, []);

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

// ✅ Safer approach: disconnect on component cleanup
function StableRealtimeFeed() {
  useEffect(() => {
    const socket = new WebSocket('wss://stream.example.dev');

    socket.onmessage = receiveLiveUpdate;

    return () => {
      socket.close();
    };
  }, []);

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

4. Retaining references to heavy data objects:

// ❌ Inefficient: keeps heavy data in memory
function InefficientComponent({ dataset }) {
  const cacheRef = useRef(null);

  useEffect(() => {
    // Stores transformed data without cleanup
    cacheRef.current = transformDataset(dataset);
  }, [dataset]);

  return <div>Data ready</div>;
}

// ✅ Improved: clears unused references properly
function OptimizedComponent({ dataset }) {
  const cacheRef = useRef(null);

  useEffect(() => {
    cacheRef.current = transformDataset(dataset);

    return () => {
      // Remove retained reference during cleanup
      cacheRef.current = undefined;
    };
  }, [dataset]);

  return <div>Data ready</div>;
}

Memory Leak Detection Checklist

Leak Category	Detection Technique	Severity	Estimated Fix Time	Fix Difficulty
Unremoved event listeners	Inspect with memory profiling tools	High	5–10 minutes	Low
Uncleared timers or intervals	Check console warnings and logs	High	2–5 minutes	Low
Persistent WebSocket connections	Monitor through the Network panel	High	10–20 minutes	Low
Retained large object references	Compare heap snapshots	Medium	15–30 minutes	Medium
Unintended closure retention	Analyze heap snapshots	Medium	20–40 minutes	High
Lingering DOM node references	Track using memory profiler	Low	30–60 minutes	Low

// Enable only during local development
if (process.env.NODE_ENV === 'development') {
  useEffect(() => {
    const monitorHeapUsage = () => {
      if (!performance.memory) return;

      const heapSizeInMB =
        performance.memory.usedJSHeapSize / (1024 * 1024);

      console.log(
        `[Heap Monitor] Current usage: ${heapSizeInMB.toFixed(2)} MB`
      );

      // Warn when memory consumption becomes unusually high
      if (heapSizeInMB >= 200) {
        console.warn(
          '[Heap Monitor] Potential memory leak detected.'
        );
      }
    };

    // Run memory inspection every 5 seconds
    const timerId = window.setInterval(monitorHeapUsage, 5000);

    return () => {
      window.clearInterval(timerId);
    };
  }, []);
}

Chrome DevTools provides a Memory profiling tool that helps identify memory leaks through heap snapshots and allocation tracking. A common workflow is to capture one snapshot before a user action and another afterward, then compare the results to detect objects that remain unexpectedly in memory.

If certain objects continue to exist even though they are no longer needed and should have been garbage collected, this usually suggests a memory retention issue or leak.

ReactJs Performance ~ Web Workers for Heavy Computations ~

Ogasawara Kakeru — Sun, 03 May 2026 08:29:22 +0000

JavaScript runs on a single thread, which means intensive tasks can freeze the UI and hurt the user experience.

To avoid this, you can offload heavy work to background threads using Web Workers.

🔧 When Web Workers are useful

Processing images or videos in the browser
Handling large datasets (sorting, filtering, transformations)
Performing CPU-heavy calculations (e.g. simulations, analytics)
Parsing large files like CSV, JSON, or XML
Running cryptographic or hashing operations
Managing real-time data streams without blocking the UI

Web Worker implementation example

// dataWorker.js
self.addEventListener('message', event => {
  const { items, taskType } = event.data;

  const output = runBackgroundTask(items, taskType);

  self.postMessage({
    status: 'completed',
    result: output,
  });
});

function runBackgroundTask(items, taskType) {
  if (taskType !== 'transform') {
    return items;
  }

  return items.map(item => {
    return applyHeavyTransformation(item);
  });
}

function applyHeavyTransformation(item) {
  // Put CPU-heavy logic here
  return {
    ...item,
    processed: true,
  };
}

// DataProcessor.jsx
import { useEffect, useState } from 'react';

function DataProcessor({ items }) {
  const [result, setResult] = useState([]);
  const [isRunning, setIsRunning] = useState(false);

  useEffect(() => {
    const backgroundWorker = new Worker(
      new URL('./dataWorker.js', import.meta.url)
    );

    backgroundWorker.addEventListener('message', event => {
      setResult(event.data.result);
      setIsRunning(false);
    });

    setIsRunning(true);

    backgroundWorker.postMessage({
      items,
      taskType: 'transform',
    });

    return () => {
      backgroundWorker.terminate();
    };
  }, [items]);

  if (isRunning) {
    return <LoadingIndicator />;
  }

  return <DataVisualization data={result} />;
}

In this example, the expensive transformation is moved outside the main React rendering flow.

The component sends raw data to the worker, waits for the processed result, and keeps the UI responsive while the task runs in the background.

Performance Comparison by Task Type

Task	Main Thread	Worker Thread	UI Smoothness	Implementation Difficulty
Image filtering	~800ms (blocks execution)	~850ms (runs off the main thread)	Maintains 60 FPS	Moderate
Data sorting (100k items)	~450ms (blocking)	~480ms (non-blocking)	Maintains 60 FPS	Low
JSON parsing (large payload)	~600ms (causes freeze)	~620ms (handled in background)	Maintains 60 FPS	Low
Physics simulations	~1200ms (UI freeze)	~1250ms (processed asynchronously)	Maintains 60 FPS	High
Cryptographic operations	~350ms (blocking)	~360ms (keeps UI responsive)	Maintains 60 FPS	Moderate
Video transcoding	Not feasible (too heavy)	Executed in background	Maintains 60 FPS	Very High

⚠️ Things to know before using Web Workers

While Web Workers are powerful, they come with a few trade-offs:

They cannot directly interact with the DOM
Memory is isolated from the main thread (SharedArrayBuffer is an advanced workaround)
Communication between threads introduces latency (~5–10ms per message)
Data must be serialized/deserialized when passing between threads

🧠 When should you actually use them?

A good rule of thumb:

If a task takes longer than ~50ms, it's a good candidate for a Web Worker.

For shorter operations, the cost of message passing can outweigh the performance gains.

In those cases, you might be better off using:

requestIdleCallback → to run tasks when the browser is idle
Simple async patterns → to avoid blocking rendering

🛠️ Modern tooling makes it easier

Today’s tooling significantly reduces the complexity of working with Web Workers:

Vite / Webpack → allow direct worker imports with minimal setup
Comlink → abstracts message passing into a simple function-call-like API

These tools make it much easier to integrate background processing into modern frontend applications without dealing with low-level boilerplate.

💡 Practical perspective

Use Web Workers selectively.

They shine in CPU-heavy scenarios, but for lightweight tasks, simpler approaches often lead to better overall performance and maintainability.

ReactJs Performance ~ Tree Shaking and Bundle Analysis ~

Ogasawara Kakeru — Wed, 29 Apr 2026 22:37:33 +0000

Reduce Your Bundle Size with Effective Tree Shaking

Modern JavaScript bundlers are smart—but they’re not mind readers. If you want smaller production bundles, you need to structure your code in a way that makes unused code easy to remove.

What actually makes tree shaking work?

Tree shaking relies on static analysis. That means your code has to be predictable and explicit so the bundler can safely eliminate what’s not used.

Here are the fundamentals:

1. Stick to ES Modules

Use import / export syntax so the bundler can analyze dependencies at build time.

import { fetchData } from "./api";

export const load = () => fetchData();

Avoid CommonJS where possible:

const { fetchData } = require("./api");

This pattern makes it harder for bundlers to optimize.

Be precise with imports

Pulling in an entire library when you only need one function is one of the fastest ways to bloat your bundle.

// ❌ Pulls in everything
import _ from "lodash";

const result = _.debounce(fn, 300);
// ✅ Only what you need
import { debounce } from "lodash-es";

const result = debounce(fn, 300);
// ✅ Even more direct
import debounce from "lodash-es/debounce";

const result = debounce(fn, 300);

Declare side effects explicitly

Bundlers avoid removing files that might cause side effects. You can help them by clarifying this in package.json:

{
  "sideEffects": false
}

⚠️ Be careful: if your code includes things like global styles, polyfills, or initialization logic, marking everything as side-effect-free can break your app.

Prefer named exports in reusable code

Named exports give bundlers clearer signals about what’s being used.

export const Card = () => {};
export const Tooltip = () => {};

Then import only what you need:

import { Card } from "@/components/ui";

Don’t guess—inspect your bundle

Instead of assuming optimizations are working, analyze the output.

Install analyzer

npm install --save-dev webpack-bundle-analyzer

Example setup

const { BundleAnalyzerPlugin } = require("webpack-bundle-analyzer");

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: "static",
      openAnalyzer: false,
      reportFilename: "report.html",
    }),
  ],
};

Build and review

npm run build

Open the generated report and look for unexpectedly large modules.

Common hidden bundle killers

Here are issues that often show up in real projects:

・Heavy date libraries used for simple formatting
・Importing entire icon packs instead of individual icons
・Duplicate dependencies caused by version mismatches
・Legacy browser polyfills that aren’t needed anymore
・Source maps accidentally included in production builds

Practical improvements
Replace heavy utilities

// Instead of a large library
import { format } from "date-fns";


const label = format(new Date(), "yyyy-MM-dd");

Limit icon imports

// ❌ Loads everything
import * as Icons from "lucide-react";
// ✅ Only what you use
import { Search, User } from "lucide-react";

Final thoughts

Tree shaking isn’t automatic magic—it’s a collaboration between your code and your tooling.

If you:

・write explicit imports
・structure exports clearly
・and verify your bundle output

you’ll consistently ship smaller, faster applications.