useEffect to prawie zawsze błąd — kiedy go naprawdę potrzebujesz, a kiedy nie

useEffectuseEffect uruchamia kod po renderze komponentu i służy głównie do synchronizacji Reacta z systemami zewnętrznymi. to najczęściej nadużywany hook w React. W audytach kodu widzę regularnie, że 70–80% użyć useEffect nie powinno tam być — albo rozwiązują problem, który nie powinien istnieć, albo duplikują mechanizm, który React już daje w standardzie.

Sam zespół React wprost pisze w dokumentacji: „You might not need an Effect". Ale mentalny model „masz problem → użyj useEffect" jest tak zakorzeniony, że nawet doświadczeni developerzy sięgają po ten hook odruchowo. W tym artykule pokazuję siedem najczęstszych antywzorców i konkretne alternatywy.

Krótko — po co useEffect istnieje

useEffect ma jedno zadanie: synchronizacja Reacta z systemami spoza Reacta. Subscribe do WebSocketa, dodanie event listenera do window, manipulacja DOM-em, który jest poza kontrolą Reacta, integracja z third-party biblioteką jak Leaflet czy D3.

Wszystko inne — obliczenia na podstawie state'u, reakcja na event, pobranie danych z serwera, powiadomienie rodzica o zmianie — ma swoje lepsze alternatywy, które React 19 w większości przypadków oferuje out of the box.

Antywzorzec 1: Transformacja state'u w useEffect

// ŹLE
function Checkout({ items }) {
  const [total, setTotal] = useState(0);
 
  useEffect(() => {
    setTotal(items.reduce((sum, item) => sum + item.price, 0));
  }, [items]);
 
  return <p>Total: {total} zł</p>;
}

Ten pattern wydaje się naturalny — „mam listę itemów, muszę policzyć total, więc używam effect". Problem: powoduje dwa rendery dla każdej zmiany. Pierwszy render pokazuje stare total, potem effect odpala się, ustawia nowe total, drugi render pokazuje poprawną wartość. Migotanie, niepotrzebna praca Reacta.

// DOBRZE
function Checkout({ items }) {
  const total = items.reduce((sum, item) => sum + item.price, 0);
 
  return <p>Total: {total} zł</p>;
}

Wartości obliczone bezpośrednio w renderze to tzw. derived stateDerived state to wartość wyliczana z propsów lub state, której zwykle nie trzeba trzymać w osobnym stanie. — React automatycznie je przelicza przy każdej zmianie propsów/state'u. Z React Compilerem są automatycznie memoizowane.

Antywzorzec 2: Powiadamianie rodzica o zmianie

// ŹLE
function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);
 
  useEffect(() => {
    onChange(isOn);
  }, [isOn]);
 
  return <button onClick={() => setIsOn(!isOn)}>{isOn ? 'On' : 'Off'}</button>;
}

Wzorzec „zmieniam state, potem effect odpala callback do rodzica" jest klasycznym źródłem infinite loopów i niechcianych efektów przy pierwszym renderze (effect odpali się natychmiast z isOn = false, chociaż user niczego nie zrobił).

// DOBRZE — event handler wywołuje callback bezpośrednio
function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);
 
  const handleClick = () => {
    const next = !isOn;
    setIsOn(next);
    onChange(next);
  };
 
  return <button onClick={handleClick}>{isOn ? 'On' : 'Off'}</button>;
}

Jeśli state pochodzi od rodzica, jeszcze prościej:

// JESZCZE LEPIEJ — state w rodzicu
function Toggle({ isOn, onChange }) {
  return <button onClick={() => onChange(!isOn)}>{isOn ? 'On' : 'Off'}</button>;
}

Zasada: event to event, effect to effect. Jeśli user coś kliknął, logika idzie do handlera kliknięcia. Effect jest dla rzeczy, które dzieją się „bez udziału użytkownika" (timer, websocket, resize).

Antywzorzec 3: Resetowanie state'u gdy zmienia się prop

// ŹLE
function Profile({ userId }) {
  const [comment, setComment] = useState('');
 
  useEffect(() => {
    setComment('');  // reset po zmianie usera
  }, [userId]);
 
  return <textarea value={comment} onChange={e => setComment(e.target.value)} />;
}

Ten pattern znowu renderuje komponent dwukrotnie (najpierw ze starym commentem, potem z resetowanym). A rozwiązanie jest trywialne:

// DOBRZE — używamy key, żeby remount komponentu
function ProfilePage({ userId }) {
  return <Profile userId={userId} key={userId} />;
}
 
function Profile({ userId }) {
  const [comment, setComment] = useState('');  // reset automatyczny przy zmianie key
  return <textarea value={comment} onChange={e => setComment(e.target.value)} />;
}

key to potężne narzędzie — zmiana key mówi Reactowi „to jest nowa instancja komponentu, zresetuj cały state". Działa dla dowolnie skomplikowanego drzewa.

Antywzorzec 4: Fetching danych

// ŹLE (klasyczny wzorzec w dokumentacji Reacta sprzed 2022)
function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);
 
  useEffect(() => {
    let cancelled = false;
    setLoading(true);
 
    fetch(`/api/users/${userId}`)
      .then(res => res.json())
      .then(data => {
        if (!cancelled) {
          setUser(data);
          setLoading(false);
        }
      })
      .catch(err => {
        if (!cancelled) {
          setError(err);
          setLoading(false);
        }
      });
 
    return () => { cancelled = true; };
  }, [userId]);
 
  if (loading) return <Spinner />;
  if (error) return <Error error={error} />;
  return <Profile user={user} />;
}

Ten kod działa. Ale nie ma cache'owania, nie ma deduplikacji (jeśli trzy komponenty fetchują tego samego usera, dostajemy trzy requesty), nie ma retry, nie ma optimistic updates, nie obsługuje race conditions (user zmienia userId szybko — odpowiedzi mogą przyjść w złej kolejności).

// DOBRZE — TanStack Query
import { useQuery } from '@tanstack/react-query';
 
function UserProfile({ userId }) {
  const { data: user, isLoading, error } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetch(`/api/users/${userId}`).then(res => res.json()),
  });
 
  if (isLoading) return <Spinner />;
  if (error) return <Error error={error} />;
  return <Profile user={user} />;
}

Pięć linii kodu, dostajesz wszystko: cache, deduplikację, retry, background refetch, optimistic updates. Szczegółowo opisuję to w artykule o fetchingu danych w React.

W Server Components to jeszcze prostsze:

// JESZCZE LEPIEJ — async Server Component
async function UserProfile({ userId }: { userId: string }) {
  const user = await getUser(userId);
  return <Profile user={user} />;
}

Antywzorzec 5: Inicjalizacja state'u z propsów

// ŹLE
function Editor({ initialValue }) {
  const [value, setValue] = useState('');
 
  useEffect(() => {
    setValue(initialValue);
  }, [initialValue]);
 
  return <textarea value={value} onChange={e => setValue(e.target.value)} />;
}

Znowu — dwa rendery, potencjalne race conditions, user traci swoje zmiany jeśli prop się zmieni.

// DOBRZE — lazy initial state
function Editor({ initialValue }) {
  const [value, setValue] = useState(initialValue);  // tylko przy mount
 
  return <textarea value={value} onChange={e => setValue(e.target.value)} />;
}

useState(initialValue) używa initialValue tylko przy pierwszym renderze. Późniejsze zmiany initialValue są ignorowane — co zazwyczaj jest zachowaniem, którego chcesz. Jeśli naprawdę potrzebujesz resetu przy zmianie — użyj key jak w antywzorcu 3.

Antywzorzec 6: Event handlery w useEffect

// ŹLE
function SearchBox() {
  const [query, setQuery] = useState('');
 
  useEffect(() => {
    if (query.length > 2) {
      trackSearch(query);  // analytics
    }
  }, [query]);
 
  return <input value={query} onChange={e => setQuery(e.target.value)} />;
}

Problem: trackSearch odpala się również przy pierwszym renderze (jeśli query ma wartość z URL albo localStorage). A chcemy trackować tylko realne wyszukiwania usera.

// DOBRZE
function SearchBox() {
  const [query, setQuery] = useState('');
 
  const handleChange = (e) => {
    const next = e.target.value;
    setQuery(next);
    if (next.length > 2) {
      trackSearch(next);
    }
  };
 
  return <input value={query} onChange={handleChange} />;
}

Trackowanie (analytics, logi, wysyłka danych) zawsze powinno być triggerowane przez konkretne user action, nie przez pośredni state change.

Antywzorzec 7: Subskrypcja do external store

// ŹLE
function OnlineStatus() {
  const [isOnline, setIsOnline] = useState(navigator.onLine);
 
  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);
 
    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);
 
    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []);
 
  return <span>{isOnline ? 'Online' : 'Offline'}</span>;
}

Ten kod działa, ale jest podatny na bug'i w SSR (hydration mismatch — serwer widzi true, klient może widzieć false). React 18+ dostarcza hook specjalnie do tego:

// DOBRZE — useSyncExternalStore
import { useSyncExternalStore } from 'react';
 
function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}
 
function OnlineStatus() {
  const isOnline = useSyncExternalStore(
    subscribe,
    () => navigator.onLine,          // klient
    () => true,                       // SSR (domyślnie online)
  );
 
  return <span>{isOnline ? 'Online' : 'Offline'}</span>;
}

useSyncExternalStoreuseSyncExternalStore pozwala bezpiecznie subskrybować zewnętrzny store w sposób zgodny z concurrent renderingiem Reacta. jest zaprojektowany do subskrypcji external sources (window events, Redux store, localStorage) i obsługuje SSR, tearing i concurrent mode. Jeden hook zamiast kombinacji useState + useEffect.

Kiedy useEffect JEST poprawny

Żeby nie było, że całkowicie go odrzucam — są miejsca, gdzie useEffect jest dokładnie tym, czego potrzebujesz.

1. Integracja z DOM API niezintegrowanym z React:

function FocusTrap() {
  const ref = useRef(null);
 
  useEffect(() => {
    const element = ref.current;
    const trap = new FocusTrap(element);
    trap.activate();
    return () => trap.deactivate();
  }, []);
 
  return <div ref={ref}>...</div>;
}

2. Manipulacja document / window:

function TitleUpdater({ title }) {
  useEffect(() => {
    document.title = title;
  }, [title]);
 
  return null;
}

3. Setting up timers / intervals:

function Clock() {
  const [time, setTime] = useState(new Date());
 
  useEffect(() => {
    const id = setInterval(() => setTime(new Date()), 1000);
    return () => clearInterval(id);
  }, []);
 
  return <p>{time.toLocaleTimeString()}</p>;
}

4. Subscribe do biblioteki nie-Reactowej:

function MapView() {
  const ref = useRef(null);
 
  useEffect(() => {
    const map = L.map(ref.current).setView([50.06, 19.94], 13);  // Leaflet
    L.tileLayer(TILE_URL).addTo(map);
    return () => map.remove();
  }, []);
 
  return <div ref={ref} style={{ height: 400 }} />;
}

W każdym z tych przypadków synchronizujesz Reacta z czymś zewnętrznym, co nie wie o istnieniu Reacta. To jest przypadek użycia useEffect.

useEffectEvent — gdy effect potrzebuje najnowszych danych

React 19.2 dodaje useEffectEvent, które rozwiązuje częsty problem: effect powinien pozostać podłączony do zewnętrznego systemu, ale callback wewnątrz niego ma widzieć najnowsze propsy albo state.

import { useEffect, useEffectEvent } from 'react';
 
function ChatRoom({ roomId, muted }: { roomId: string; muted: boolean }) {
  const onConnected = useEffectEvent(() => {
    if (!muted) {
      showToast('Połączono z pokojem');
    }
  });
 
  useEffect(() => {
    const connection = createConnection(roomId);
    connection.on('connected', onConnected);
    connection.connect();
    return () => connection.disconnect();
  }, [roomId]);
}

Bez useEffectEvent kuszące jest dopisanie muted do dependency array, co powoduje reconnect chatu przy każdym przełączeniu wyciszenia. Z useEffectEvent effect reaguje na roomId, a callback nadal widzi najnowsze muted.

Diagnostyczne pytania

Kiedy zamierzam napisać useEffect, przechodzę przez checklist:

1. Czy to jest transformacja danych? Jeśli wartość da się obliczyć z props/state w renderze — nie używaj effect.
2. Czy to reakcja na event użytkownika? Jeśli tak — logika idzie do handlera.
3. Czy to fetchowanie danych? Użyj TanStack Query / SWR albo Server Components.
4. Czy to synchronizacja z external system? Tak — useEffect jest odpowiedni. useSyncExternalStore dla stores.
5. Czy to inicjalizacja, która powinna się wydarzyć raz? Użyj useState(() => init()), ref, albo top-level module code.

Jeśli żadna z pozycji 1–4 nie jest prawdą — prawdopodobnie nie potrzebujesz useEffect.

Podsumowanie

useEffect nie jest zły. Jest po prostu nadużywany do problemów, dla których istnieją lepsze rozwiązania. W 2026 roku, ze wszystkimi narzędziami, które mamy — Server Components, Server Actions, TanStack Query, useSyncExternalStore, useActionState, useTransition — większość kodu, który pisałem trzy lata temu z useEffect, dziś bym napisał zupełnie inaczej. I to nie tylko „czystszy", ale też realnie mniej podatny na bug'i.

Jeśli masz projekt React z masą useEffect i chcesz go zmodernizować — napisz do mnie, audyt z konkretnymi sugestiami to typowa usługa StriveLab.