Why Derived State in React Is Not Always an Anti-pattern

May 22, 2022

If you've spent any time around React developers, you've likely heard the maxim: "Derived state is an anti-pattern." While generally sound advice, treating it as absolute truth can lead to overly complicated solutions. Let's explore when derived state can actually simplify your React components and why it's not inherently evil.

Understanding Derived State

Derived state refers to state values computed directly from props or other state variables. The React docs rightly caution against derived state when it duplicates state or can lead to synchronization issues:

function MyComponent({ initialCount }) {
  const [count, setCount] = useState(initialCount);

  // Derived state anti-pattern
  const [doubleCount, setDoubleCount] = useState(count * 2);
}

The above example is indeed problematic, as keeping doubleCount in sync with count introduces unnecessary complexity.

When Derived State is Beneficial

However, there are cases where derived state isn't just acceptable; it's preferable:

1. Memoizing Expensive Computations

When calculating a value is computationally expensive, deriving and memoizing it can enhance performance:

const sortedItems = useMemo(() => {
  return items.slice().sort((a, b) => a.localeCompare(b));
}, [items]);

This isn't redundant state—it's derived, optimized computation.

2. Maintaining UI Consistency

Consider UI states like expanded or collapsed views. These are inherently derived from state or props but may be stored internally to maintain consistent interactions:

const [isExpanded, setExpanded] = useState(false);

useEffect(() => {
  if (items.length === 0) setExpanded(false);
}, [items.length]);

Here, derived state ensures intuitive UI behavior without external complexity. Derived state helps in this scenario by automatically syncing the UI state (isExpanded) with the data (items.length). When the data no longer supports the expanded view (e.g., no items to display), derived state simplifies ensuring the UI accurately represents this situation. Without derived state, you'd have to manage multiple checks manually, potentially causing inconsistent or unintuitive UI behaviors.

3. Complex Interaction Logic

Sometimes interaction logic naturally fits derived state, especially when multiple state variables determine the UI:

const isFormValid = useMemo(() => {
  return email.includes('@') && password.length > 8;
}, [email, password]);

Storing isFormValid as state here is unnecessary; deriving it simplifies and clarifies the intent.

The Nuance is in the Intention

The real takeaway is not that derived state is always bad, but that duplicated state is. Ask yourself:

  • Does this derived state make my component simpler?
  • Does it optimize performance without introducing synchronization headaches?

If yes, it's not an anti-pattern—it's thoughtful React design.

Conclusion

Derived state in React isn't a universal evil. Recognizing when it's beneficial helps create cleaner, simpler, and more maintainable components. Don't shy away from derived state entirely—use it intentionally and wisely.