Why ReactUse doesn't memoize hook methods by default

ReactUse deliberately avoids memoizing hook methods by default. That is not an oversight or a missing layer of polish. It is a product decision: memoization is an optimization technique, and optimizations work best when the application developer applies them to a real bottleneck with local context.

Library philosophy

Hooks should give you useful state, callbacks, and helpers without hiding the behavior of your component tree. If every method returned by every hook were automatically wrapped in memoization, the library would start making performance decisions for code it cannot see.

That sounds convenient at first, but it can quickly become misleading:

• It can hide architectural issues instead of helping you find the component boundary or state shape that actually causes unnecessary work.
• It can create a false sense of security because a memoized function does not mean the surrounding UI is optimized.
• It can make debugging harder when identities stay stable until a dependency changes in a way that is no longer obvious from the call site.

ReactUse keeps those choices visible. The hook gives you the primitive; your component decides whether a value or callback needs stable identity.

Optimize when there is a reason

Donald Knuth's old warning still fits React code: premature optimization tends to make systems harder to understand before it makes them faster.

Re-renders are normal in React. Modern React and modern browsers handle many of them comfortably, and a render is not automatically a performance problem. The meaningful question is whether a specific render path is expensive, repeated too often, or passing unstable identities into memoized children.

When that is true, memoize right where the reason exists:

Copyimport { useCallback, useMemo } from 'react';
import { useCounter } from '@siberiacancode/reactuse';
 
export const Component = () => {
  const counter = useCounter(0);
 
  const expensiveValue = useMemo(() => performHeavyCalculation(counter.value), [counter.value]);
 
  const handleIncrement = useCallback(() => {
    performHeavyOperation();
    counter.inc();
  }, [counter.inc]);
 
  // ...
};

This keeps the optimization attached to the expensive calculation or the identity-sensitive callback. The dependency list lives next to the code that needs it, which makes future changes easier to review.

Memoization belongs to the app

A library can know the shape of its own API, but it cannot know whether your component tree benefits from stable function identity. One component may pass a callback to a memoized child; another may call it directly from an event handler; a third may replace the whole feature boundary next week.

Those cases should not all pay the same complexity cost.

ReactUse treats memoization as an application-level decision because the app has the missing context:

• where expensive work actually happens;
• which children are memoized;
• which dependency changes are meaningful;
• whether stable identity improves anything measurable.

React Compiler

The React team has also been moving toward React Compiler, which can automatically optimize code by applying memoization where the compiler can prove it is useful. As that work becomes part of everyday React development, blanket library-level memoization becomes even less attractive.

The principle stays the same either way: optimize deliberately. Let ReactUse expose clear primitives, let your app own the performance boundary, and add memoization when there is a concrete reason to do it.