Callbacki w JavaScript: funkcje jako argumenty i callback hell

Callback to funkcja, którą przekazujesz innej funkcji

Funkcje w JavaScript są wartościami. Możesz przechowywać je w zmiennych, wkładać do tablic i, co tu najważniejsze, przekazywać jako argumenty. Gdy przekazujesz funkcję do innej funkcji, żeby ta mogła ją później wywołać, przekazana funkcja jest callbackiem.

function greet(name, formatter) {
    const message = formatter(name);
    console.log(message);
}

function shout(name) {
    return `HELLO, ${name.toUpperCase()}!`;
}

greet("Rosa", shout);
greet("Boris", (n) => `hey, ${n}`);

greet nie wie i nie obchodzi jej, co robi formatter. Po prostu wywołuje go z imieniem i używa wyniku. Zachowanie wybierasz, przekazując różne callbacki. Ta elastyczność to cały powód istnienia callbacków.

Callbacki synchroniczne działają od razu

Nie każdy callback jest asynchroniczny. Wiele metod tablic, których już używasz, opiera się na callbackach i wywołuje je synchronicznie, zanim zewnętrzne wywołanie się zakończy:

const numbers = [1, 2, 3, 4];

const doubled = numbers.map((n) => n * 2);
const evens = numbers.filter((n) => n % 2 === 0);
const sum = numbers.reduce((acc, n) => acc + n, 0);

console.log(doubled, evens, sum);

map, filter i reduce przyjmują callback i wywołują go raz dla każdego elementu, od razu. Zanim map zwróci wynik, wszystkie wywołania callbacka już się odbyły. Nic nie czeka w kolejce na później.

To zwykły wzorzec funkcji wyższego rzędu: "oto praca, oto jak ją zrobić, daj mi wynik". Event loop nie bierze w tym udziału.

Callbacki asynchroniczne działają później

Gdy ludzie mówią "callbacki", zwykle mają na myśli te asynchroniczne. Przekazujesz funkcję do API, które potrzebuje czasu (timer, żądanie sieciowe, odczyt pliku), a API wywołuje twoją funkcję, gdy praca się zakończy.

console.log("przed");

setTimeout(() => {
    console.log("timer odpalony");
}, 1000);

console.log("po");

Kolejność wyjścia: przed, po, a sekundę później timer odpalony. setTimeout nie wstrzymuje programu. Przekazuje callback do środowiska uruchomieniowego, od razu zwraca sterowanie, a reszta skryptu działa dalej. Sekundę później event loop podejmuje callback i go uruchamia.

Schemat "zwróć teraz, oddzwoń później" to model myślowy dla każdego asynchronicznego API opartego na callbackach w JavaScript, od addEventListener po starsze API plików w Node.js.

Konwencja error-first (Node.js)

Zanim pojawiły się obietnice, Node.js ustandaryzował konkretny kształt callbacka: pierwszy argument to błąd (albo null), a kolejne to właściwy wynik. Nadal spotkasz go w starszym kodzie i niektórych bibliotekach.

function loadUser(id, callback) {
    setTimeout(() => {
        if (id <= 0) {
            callback(new Error("nieprawidłowe id"));
            return;
        }
        callback(null, { id, name: "Rosa" });
    }, 100);
}

loadUser(1, (err, user) => {
    if (err) {
        console.error("błąd:", err.message);
        return;
    }
    console.log("użytkownik:", user);
});

loadUser(-1, (err, user) => {
    if (err) {
        console.error("błąd:", err.message);
        return;
    }
    console.log("użytkownik:", user);
});

Kod wywołujący najpierw sprawdza err i wychodzi wcześniej, jeśli ma wartość truthy. Dopiero wtedy ufa wynikowi. To konwencja, której język nie wymusza, ale gdy raz zobaczysz sygnaturę (err, result) => ..., rozpoznasz ją wszędzie.

Callback hell

Kłopoty zaczynają się, gdy jeden krok asynchroniczny zależy od wyniku innego. Każdy callback musi być zagnieżdżony w poprzednim, a kod układa się w schodki uciekające w bok:

function step(name, cb) {
    setTimeout(() => cb(null, `${name}-done`), 100);
}

step("login", (err, a) => {
    if (err) return console.error(err);
    step("fetch-profile", (err, b) => {
        if (err) return console.error(err);
        step("fetch-posts", (err, c) => {
            if (err) return console.error(err);
            step("render", (err, d) => {
                if (err) return console.error(err);
                console.log(a, b, c, d);
            });
        });
    });
});

To słynna "piramida zagłady", czyli callback hell. Kilka rzeczy sprawia, że jest bolesna:

• Przepływ sterowania skacze zygzakiem zamiast czytać się z góry na dół.
• Każdy poziom powtarza ten sam szablonowy kod if (err) return ....
• Wyjątek rzucony w jednym callbacku nie przechodzi do zewnętrznych: błędy trzeba obsługiwać na każdej warstwie.
• Refaktoryzacja oznacza ponowne wcięcie całego bloku.

Można to trochę spłaszczyć, wydzielając nazwane funkcje, ale główny problem (składanie operacji asynchronicznych z gołych callbacków jest niewygodne) nie znika. To właśnie problem, do którego rozwiązania zaprojektowano obietnice.

Dwie pułapki, które warto znać

Nie wywołuj callbacka przez przypadek. Przekazując callback, przekazujesz samą funkcję, a nie wynik jej wywołania.

function run(cb) {
    console.log("zaraz uruchamiam");
    cb();
}

function work() {
    console.log("pracuję");
}

run(work);    // dobrze: przekazuje funkcję
// run(work());  // źle: najpierw wywołuje work(), a do run przekazuje undefined

Uważaj na this. Jeśli callback to zwykła funkcja używająca this, wartość this zależy od tego, jak callback zostanie wywołany, a nie od miejsca, w którym go zdefiniowano. Funkcje strzałkowe omijają ten problem, bo dziedziczą this z otaczającego zakresu:

const counter = {
    count: 0,
    startBroken() {
        setTimeout(function () {
            this.count++;           // `this` is not the counter here
            console.log(this.count); // NaN in strict mode, or global pollution
        }, 10);
    },
    startFixed() {
        setTimeout(() => {
            this.count++;           // arrow - `this` is the counter
            console.log(this.count);
        }, 10);
    },
};

counter.startFixed();

Właśnie z tego powodu funkcje strzałkowe są domyślnym wyborem dla callbacków pisanych w miejscu użycia.

Callbacki vs obietnice

Callbacki nadal pojawiają się w synchronicznych API (map, forEach, sort), w event listenerach (element.addEventListener("click", ...)) i w niskopoziomowych hookach środowiska. Przy pracy asynchronicznej, która daje jeden wynik, ekosystem niemal całkowicie przeszedł na obietnice.

Szybkie porównanie:

• Callbacki: bezpośrednie, minimalne, ale źle się składają. Obsługa błędów jest ręczna na każdym kroku.
• Obietnice: wartość reprezentująca przyszły wynik. Łączysz je w łańcuch przez .then(), błędy obsługujesz raz przez .catch(), a piramida się spłaszcza.

Nadal musisz rozumieć callbacki: na nich zbudowane są obietnice i są wszędzie w kodzie sterowanym zdarzeniami. Ale nowe asynchroniczne API rzadko pisze się dziś na gołych callbackach.

Dalej: obietnice

Obietnice biorą pomysł "zrób to, gdy tamto będzie gotowe" i opakowują go w obiekt, który możesz przekazywać, łączyć w łańcuchy i składać. To temat następnej strony i pomost do async/await, czyli sposobu, w jaki większość nowoczesnego JavaScriptu obsługuje pracę asynchroniczną.