Your React UI May Be Buggy Because It Remembers Too Much

I started thinking about this differently while building interfaces where the same underlying information appeared in several forms.

A list of links existed. Then there was a filtered version of that list. Then the number of filtered results. Then the currently selected item. Then flags derived from those values.

Individually, every state variable looked reasonable. Together, they created several representations of the same truth. And that is where seemingly random UI bugs begin.

The Pattern Looked Harmless

Imagine a simplified links interface:

const [links, setLinks] = useState<Link[]>([]);
const [searchQuery, setSearchQuery] = useState("");
const [selectedCategory, setSelectedCategory] =
  useState<string | null>(null);

const [filteredLinks, setFilteredLinks] = useState<Link[]>([]);
const [filteredCount, setFilteredCount] = useState(0);
const [selectedLink, setSelectedLink] = useState<Link | null>(null);
const [isEmpty, setIsEmpty] = useState(false);

Nothing here immediately screams bad architecture. Every variable represents something visible in the UI. That is exactly the trap.

filteredLinks is not actually new information. Neither is filteredCount. Neither is isEmpty. They are consequences of information the component already has.

Store the Minimum. Derive the Rest.

Instead of asking where to store a value, I try to ask an earlier question: does the UI need to remember this at all?

const [searchQuery, setSearchQuery] = useState("");
const [selectedCategory, setSelectedCategory] =
  useState<string | null>(null);
const [selectedLinkId, setSelectedLinkId] =
  useState<string | null>(null);

const filteredLinks = links.filter((link) => {
  const matchesQuery = link.title
    .toLowerCase()
    .includes(searchQuery.toLowerCase());

  const matchesCategory =
    !selectedCategory || link.categoryId === selectedCategory;

  return matchesQuery && matchesCategory;
});

const filteredCount = filteredLinks.length;
const selectedLink =
  links.find((link) => link.id === selectedLinkId) ?? null;
const isEmpty = filteredLinks.length === 0;

There is no synchronization effect. There is nothing to keep aligned. Whenever the source values change, React renders again and calculates the current answer from the current inputs.

Five Homes for UI Information

useEffect Is Often Where the Smell Becomes Visible

useEffect is not the problem. Effects are essential when React needs to synchronize with something outside React: DOM APIs, browser APIs, subscriptions, timers, network connections, or third-party libraries.

Is this effect connecting React to something external, or is it keeping my own state variables from disagreeing?

That question often reveals derived state hiding inside synchronization code.

How I Audit an Overloaded React Component

When a component starts becoming difficult to reason about, I do not immediately split it into smaller files. First I inspect its state model.

1. List every useState and write down what the component believes it must remember.
2. Mark values that can be calculated: counts, filtered lists, booleans, formatted strings, selected objects, and status labels.
3. Trace effects whose main job is A changed, so update B.
4. Find duplicated ownership across props, fetched data, context, stores, the URL, and other state variables.
5. Keep the smallest independent representation, then re-test create, delete, filter, search, select, clear filter, navigate, and refetch flows.

Derived State Is Not Always Wrong

A form might initialize from server data and then become an independent draft. An editor may preserve a historical snapshot. An optimistic interface might temporarily maintain a local version while a mutation is pending.

The distinction is ownership. If the UI intentionally creates a new version of information with its own lifecycle, state can make sense. What I want to avoid is accidental duplication because another copy felt convenient.