Frontend

The Three-Hook Pattern That Keeps React UIs Responsive During Heavy Computation

By Jasper_L · Aug 7, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Any React app that does client-side data processing, image manipulation, or cryptographic work will freeze the UI without this pattern. The three-hook coordination is the minimal correct recipe for Web Workers in React, and getting the cleanup wrong leaks threads that keep consuming memory until the tab closes.

Summary

JavaScript's single-threaded runtime freezes the entire page during a long-running loop. Web Workers run scripts on a separate OS thread, but managing their lifecycle inside React requires coordinating three hooks. useRef holds a persistent reference to the Worker instance across re-renders without triggering updates. useEffect creates the Worker on mount and calls terminate() on unmount to prevent memory leaks. useState drives the UI, disabling a button during computation and displaying the result when the Worker posts back. The demo runs a half-million-iteration calculation in the background while the page remains scrollable and responsive.

The communication model is pure message-passing: the main thread calls postMessage, the Worker's onmessage handler runs the loop, and the Worker posts the result back. Workers have no access to the DOM, window, or document, so all UI updates happen in the main thread's onmessage callback via setState. The pattern is deterministic: mount creates the Worker, unmount destroys it, and every render sees the same ref object.

Takeaways

— Running a 500,000-iteration loop on the main thread freezes the entire page; moving it to a Web Worker keeps scrolling and clicks responsive.

— useRef holds the Worker instance across renders because its .current property is mutable and does not trigger re-renders.

— useEffect creates the Worker on mount and returns a cleanup function that calls worker.terminate() to prevent memory leaks.

— useState manages loading and result states so the button disables during computation and the result appears when the Worker posts back.

— Workers communicate exclusively via postMessage and onmessage; they cannot access the DOM, window, or document.

— Using new URL('./work.js', import.meta.url) ensures Vite correctly resolves and bundles the Worker file.

Conclusions

The three-hook pattern is effectively a resource lifecycle manager: useRef for stable identity, useEffect for setup and teardown, useState for reactivity. This same structure applies to any external resource that outlives a single render — WebSockets, observers, or WASM instances.

Storing a Worker instance in useState is a common mistake because it causes unnecessary re-renders and risks losing the reference on state updates. useRef is the correct choice precisely because it sidesteps React's reactivity system for values that don't belong to the UI.

The cleanup function in useEffect is not optional for Workers. A terminated Worker frees its thread; an unterminated one persists until the tab closes, which matters in single-page apps where components mount and unmount frequently.

Concepts & terms

Web Worker

A browser API that runs JavaScript on a separate OS thread, communicating with the main thread via postMessage and onmessage. Workers cannot access the DOM, window, or document.

useRef

A React Hook that returns a mutable object ({ current: ... }) which persists across renders. Changing .current does not trigger a re-render, making it suitable for holding references to DOM nodes, timers, or Worker instances.

useEffect cleanup function

The function returned from a useEffect callback runs when the component unmounts or before the effect re-runs. It is the correct place to call worker.terminate(), clearInterval, or remove event listeners.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗