Deep Equal - zrozumienie głębokiego porównania

Deep equal (porównanie głębokie) to porównywanie obiektów i tablic przez rekurencyjne zestawienie wartości, a nie referencji: { a: 1, b: 2 } jest głęboko równe { a: 1, b: 2 }, choć operator === zwróci false, bo to dwa różne obiekty w pamięci. Typowe zastosowania: testy (porównanie wyniku z oczekiwaniem), zarządzanie stanem (wykrywanie zmian), memoizacja (unieważnianie cache przy zmianie wejść) i diffowanie obiektów. Standardowe narzędzia to _.isEqual z Lodasha, szybszy fast-deep-equal i matcher toEqual w Jeście.

Operator === porównuje referencje: dwa obiekty są „równe" tylko wtedy, gdy to dosłownie ten sam obiekt w pamięci. Shallow equal porównuje wyłącznie pierwszy poziom właściwości — {a: 1, b: {c: 2}} i jego kopia wypadną nierówno, bo zagnieżdżone b to inne referencje. Deep equal schodzi rekurencyjnie w głąb: ta sama struktura i wartości oznaczają równość. Praktyczne konsekwencje: React.memo domyślnie porównuje płytko, Jest w toEqual głęboko, a zdziwienie juniora, „czemu === nie działa dla obiektów", to rytuał przejścia — różnica między równością referencji a wartości to fundament języka.

Standardowy zestaw:

• Lodash _.isEqual — najpopularniejszy wybór ogólnego przeznaczenia, poprawnie obsługuje daty, mapy, sety i referencje cykliczne,
• fast-deep-equal — szybszy przy prostych strukturach,
• Node.js assert.deepStrictEqual,
• Jest — expect(actual).toEqual(expected) wbudowane w testy,
• React.memo z własną funkcją porównującą, gdy potrzeba głębokiego porównania propsów.

Nowoczesną alternatywą bywa odwrócenie problemu: niemutowalne aktualizacje (Immer, Redux Toolkit) sprawiają, że wystarczy błyskawiczne porównanie referencji. Własnych implementacji lepiej unikać — przypadki brzegowe mszczą się miesiącami.

Typowe scenariusze:

• testy — toEqual w Jeście porównuje głęboko domyślnie,
• selektory Reduxa — memoizacja przy złożonym stanie,
• optymalizacja Reacta — własne porównanie w React.memo,
• formularze — czy wartości zmieniły się względem początkowych (dirty state),
• diffowanie obiektów — co konkretnie się zmieniło,
• cache odpowiedzi API — to samo żądanie, ta sama odpowiedź.

Zasada umiaru: głębokie porównanie dużych struktur kosztuje, więc tam, gdzie się da, lepiej projektować stan niemutowalnie i porównywać referencje.

Najważniejsze:

• wydajność — koszt rośnie z liczbą właściwości; głębokie porównania wielkich obiektów potrafią mulić aplikację,
• referencje cykliczne — obiekt wskazujący sam na siebie zapętli naiwną implementację (Lodash sobie radzi),
• typy specjalne — Date, Map, Set, RegExp traktowane różnie w różnych bibliotekach,
• funkcje — porównywalne tylko przez referencję,
• undefined kontra brak właściwości — { a: undefined } i {} bywają równe lub nie, zależnie od biblioteki,
• nadużycie w React.memo — głębokie porównanie propsów bywa wolniejsze niż re-render.

Rekomendacja: wzorce niemutowalne jako domyślne, deep equal jako narzędzie ostatniej szansy.