[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog.$slug",{"_7":8,"_9":10,"_11":12},"meta",{"_25":26,"_27":28,"_29":30,"_31":32},"en",{"_13":21,"_15":22,"_17":23,"_19":24},"pl",{"_13":14,"_15":16,"_17":18,"_19":20},"title","Pułapka useMemo, o której mało kto mówi","description","Kiedy memoizacja szkodzi więcej niż pomaga — krótki wpis o zbędnym useMemo w React.","content","## Domyślny instynkt\n\nWielu developerów owija każdą obliczoną wartość w `useMemo`. Instynkt jest zrozumiały: dokumentacja React wspomina o memoizacji przy kosztownych obliczeniach.\n\nAle nie każde obliczenie jest kosztowne. Samo `useMemo` też ma cenę.\n\n## Prosty przykład\n\n```tsx\nfunction UserList({ users }: { users: User[] }) {\n const sorted = useMemo(\n () => [...users].sort((a, b) => a.name.localeCompare(b.name)),\n [users]\n );\n\n return (\n

{user.name}

\n );\n}\n```\n\nDla listy 20 użytkowników sortowanie jest tanie. Wywołanie `useMemo` dodaje:\n\n- Porównywanie zależności przy każdym renderze\n- Dodatkowy narzut poznawczy przy czytaniu kodu\n\n## Kiedy useMemo naprawdę pomaga\n\nSięgnij po `useMemo`, gdy:\n\n1. Obliczenie jest **mierzalnie kosztowne** (duże zbiory danych, ciężkie transformacje)\n2. Wartość trafia do **memoizowanego dziecka**, które inaczej by się niepotrzebnie re-renderowało\n3. Potrzebujesz **stabilności referencji** dla tablicy zależności gdzie indziej\n\n## Zasada kciuka\n\nZacznij bez `useMemo`. Dodawaj go dopiero, gdy profilowanie pokaże realny problem — nie dlatego, że „best practices\" każą.\n\n> Przedwczesna memoizacja to źródło zła — albo przynajmniej mylącego kodu React.","html","

Domyślny instynkt

Wielu developerów owija każdą obliczoną wartość w useMemo. Instynkt jest zrozumiały: dokumentacja React wspomina o memoizacji przy kosztownych obliczeniach.

Ale nie każde obliczenie jest kosztowne. Samo useMemo też ma cenę.

Prosty przykład

function UserList({ users }: { users: User[] }) {\n  const sorted = useMemo(\n    () => [...users].sort((a, b) => a.name.localeCompare(b.name)),\n    [users]\n  );\n \n  return (\n    <ul>\n      {sorted.map((user) => (\n        <li key={user.id}>{user.name}</li>\n      ))}\n    </ul>\n  );\n}

Dla listy 20 użytkowników sortowanie jest tanie. Wywołanie useMemo dodaje:

Porównywanie zależności przy każdym renderze
Dodatkowy narzut poznawczy przy czytaniu kodu

Kiedy useMemo naprawdę pomaga

Sięgnij po useMemo, gdy:

Obliczenie jest mierzalnie kosztowne (duże zbiory danych, ciężkie transformacje)
Wartość trafia do memoizowanego dziecka, które inaczej by się niepotrzebnie re-renderowało
Potrzebujesz stabilności referencji dla tablicy zależności gdzie indziej

Zasada kciuka

Zacznij bez useMemo. Dodawaj go dopiero, gdy profilowanie pokaże realny problem — nie dlatego, że „best practices\" każą.

\n
Przedwczesna memoizacja to źródło zła — albo przynajmniej mylącego kodu React.
\n

","The useMemo trap nobody talks about","When memoization hurts more than it helps — a quick look at unnecessary useMemo in React.","## The default instinct\n\nMany developers wrap every computed value in `useMemo`. The instinct is understandable: React docs mention memoization for expensive calculations.\n\nBut not every calculation is expensive. And `useMemo` itself has a cost.\n\n## A simple example\n\n```tsx\nfunction UserList({ users }: { users: User[] }) {\n const sorted = useMemo(\n () => [...users].sort((a, b) => a.name.localeCompare(b.name)),\n [users]\n );\n\n return (\n

{user.name}

\n );\n}\n```\n\nFor a list of 20 users, sorting is cheap. The `useMemo` call adds:\n\n- Dependency comparison on every render\n- Extra mental overhead when reading the code\n\n## When useMemo actually helps\n\nReach for `useMemo` when:\n\n1. The calculation is **measurably expensive** (large datasets, heavy transforms)\n2. The value is passed to a **memoized child** that would otherwise re-render unnecessarily\n3. You need **referential stability** for a dependency array elsewhere\n\n## Rule of thumb\n\nStart without `useMemo`. Add it only when profiling shows a real problem — not because \"best practices\" say so.\n\n> Premature memoization is the root of all evil — or at least of confusing React code.","

The default instinct

Many developers wrap every computed value in useMemo. The instinct is understandable: React docs mention memoization for expensive calculations.

But not every calculation is expensive. And useMemo itself has a cost.

A simple example

function UserList({ users }: { users: User[] }) {\n  const sorted = useMemo(\n    () => [...users].sort((a, b) => a.name.localeCompare(b.name)),\n    [users]\n  );\n \n  return (\n    <ul>\n      {sorted.map((user) => (\n        <li key={user.id}>{user.name}</li>\n      ))}\n    </ul>\n  );\n}

For a list of 20 users, sorting is cheap. The useMemo call adds:

Dependency comparison on every render
Extra mental overhead when reading the code

When useMemo actually helps

Reach for useMemo when:

The calculation is measurably expensive (large datasets, heavy transforms)
The value is passed to a memoized child that would otherwise re-render unnecessarily
You need referential stability for a dependency array elsewhere

Rule of thumb

Start without useMemo. Add it only when profiling shows a real problem — not because \"best practices\" say so.

\n
Premature memoization is the root of all evil — or at least of confusing React code.
\n

","slug","use-memo-trap","date","2026-07-08","published",true,"tags",[33,34,35],"react","hooks","performance"]