DEV Community: Darren Hwang

React Compiler and and the promise of automated memoization

Darren Hwang — Fri, 15 May 2026 00:55:27 +0000

The real-world impact of the React Compiler (formerly React Forget). The promise of this tool is to automate memoization, theoretically freeing developers from the manual overhead of useMemo, useCallback, and React.memo.

The Problem: Manual Memoization

React re-renders are cascading; a change in a parent component triggers a re-render for all children unless stopped by memoization. Manually implementing this is often complex and leads to:

Referential instability: Objects and functions recreated on every render.
"Prop drilling" complexity: Tracing memoization through long component chains.
Messy code: Over-use of hooks making the codebase unreadable.

The Compiler's Performance

1. Initial Load Performance

One major concern was that memoizing "everything" would bloat the initial load. However, the tests showed minimal to no impact on initial load times. The compiler is efficient enough that the overhead is negligible.

2. Interaction Performance

The results here were mixed but generally positive:

Best Case: On a settings preview page, total blocking time dropped from 280ms to 0ms.
Realistic Case: On a gallery page, blocking time dropped from 130ms to 90ms. The compiler eliminated many re-renders, but some heavy components still re-rendered due to unstable data references from external libraries (like React Query).

3. Can it catch everything?

No. The investigation found the compiler failed to stop all re-renders in 7 out of 9 complex cases. Reasons include:

Incompatibility with certain external libraries.
Legacy code structures the compiler doesn't yet understand.
Non-primitive props (objects/arrays) that change references outside of the component's scope.

React 18 Vs React 19

React 18 made rendering smarter. React 19 improves performance more by reducing work the browser has to do, loading resources earlier, and making async updates feel faster.

However, you have to opt-in to these improvements. It’s not that every render is magically faster; the biggest gains come from using the new React 19 patterns.

React Compiler is often discussed with modern React because it can automatically memoize components and reduce unnecessary re-renders, but simply upgrading to React 19 does not automagically mean your app is using the compiler; it must be configured in your build setup.

1. Less JavaScript sent to the browser

React 19 stabilizes Server Components, which let parts of your UI run on the server or at build time instead of in the browser. That means the user may download less JavaScript, parse less code, and see content sooner. React’s docs give an example where expensive markdown libraries are not included in the client bundle when moved into a Server Component. react.dev/react-19

Simple analogy:
React 18 often ships more of the “kitchen” to the customer. React 19 can cook more on the server and only send the finished meal.

2. Better loading of CSS, scripts, fonts, and other resources

React 19 adds better support for things like stylesheets, async scripts, and preload/preconnect APIs. This helps the browser discover important files earlier and avoid duplicated scripts or styles. React’s release notes specifically say these resource APIs can improve initial page loads and client-side navigations. react.dev/react-19

React 19 gives you direct APIs (preload, preconnect, preinit) to hint to the browser which fonts, scripts, or pages the user might need next. This makes navigation feel almost instant because resources are fetched ahead of time as soon as someone hovers over a link .

Simple example:
Instead of waiting until a component appears to discover its font or script, React can help the browser start fetching it earlier.

3. Smoother forms and async updates

React 19 adds Actions, useActionState, useFormStatus, and useOptimistic. These don’t necessarily make the CPU faster, but they make the app feel faster because React can show pending states and optimistic UI more naturally. For example, useOptimistic can immediately show the expected result while the server request is still running. react.dev/react-19

Simple example:
You click “Save,” and the UI updates right away instead of waiting for the server to respond.

4. Better Suspense/data handling with use

React 19’s use API lets components read promises during render and suspend until data is ready. Used with Suspense and frameworks, this can help avoid awkward loading flows and make async rendering more coordinated. react.dev/react-19

Simple version:
React gets better at saying, “Pause this part until the data is ready, but keep the rest of the page moving.”

5. More resilient hydration

Hydration is when React connects server-rendered HTML to interactive JavaScript in the browser. The initial hand‑off from server HTML to an interactive client app (hydration) is now twice as fast, meaning your app becomes usable much quicker after the page load. React 19 improves how hydration handles unexpected tags from third-party scripts or browser extensions, reducing cases where React has to throw away server HTML and re-render on the client. react.dev/react-19

Why that matters:
Less unnecessary re-rendering means fewer janky page loads.

6. Faster JSX transform requirement

React 19 requires the modern JSX transform, which React says enables additional improvements including JSX speed improvements and faster performance. react.dev/react-19

7. An automatic “memoization” compiler

In React 18, developers had to manually wrap things in useMemo or useCallback to avoid unnecessary re-renders. React 19 now includes a smart compiler that analyzes your components and handles this automatically—so you get fewer re-renders and snappier UIs without the extra boilerplate.

8. Concurrent rendering that just works

React 18 introduced concurrent rendering but you had to opt in with things like useTransition. React 19 makes this automatic—it instantly prioritizes urgent tasks (like typing or clicking) over less critical background work (like filtering a huge list), so the UI always feels responsive and never freezes.

Important caveat

React 19 is not simply “React 18 but every render is faster.” React 18 already introduced major performance features like automatic batching, transitions, and streaming server rendering. (react.dev) React 19’s performance benefits mostly come when you use its newer architecture: Server Components, better resource loading, Actions, Suspense patterns, and modern tooling.

Again, React Compiler is often discussed with modern React because it can automatically memoize components and reduce unnecessary re-renders, but simply upgrading to React 19 does not automagically mean your app is using the compiler; it must be configured in your build setup. (react.dev)

Bottom line:

React 18 made updates smoother. React 19 helps apps load less, fetch smarter, hydrate more reliably, and feel faster during async work.

⚠️
While the React Compiler is a massive step forward, developers seeking to squeeze every millisecond of performance out of their apps will still need to understand and occasionally implement manual memoization.

[Boost]

Darren Hwang — Sun, 10 May 2026 01:17:21 +0000

Darren Hwang

May 10

Preventing unnecessary re-renders using React.memo, useMemo and useCallback hooks

#javascript #performance #react #webdev

Comments 4

3 min read

Preventing unnecessary re-renders using React.memo, useMemo and useCallback hooks

Darren Hwang — Sun, 10 May 2026 01:11:10 +0000

Preventing unnecessary re-renders in React is crucial for maintaining performance, especially in complex component trees. Here is a comprehensive summary of the key concepts, focusing on React.memo and related hooks.

The Problem with Re-renders

When a parent component re-renders, its children automatically re-render as well. In large-scale applications, this default behavior can create noticeable performance bottlenecks.

There are four primary reasons why a component will re-render itself, along with one common misconception.

1. State Changes

This is the "root" source of all re-renders. When a component’s state is updated (typically via useState or useReducer), the component triggers a re-render to reflect the new data.

Trigger: Usually happens inside event callbacks or useEffect hooks.

2. Parent Re-renders

If a parent component re-renders, React will automatically re-render all of its children.

Direction: The render cycle always flows "down" the tree. A child re-rendering does not naturally trigger a parent re-render unless it invokes a state change in that parent.

3. Context Changes

When the value provided by a Context.Provider changes, every component consuming that context will re-render.

Note: This occurs even if the component only utilizes a portion of the data that didn't change. These re-renders cannot be prevented with simple memoization.

4. Hook Changes

Since everything inside a custom hook belongs to the component utilizing it, standard rules for state and context apply:

A state change inside a hook triggers a re-render of the "host" component.
If a hook consumes a Context that changes, the "host" component re-renders.

⛔ The "Props Change" Myth

A prevalent misconception is that a component re-renders because its props changed. In reality, for props to change, the parent must re-render first.

If a component is not memoized, it will re-render when its parent does, regardless of whether the props are identical or entirely different.
Props only become the deciding factor for a re-render when using memoization techniques like React.memo.

Component Re-render Triggers

Trigger	Description
State	The component's internal `useState` or `useReducer` was updated.
Parent	The component's parent is re-rendering.
Context	A `useContext` value the component subscribes to has changed.
Hooks	A state or context change occurred inside a hook used by the component.

Using React.memo

React.memo is a higher-order component that memoizes a child component. It intercepts the default behavior and prevents re-renders if the component's incoming props have not changed.

The Pitfall: Referential Equality

React.memo relies on shallow comparison. Objects can cause unintended re-renders because of how React compares props—specifically through referential equality.

Referential Equality: For primitive values (strings, numbers, booleans), React compares the actual value. However, for objects, arrays, and functions, it compares the memory reference.
New References on Render: Every time a parent component re-renders, any prop defined inline (e.g., user={{ id: 1 }}) is recreated as a brand-new object in memory.
The Effect: Because this new object has a different reference than the one from the previous render, React assumes the prop has changed. Even if the child is wrapped in React.memo, it will ignore the memoization and re-render because the shallow comparison returns false.

The Solution: `useMemo` and `useCallback`

To prevent this broken memoization, you must preserve the object or function's reference across re-renders.

Use the useMemo hook to cache objects and arrays.
Use the useCallback hook to cache functions.

Custom Comparison

Similar to the legacy shouldComponentUpdate lifecycle method in class components, you can pass a custom comparison function as the second argument to React.memo. This allows you to define the exact logic for when a component should update.

Best Practices

Optimization should always be a "last resort." Prioritize solid component composition techniques first (like moving state down or passing elements as children). Composition is generally more predictable and maintainable than adding complex layers of memoization hooks.

Based on the React re-renders guide.

requestAnimationFrame vs requestIdleCallback

Darren Hwang — Mon, 06 Apr 2026 18:41:02 +0000

The primary difference between (rAF) and (rIC) is priority and timing within the browser's event loop.
Key Differences

Feature	(rAF)	(rIC)
Priority	High: Critical for visual updates.	Low: Non-critical background tasks.
Timing	Executes before the next repaint/refresh.	Executes during idle periods at the end of a frame.
Frequency	Matches display refresh rate (usually 60Hz).	Unpredictable; depends on CPU availability.
Best For	Animations, UI transitions, and DOM changes.	Analytics, background data processing, or logging.
Browser Support	Universal support across all modern browsers.	Not supported in Safari; experimental in others.

Detailed Comparison

requestAnimationFrame

• Synchronization: It synchronizes your code with the browser's V-Sync, ensuring that visual changes happen exactly once per frame to prevent "jank" or screen tearing.
• Power Efficiency: If the tab is backgrounded or hidden, the browser automatically pauses rAF calls to save battery and CPU.
• Usage: Ideal for any task that modifies the DOM or CSS styles for visual feedback.

requestIdleCallback

• Idle Deadline: It provides a object with a method, allowing you to check how many milliseconds are left before the browser needs to process higher-priority tasks.
• Guaranteed Execution: You can pass an optional (e.g., ) to force the browser to run the task even if it never becomes idle.
• Restrictions: You should not modify the DOM inside rIC, as it occurs after the frame's layout and paint phases; doing so can cause expensive reflows in the next frame.

When to use which?

• Use requestAnimationFrame when you need to update the UI or perform an animation.
• Use requestIdleCallback for background tasks like sending telemetry, pre-fetching data, or non-urgent state calculations that shouldn't interrupt user interaction.

rAF, rIC and Deferred Value

Use requestAnimationFrame (rAF) or requestIdleCallback (rIC) serve different performance goals compared to the built-in useDeferredValue hook. [1]

Choosing the Right API

• requestAnimationFrame (rAF): Best for visual synchronization. It ensures the value updates just before the next browser repaint (typically every 16.67ms), preventing visual stuttering during high-frequency updates like scrolling or resizing.
• requestIdleCallback (rIC): Best for non-urgent background work. It waits until the browser is completely idle before updating the value, which avoids interfering with critical user interactions like typing.
• useDeferredValue (React Built-in): If you are on React 18+, this is usually superior because it integrates with React's Concurrent Mode. It schedules a low-priority background render that is interruptible if a new update occurs. [2, 3, 4, 5, 6, 7]

Implementation Guidelines

When implementing these in a custom hook, follow these patterns to ensure stability:

• Use for IDs: Store the request ID returned by rAF/rIC in a useRef to track and cancel it during cleanup.
• Cleanup on Unmount: Always return a cleanup function in to call or to prevent memory leaks and "ghost" state updates.
• Throttle State Updates: Be cautious with state updates inside these callbacks. High-refresh-rate displays (120Hz+) can trigger rAF more frequently than needed, potentially causing performance overhead if not throttled.
• Browser Compatibility: While rAF is widely supported, requestIdleCallback is not supported in all browsers (e.g., older Safari versions). Use a polyfill or a fallback for production apps. [3, 8, 9, 10, 11, 12]

let fps = 30;
let lastTime = 0;

function animate(currentTime) {
  requestAnimationFrame(animate);

  const delta = currentTime - lastTime;
  if (delta < 1000 / fps) return; // Skip frame if too early

  lastTime = currentTime - (delta % (1000 / fps));
  // Perform throttled work
}
requestAnimationFrame(animate);

Summary Comparison

Feature
Primary Goal	Smooth animations/visuals	Background/Low-priority tasks	Non-blocking UI updates
Execution Timing	Before next repaint	During browser idle time	React's idle time (interruptible)
Best For	Position/Layout updates	Analytics, heavy data processing	Expensive list rendering
React Integration	Manual (via )	Manual (via )	Native (Concurrent Mode)

[1] https://layonez.medium.com/performant-animations-with-requestanimationframe-and-react-hooks-99a32c5c9fbf
[2] https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame
[3] https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
[4] https://en.blog.jasonzk.com/js/requestidlecallback-and-requestanimationframe/
[6] https://www.youtube.com/watch?v=yIpHTYo3PY0
[10] https://dev.to/tawe/requestanimationframe-explained-why-your-ui-feels-laggy-and-how-to-fix-it-3ep2
[11] https://github.com/Chalarangelo/30-seconds-of-code/blob/master/content/snippets/react/s/use-request-animation-frame.md
[12] https://css-tricks.com/using-requestanimationframe-with-react-hooks/
[13] https://stackoverflow.com/questions/38709923/why-is-requestanimationframe-better-than-setinterval-or-settimeout
[14] https://medium.com/@ignatovich.dm/understanding-usedeferredvalue-in-react-enhancing-performance-with-deferred-rendering-ec8eb28aa997
[15] https://medium.com/zestgeek/understanding-reacts-usedeferredvalue-hook-a-comprehensive-guide-with-examples-f8aa3361ee23

[2] https://macarthur.me/posts/navigating-the-event-loop/
[3] https://developer.chrome.com/blog/using-requestidlecallback
[4] https://www.luisball.com/blog/request-animation-frame-versus-request-idle-callback
[5] https://stackoverflow.com/questions/61145102/using-requestanimationframe-inside-requestidlecallback
[6] https://powerfulyang.com/post/104
[7] https://andriii.hashnode.dev/windowrequestidlecallback-all-you-need-to-know
[10] https://www.clicktorelease.com/blog/calculating-fps-with-requestIdleCallback/
[11] https://andriii.hashnode.dev/requestanimationframe-all-you-need-to-know
[12] https://dev.to/sylwia-lask/9-things-youre-overengineering-the-browser-already-solved-them-o99
[13] https://dev.to/codewithrajat/boost-your-web-performance-mastering-javascript-scheduling-methods-56eh
[15] https://caniuse.com/requestidlecallback
[16] https://www.youtube.com/watch?v=oDYT2J5zNHc
[17] https://medium.com/imgcook/a-closer-look-at-react-fiber-b2ab072fcc2a
[18] https://www.youtube.com/watch?v=nect7xrF2go
[19] https://www.debugbear.com/blog/requestanimationframe
[20] https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/CSS_JavaScript_animation_performance

The most powerful pattern in TypeScript, Discriminated Unions

Darren Hwang — Mon, 06 Apr 2026 18:19:42 +0000

Discriminated Unions is useful in cases where you have a discriminant, which is a common property with a literal type (like 'idle', 'loading') that exists in every member.

TypeScript will narrow the type based on the discriminator, a common property to discriminate between union members. , making your code much safer.

type State = 
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'success'; data: string }
  | { status: 'error'; error: Error }

function handleState(state: State) {
  switch (state.status) {
    case 'idle':
      // TypeScript knows state is { status: 'idle' }
      break
    case 'loading':
      // TypeScript knows state is { status: 'loading' }
      break
    case 'success':
      // TypeScript knows state has 'data' property
      console.log(state.data.toUpperCase())
      break
    case 'error':
      // TypeScript knows state has 'error' property
      console.error(state.error.message)
      break
    default:
      const _exhaustive: never = status
      throw new Error(`Unhandled status: ${status}`)
  }
}

The most powerful patterns in TypeScript. Discriminated Unions allow you to create a type-safe state machine where the compiler ensures you only access data that actually exists in a given state.

Here is a breakdown of why this pattern is the gold standard for state management.

1. The Core Components

To create a Discriminated Union, you need three things:

The Members: Individual object types representing different states.
The Discriminant: A common property with a literal type (like 'idle', 'loading') that exists in every member.
The Union: A type that combines them using the | operator.

Example Anatomy

type State = 
  | { status: 'idle' } 
  | { status: 'loading' } 
  | { status: 'success'; data: string } // 'data' only exists here
  | { status: 'error'; error: Error };   // 'error' only exists here

2. Why It Beats "Optional Property" Hell

Without unions, developers often use one giant object with optional properties. This is dangerous because it allows for "impossible states."

The "Bad" Way (Optional Properties)	The "Good" Way (Discriminated Unions)
`data?: string; error?: Error;`	Data and Error are tied to specific statuses.
You could accidentally have both `data` and `error` at the same time.	The type system makes it impossible to have `data` while in an `error` state.
Requires constant null checks or "non-null assertions" (`!`).	TypeScript narrows the type automatically.

3. Type Narrowing in Action

As you showed in your post's switch statement, once you check the status property, TypeScript "narrows" the object to that specific member of the union.

function handleState(state: State) {
  if (state.status === 'success') {
    // Inside this block, TypeScript knows 'data' exists.
    // You don't need to check if state.data is undefined.
    console.log(state.data); 
  }
}

4. Exhaustiveness Checking

One of the best "pro tips" for state management is ensuring you've handled every possible state. You can use the never type to catch unhandled cases at compile time:

function handleState(state: State) {
  switch (state.status) {
    case 'idle': return 'Waiting...';
    case 'loading': return 'Loading...';
    case 'success': return state.data;
    case 'error': return state.error.message;
    default:
      // If you add a new state like 'processing' later, 
      // TypeScript will throw an error here because 'processing'
      // cannot be assigned to 'never'.
      const _exhaustiveCheck: never = state;
      return _exhaustiveCheck;
  }
}

Summary of Benefits

Safety: Prevents accessing data when the app is still loading.
Clarity: The code serves as documentation for what data is available when.
Maintainability: Adding a new state (e.g., reconnecting) triggers compiler errors in every function that hasn't accounted for it yet.

Learning CacheStorage

Darren Hwang — Thu, 12 May 2022 19:03:42 +0000

Just learned about CacheStorage, will try experiment with it. Seems promising

DEV Community: Darren Hwang

React Compiler and and the promise of automated memoization

The Problem: Manual Memoization

The Compiler's Performance

1. Initial Load Performance

2. Interaction Performance

3. Can it catch everything?

React 18 Vs React 19

1. Less JavaScript sent to the browser

2. Better loading of CSS, scripts, fonts, and other resources

3. Smoother forms and async updates

4. Better Suspense/data handling with use

5. More resilient hydration

6. Faster JSX transform requirement

7. An automatic “memoization” compiler

8. Concurrent rendering that just works

Important caveat

Bottom line:

[Boost]

Preventing unnecessary re-renders using React.memo, useMemo and useCallback hooks

Preventing unnecessary re-renders using React.memo, useMemo and useCallback hooks

The Problem with Re-renders

1. State Changes

2. Parent Re-renders

3. Context Changes

4. Hook Changes

⛔ The "Props Change" Myth

Component Re-render Triggers

Using React.memo

The Pitfall: Referential Equality

The Solution: useMemo and useCallback

Custom Comparison

Best Practices

requestAnimationFrame vs requestIdleCallback

Detailed Comparison

requestAnimationFrame

requestIdleCallback

When to use which?

rAF, rIC and Deferred Value

Choosing the Right API

Implementation Guidelines

Summary Comparison

The most powerful pattern in TypeScript, Discriminated Unions

1. The Core Components

Example Anatomy

2. Why It Beats "Optional Property" Hell

3. Type Narrowing in Action

4. Exhaustiveness Checking

Summary of Benefits

Further reading and references

Learning CacheStorage

The Solution: `useMemo` and `useCallback`