React developers who know when not to use React

TypeScript · src/components/InvoiceTable.tsx

The most common avoidable bug in React codebases, and the fix. Copying props into state and syncing with an effect means every change renders once with stale data before the effect corrects it — visible as a flicker, and the source of filters that reset themselves. Anything derivable from props and state is computed during render instead, which removes the effect, the duplicated state and the entire class of bug. Only genuine synchronisation with something outside React is left as an effect.

// Before: three pieces of state that are all the same information, kept in
// step by effects. Each render shows the old value first, then corrects it.
//
//   const [visible, setVisible] = useState(invoices);
//   const [total, setTotal] = useState(0);
//   useEffect(() => { setVisible(invoices.filter(matches)); }, [invoices, query]);
//   useEffect(() => { setTotal(visible.reduce(sum, 0)); }, [visible]);

export function InvoiceTable({ invoices }: { invoices: Invoice[] }) {
  // The only real state: what the user typed. Everything else follows from it.
  const [query, setQuery] = useState('');
  const [sort, setSort] = useState<SortKey>('dueOn');

  // Derived during render. No effect, no stale first paint, no flicker.
  const visible = useMemo(
    () => invoices.filter((i) => matches(i, query)).sort(by(sort)),
    [invoices, query, sort],
  );

  // useMemo is a performance hint, not correctness: this would still be right
  // computed inline. It is here because the list is long, which is a reason.
  const totalMinor = useMemo(
    () => visible.reduce((sum, i) => sum + i.totalMinor, 0),
    [visible],
  );

  // An effect that is genuinely one: synchronising with something outside
  // React, with a cleanup, rather than deriving state from other state.
  useEffect(() => {
    const title = document.title;
    document.title = `${visible.length} invoices — ${title}`;
    return () => { document.title = title; };
  }, [visible.length]);

  return <Table rows={visible} footerTotalMinor={totalMinor} onQuery={setQuery} />;
}

When React is the wrong tool

A content site with a contact form does not need React. It will be faster, cheaper, and easier to maintain as server-rendered HTML with a small amount of JavaScript. We would rather tell you that than bill for the framework. React earns its weight when there is real client-side state — an editor, a dashboard, a multi-step flow with live validation. If your interface is mostly reading, the framework is overhead you pay for on every page load.