Callback hell w JavaScript? Uporządkuj asynchroniczny kod

Trzy operacje asynchroniczne uruchamiane jedna po drugiej potrafią szybko zamienić prostą funkcję w kod przypominający piramidę. Zjawisko callback hell utrudnia czytanie, obsługę błędów i późniejsze zmiany, ale da się je skutecznie ograniczyć. Pokażę, skąd bierze się problem w JavaScript, jak rozpoznać go w praktyce oraz kiedy użyć Promise, async/await albo zwykłego rozdzielenia funkcji.

Na czym polega problem z zagnieżdżonymi callbackami

Callback to funkcja przekazana do innej funkcji po to, aby wykonać ją później, na przykład po zakończeniu odczytu pliku, odpowiedzi serwera albo kliknięciu przycisku. Sam mechanizm jest prosty i nadal ma sens w wielu miejscach, szczególnie przy obsłudze zdarzeń.

Problem pojawia się wtedy, gdy wynik jednej operacji jest potrzebny do uruchomienia kolejnej, a każda następna funkcja trafia do środka poprzedniej. Kod przesuwa się coraz bardziej w prawo, a jego logika przypomina piramidę zagłady. W praktyce trudniej wtedy ustalić, co wydarzy się pierwsze i gdzie trafi błąd.

pobierzUzytkownika(1, function (blad, uzytkownik) {
  if (blad) {
    return obsluzBlad(blad);
  }

  pobierzZamowienia(uzytkownik.id, function (blad, zamowienia) {
    if (blad) {
      return obsluzBlad(blad);
    }

    pobierzSzczegoly(zamowienia[0].id, function (blad, szczegoly) {
      if (blad) {
        return obsluzBlad(blad);
      }

      zapiszRaport(szczegoly, function (blad) {
        if (blad) {
          return obsluzBlad(blad);
        }

        console.log("Raport zapisany");
      });
    });
  });
});

Każda funkcja w przykładzie może być poprawna osobno. Kłopot polega na tym, że ich połączenie tworzy trudny do utrzymania przepływ. Dodanie kolejnego kroku oznacza następny poziom wcięcia, a zmiana kolejności operacji często wymaga przebudowania kilku callbacków.

Dlaczego taki kod szybko staje się trudny w utrzymaniu

Najbardziej odczuwalnym skutkiem jest spadek czytelności. Czytając kod od góry do dołu, nie zawsze widzę prostą sekwencję działań, tylko mieszankę logiki biznesowej, obsługi błędów i technicznych szczegółów API.

Powtarzająca się obsługa błędów

W popularnym stylu Node.js pierwszy argument callbacka zawiera błąd. To tak zwany error-first callback. Konwencja jest użyteczna, ale przy kilku poziomach zagnieżdżenia ten sam warunek pojawia się wiele razy.

Jeżeli każda operacja może się nie udać, programista musi pamiętać o sprawdzeniu błędu w każdym miejscu. Pominięcie jednego warunku może doprowadzić do użycia pustej wartości, częściowo zapisanego rekordu albo trudnego do odtworzenia błędu w dalszej części programu.

Problemy z kontrolą przepływu

W kodzie opartym na callbackach łatwo przypadkiem wywołać funkcję końcową więcej niż jeden raz. Może się tak zdarzyć, gdy jedna gałąź obsłuży błąd, a później druga nadal spróbuje wykonać sukces. Dlatego callback powinien często kończyć działanie instrukcją return, gdy obsłużono błąd.

Drugim błędem jest wywołanie callbacka zbyt wcześnie albo w kilku miejscach bez jasnej reguły. Wtedy pojawiają się podwójne odpowiedzi HTTP, zdublowane zapisy lub ostrzeżenia typu „callback was already called”.

Testowanie i debugowanie

Testowanie jednej funkcji może być łatwe, ale sprawdzenie całego łańcucha wymaga przygotowania wielu scenariuszy. Trzeba przetestować sukces pierwszego kroku, błąd drugiego, pustą odpowiedź trzeciego oraz sytuację, w której operacja trwa znacznie dłużej niż zwykle.

Z mojego doświadczenia wynika, że największy chaos nie pojawia się podczas pisania pierwszej wersji. Wychodzi dopiero przy poprawkach. Gdy trzeba dodać logowanie, ponowienie żądania albo warunek zależny od danych, zagnieżdżony kod szybko przestaje być lokalnym problemem.

Jak wygląda refaktoryzacja krok po kroku

Nie trzeba od razu przepisywać całego projektu. Najbezpieczniej zacząć od spłaszczenia logiki i oddzielenia poszczególnych etapów. Dzięki temu można poprawiać kod małymi fragmentami, bez zmiany całego zachowania aplikacji.

1. Wyciągnij funkcje poza zagnieżdżenie

Pierwszym krokiem jest nadanie nazw callbackom. Kod staje się dłuższy, ale łatwiej zobaczyć, co robi każdy etap i osobno przetestować jego działanie.

function poPobraniuSzczegolow(blad, szczegoly) {
  if (blad) {
    return obsluzBlad(blad);
  }

  zapiszRaport(szczegoly, poZapisieRaportu);
}

function poPobraniuZamowien(blad, zamowienia) {
  if (blad) {
    return obsluzBlad(blad);
  }

  pobierzSzczegoly(zamowienia[0].id, poPobraniuSzczegolow);
}

function poPobraniuUzytkownika(blad, uzytkownik) {
  if (blad) {
    return obsluzBlad(blad);
  }

  pobierzZamowienia(uzytkownik.id, poPobraniuZamowien);
}

pobierzUzytkownika(1, poPobraniuUzytkownika);

To rozwiązanie usuwa piramidę, ale nie eliminuje wszystkich wad callbacków. Nadal trzeba śledzić, która funkcja przekazuje dane dalej, a wspólna obsługa błędów pozostaje rozproszona.

2. Zwracaj wynik zamiast ukrywać go w środku

Jeśli tworzysz własne funkcje asynchroniczne, zadbaj o przewidywalny kontrakt. Callback powinien otrzymywać błąd jako pierwszy argument, a wynik jako drugi. Warto też jasno ustalić, że zostanie wywołany dokładnie raz.

function pobierzProfil(id, callback) {
  baza.dane(id, function (blad, dane) {
    if (blad) {
      return callback(blad);
    }

    callback(null, dane);
  });
}

Takie reguły nie usuwają zagnieżdżenia, ale ograniczają liczbę nieprzewidywalnych zachowań. Ma to szczególne znaczenie w starszych bibliotekach oraz kodzie, którego nie można jeszcze przepisać na Promise.

3. Zamień callbacki na Promise

Promise reprezentuje wynik operacji, który będzie dostępny później. Zamiast przekazywać funkcję do każdej metody, zwracasz obiekt i łączysz kolejne kroki przez then(). Błąd może zostać obsłużony w jednym catch() na końcu łańcucha.

function pobierzUzytkownikaPromise(id) {
  return pobierzUzytkownika(id);
}

pobierzUzytkownikaPromise(1)
  .then(function (uzytkownik) {
    return pobierzZamowienia(uzytkownik.id);
  })
  .then(function (zamowienia) {
    return pobierzSzczegoly(zamowienia[0].id);
  })
  .then(function (szczegoly) {
    return zapiszRaport(szczegoly);
  })
  .then(function () {
    console.log("Raport zapisany");
  })
  .catch(function (blad) {
    obsluzBlad(blad);
  });

Najważniejsza zasada brzmi zwracaj Promise z każdego kroku. Jeżeli zapomnisz o return, następny etap może uruchomić się za wcześnie albo otrzymać wartość undefined. To jeden z najczęstszych błędów podczas pierwszej refaktoryzacji.

Promise i async/await w praktyce

W nowych fragmentach aplikacji najczęściej wybieram async/await, ponieważ pozwala zapisać sekwencję operacji w formie przypominającej zwykły kod synchroniczny. Funkcja oznaczona jako async zawsze zwraca Promise, a await czeka na jego rozstrzygnięcie w obrębie tej funkcji.

async function utworzRaport(idUzytkownika) {
  try {
    const uzytkownik = await pobierzUzytkownika(idUzytkownika);
    const zamowienia = await pobierzZamowienia(uzytkownik.id);
    const szczegoly = await pobierzSzczegoly(zamowienia[0].id);

    await zapiszRaport(szczegoly);
    console.log("Raport zapisany");
  } catch (blad) {
    obsluzBlad(blad);
  }
}

Ten zapis jest krótszy i zwykle łatwiejszy do debugowania. Nie oznacza jednak, że await magicznie przyspiesza program. Jeżeli dwa żądania są od siebie niezależne, uruchomione jedno po drugim będą czekały na siebie niepotrzebnie.

async function pobierzDane() {
  const [profil, ustawienia] = await Promise.all([
    pobierzProfil(),
    pobierzUstawienia()
  ]);

  return { profil, ustawienia };
}

Promise.all() uruchamia niezależne operacje równolegle i kończy się błędem, gdy którakolwiek z nich zostanie odrzucona. Jeśli potrzebujesz zebrać rezultat każdego zadania, także tych zakończonych błędem, rozważ Promise.allSettled(). Dobór metody zależy od tego, czy brak jednego wyniku ma zatrzymać cały proces.

W praktyce nie traktuję callbacków jako zakazanego rozwiązania. Event listener, funkcja sortująca albo mały hook biblioteki mogą korzystać z callbacka bez żadnego problemu. Kryterium jest proste: jeśli kod pozostaje czytelny i ma jasny przepływ, nie ma potrzeby przepisywać go tylko dlatego, że istnieje nowszy wzorzec.

Typowe błędy przy ucieczce od callbackowego piekła

Najczęstszy błąd polega na mechanicznym zamienieniu każdego callbacka na osobny Promise. Taka zmiana może usunąć wcięcia, ale zostawić tę samą chaotyczną strukturę. Refaktoryzacja powinna poprawić także nazwy funkcji, przepływ danych i sposób reagowania na błędy.

Mieszanie callbacków i Promise bez wyraźnej granicy

Starsza funkcja może nadal wywoływać callback, podczas gdy reszta aplikacji pracuje na Promise. W takim przypadku przydaje się adapter, który opakowuje istniejące API w nowy interfejs. W Node.js można użyć util.promisify, jeśli dana funkcja stosuje standardowy układ argumentów.

Nie należy jednak opakowywać funkcji na ślepo. Jeśli biblioteka ma nietypową sygnaturę, callback wywoływany jest więcej niż raz albo wynik ma kilka wartości, trzeba sprawdzić jej dokumentację i napisać własny adapter.

Zapominanie o błędach

Blok try/catch przechwytuje błędy z operacji używających await, ale nie każdą przypadkową pracę uruchomioną w tle. Jeżeli rozpoczynasz Promise bez await i bez obsługi odrzucenia, możesz otrzymać nieobsłużony błąd.

async function zapiszDane() {
  await przygotujDane();

  // Błąd w tym zadaniu nie zostanie obsłużony przez try/catch wyżej,
  // jeśli Promise nie zostanie zwrócony ani oczekiwany.
  wyslijPowiadomienie();
}

Warto jasno zdecydować, czy zadanie jest częścią głównego procesu. Jeśli tak, użyj await albo zwróć Promise. Jeśli ma działać niezależnie, dodaj własne catch() i zaplanuj, co aplikacja zrobi w razie niepowodzenia.

Przeczytaj również: Redux - Kiedy warto go użyć i jak działa?

Niepotrzebne oczekiwanie na operacje niezależne

Wstawienie await przed każdym wywołaniem daje czytelny kod, ale może obniżyć wydajność. Profil użytkownika i lista kategorii nie zawsze muszą być pobierane osobno. Najpierw rozdziel zależności, a dopiero potem zdecyduj, które operacje mogą działać równolegle.

Kiedy callbacki nadal są dobrym wyborem

Nie każde zagnieżdżenie oznacza awarię projektu. Callback użyty w funkcji setTimeout, obsłudze kliknięcia lub metodzie tablicy zwykle jest naturalnym elementem JavaScriptu. Problem zaczyna się dopiero przy łańcuchu zależnych operacji asynchronicznych, który rozrasta się razem z logiką aplikacji.

Mały callback może być lepszy od tworzenia całej warstwy Promise. Dotyczy to szczególnie jednorazowych skryptów, prostych integracji i kodu utrzymywanego przez bibliotekę, która od początku udostępnia callbackowe API.

Przed refaktoryzacją sprawdzam trzy rzeczy. Czy zagnieżdżenie ma więcej niż dwa lub trzy poziomy? Czy obsługa błędów powtarza się w każdym kroku? Czy dodanie kolejnej operacji wymaga przesuwania dużej części kodu w prawo? Jeśli odpowiedź brzmi „tak”, przejście na Promise albo async/await zwykle szybko się zwraca.

• Zostaw callback, gdy obsługuje pojedyncze zdarzenie lub prostą operację.
• Wydziel funkcje, gdy problemem jest głównie długość jednego bloku.
• Wybierz Promise, gdy budujesz łańcuch i potrzebujesz wygodnego łączenia wyników.
• Użyj async/await, gdy najważniejsza jest czytelna sekwencja i centralna obsługa błędów.
• Dodaj Promise.all(), gdy kilka zadań nie zależy od siebie.

Jak odzyskać kontrolę nad asynchronicznym kodem

Dobrze napisany kod asynchroniczny nie musi być krótki za wszelką cenę. Powinien jasno pokazywać, od czego zależy każda operacja, co dzieje się po błędzie i które zadania mogą działać równolegle.

Najpraktyczniejsza ścieżka wygląda zwykle tak: najpierw nazwij callbacki, potem ujednolić ich kontrakt, następnie opakuj starsze API w Promise i dopiero na końcu uprość całość przez async/await. Taka kolejność ogranicza ryzyko i pozwala po każdym kroku uruchomić testy.

Nie chodzi o usunięcie każdego callbacka z projektu. Chodzi o to, aby logika aplikacji nie była zakopana pod kolejnymi poziomami wcięć. Gdy przepływ danych jest płaski, błędy mają jednoznaczną ścieżkę, a niezależne zadania nie blokują się wzajemnie, JavaScript staje się znacznie łatwiejszy w rozwijaniu.