codeflow: Skill for Claude Code

You Might Not Need an Effect

Effects are an escape hatch from the React paradigm. They let components synchronize with external systems (network, browser DOM, third-party widgets, non-React code). If no external system is involved, removing the Effect typically simplifies the code and eliminates bugs.

Core Decision Tree

Before writing a useEffect, apply this checklist in order:

1. Can this be calculated during rendering? Compute it directly in the component body or with useMemo.
2. Is this in response to a user event? Put the logic in the event handler, not an Effect.
3. Does state need to reset when a prop changes? Use a key on the component or compute derived values.
4. Is this a chain of state updates? Consolidate into one event handler.
5. Is this notifying a parent or passing data upward? Lift the state or call the parent callback from the event handler.
6. Is this app initialization that should run once? Use a module-level guard or run before rendering.
7. Is this synchronizing with an external system? This is a valid Effect. Include proper cleanup.

Anti-Patterns to Eliminate

Derived State in Effects

Never store computed values in state and sync them with an Effect. Calculate during render.

// BAD
const [fullName, setFullName] = useState("");
useEffect(() => {
  setFullName(firstName + " " + lastName);
}, [firstName, lastName]);

// GOOD
const fullName = firstName + " " + lastName;

For expensive computations, use useMemo instead of state + Effect.

User Event Logic in Effects

Logic that runs because a user did something belongs in the event handler — not in an Effect triggered by state the handler set.

// BAD: shows notification on page load if item already in cart
useEffect(() => {
  if (product.isInCart) showNotification("Added!");
}, [product]);

// GOOD: shows notification only when user clicks buy
function handleBuyClick() {
  addToCart(product);
  showNotification("Added!");
}