instanceof w JavaScript - Używać czy unikać?

Operator instanceof przydaje się wtedy, gdy kod ma rozpoznać, czy dany obiekt należy do konkretnego łańcucha prototypów. To nie jest zwykłe porównanie typu, tylko sprawdzenie relacji między obiektem a konstruktorem, dlatego potrafi dawać wyniki, które na pierwszy rzut oka zaskakują. Poniżej pokazuję, jak działa, gdzie się wykłada, czym różni się od innych testów i kiedy w praktyce lepiej wybrać inną metodę.

Jak działa operator instanceof w praktyce

Najprościej ujmując, zapis obiekt instanceof Konstruktor pyta, czy Konstruktor.prototype znajduje się gdzieś w łańcuchu prototypów obiekt. Ja traktuję to jako test pokrewieństwa, a nie test samego „gatunku” danych. To ważne rozróżnienie, bo w JavaScript obiekt może wyglądać „jak ten właściwy”, ale niekoniecznie pochodzić z miejsca, które masz na myśli.

W praktyce działa to tak:

function Car(make, model) {
  this.make = make;
  this.model = model;
}

const auto = new Car("Honda", "Accord");

console.log(auto instanceof Car);   // true
console.log(auto instanceof Object); // true

To, że auto instanceof Object zwraca true, nie jest błędem. Każdy obiekt utworzony zwykłym konstruktorem ma w łańcuchu prototypów Object.prototype, więc przechodzi również ten test. Z kolei zwykły literał prymitywny nie przechodzi go wcale:

const text = "Ala ma kota";

console.log(text instanceof String); // false
console.log(new String("Ala ma kota") instanceof String); // true

To właśnie tu widać sedno: operator nie pyta „jaki to typ?”, tylko „czy ten prototyp jest w drodze do korzenia?” Jeśli ten model masz w głowie, połowa późniejszych pułapek przestaje być zaskoczeniem. Następny krok to sprawdzenie, kiedy ten mechanizm daje wyniki inne niż się intuicyjnie spodziewasz.

Kiedy wynik potrafi zaskoczyć

W codziennym kodzie instanceof zwykle działa przewidywalnie. Problemy zaczynają się wtedy, gdy zmieniasz prototypy, mieszasz obiekty z różnych środowisk albo zakładasz, że wynik testu mówi coś więcej niż tylko „ten łańcuch się zgadza”.

Ten ostatni punkt jest szczególnie ważny, jeśli korzystasz z klas z prywatnymi polami. Obiekt może przejść test instanceof, a i tak nie mieć wewnętrznego stanu ustawionego przez konstruktor. Wtedy pozornie poprawna gałąź kodu kończy się błędem przy dostępie do prywatnych pól. Dla mnie to jeden z najczęstszych powodów, dla których nie warto traktować tego operatora jak pełnej walidacji obiektu.

class Foo {
  #value = "foo";

  static getValue(x) {
    return x.#value;
  }
}

const x = { __proto__: Foo.prototype };

if (x instanceof Foo) {
  console.log(Foo.getValue(x)); // TypeError
}

Jeśli pracujesz z wieloma kontekstami, warto od razu założyć, że sam test prototypów może nie wystarczyć. To prowadzi do pytania: kiedy sięgnąć po instanceof, a kiedy użyć czegoś bardziej bezpośredniego.

Najczęstsze błędy i TypeError

W błędach związanych z instanceof widać zwykle te same trzy problemy: prawa strona nie jest konstruktorową funkcją, ktoś przypadkiem wywołał funkcję zamiast przekazać jej nazwę albo operator został użyty z niepoprawnym priorytetem.

function Foo() {}
const x = new Foo();

console.log(x instanceof Foo); // true

const f = Foo();
console.log(x instanceof f); // TypeError

const isCar = (value) => value instanceof Car; // źle, jeśli Car miałoby być funkcją strzałkową

Druga pułapka to negacja. Zapis !obiekt instanceof Konstruktor nie znaczy tego, co większość ludzi myśli. Najpierw wykonuje się !, więc finalnie sprawdzasz, czy false albo true jest instancją konstruktora. To niemal zawsze prowadzi do złego wyniku.

if (!(myCar instanceof Car)) {
  // poprawnie
}

if (!myCar instanceof Car) {
  // błędnie
}

Jeżeli mam wskazać jedną rzecz, którą warto zapamiętać na dłużej, to jest nią ta: operator działa poprawnie tylko wtedy, gdy prawa strona jest tym, czym myślisz, że jest. Jeśli to nie jest pewne, trzeba się zatrzymać i sprawdzić, czy na pewno używasz właściwego narzędzia. I właśnie tutaj naturalnie pojawia się porównanie z innymi metodami weryfikacji.

Czym zastąpić go w zależności od zadania

Wiele osób używa instanceof jako uniwersalnego testu typu, a to zwykle jest skrót myślowy, który wcześniej czy później mści się w produkcji. W praktyce lepiej dobrać narzędzie do konkretnego problemu, zamiast próbować jednym operatorem obsłużyć wszystko.

Ja zwykle wybieram typeof dla prymitywów, Array.isArray() dla tablic i instanceof dopiero wtedy, gdy naprawdę interesuje mnie hierarchia klas. To prosta zasada, ale oszczędza sporo czasu przy debugowaniu. Jeśli kod obsługuje obiekty z iframe, pluginów albo różnych okien, zwykły test konstruktora często przegrywa z bardziej jednoznaczną walidacją.

Warto też pamiętać o Object.prototype.isPrototypeOf(). Ten mechanizm bywa praktyczny, gdy chcesz sprawdzić sam prototyp, bez zakładania konkretnego konstruktora. To szczególnie przydatne w kodzie, w którym obiekty mogą być składane ręcznie albo dziedziczenie nie przebiega w najbardziej klasyczny sposób.

Jak kontrolować własne reguły przez Symbol.hasInstance

Jeśli potrzebujesz, żeby instanceof oznaczał coś bardziej domenowego niż zwykły łańcuch prototypów, możesz przejąć kontrolę przez Symbol.hasInstance. To już jednak narzędzie dla świadomych przypadków, nie do codziennego nadużywania. Z mojego punktu widzenia ma sens głównie wtedy, gdy budujesz własną „markę” obiektów albo chcesz uznać za instancję coś, co spełnia konkretny warunek strukturalny.

class Forgeable {
  static isInstanceFlag = Symbol("isInstanceFlag");

  static [Symbol.hasInstance](obj) {
    return obj && Forgeable.isInstanceFlag in obj;
  }
}

const obj = { [Forgeable.isInstanceFlag]: true };

console.log(obj instanceof Forgeable); // true

To rozwiązanie jest wygodne, ale ma koszt: zmienia intuicję całego operatora. Ktoś czytający taki kod może zakładać, że test dotyczy klasy, a w rzeczywistości sprawdzasz tylko obecność znacznika. Dlatego używałbym tego tylko tam, gdzie reguła jest dobrze opisana i utrzymywana razem z kodem. W przeciwnym razie łatwo stworzyć abstrakcję, którą trudno potem zrozumieć po kilku miesiącach.

Najprościej myśleć o tym tak: zwykły instanceof to test struktury prototypów, a Symbol.hasInstance to możliwość podmiany definicji tej struktury na własną. To już nie jest drobna optymalizacja, tylko decyzja architektoniczna. I właśnie dlatego warto przemyśleć, czy naprawdę jej potrzebujesz.

Kiedy używam go w kodzie produkcyjnym, a kiedy odpuszczam

W praktyce sięgam po instanceof głównie w trzech sytuacjach: przy rozróżnianiu własnych klas domenowych, przy obsłudze błędów i wtedy, gdy chcę sprawdzić, czy obiekt pochodzi z przewidywalnej hierarchii konstruktorów. Poza tym zakresem zaczynam być ostrożny. Jeśli test ma potwierdzać poprawność danych z API, formularza albo zewnętrznej biblioteki, zwykle wolę jawne walidatory niż samą kontrolę konstruktora.

• Używaj go do rozpoznawania instancji własnych klas, jeśli obiekty nie opuszczają bieżącego środowiska wykonania.
• Nie traktuj go jako pełnej walidacji danych wejściowych.
• Unikaj polegania na nim przy obiektach z iframe, różnych okien, workerów lub bibliotek osadzonych w innym realmie.
• Przy tablicach wybieraj Array.isArray(), nie instanceof Array.
• Jeżeli potrzebujesz reguły biznesowej, rozważ jawny znacznik, metodę walidacyjną albo Symbol.hasInstance tylko wtedy, gdy faktycznie poprawia to czytelność.

Jeżeli miałbym zostawić jedną praktyczną wskazówkę na koniec, byłaby prosta: testuj zachowanie, nie tylko nazwę typu. Gdy kod opiera się na klasach, właściwie użyty instanceof jest czytelny i wygodny. Gdy jednak zaczynasz go stosować do wszystkiego, rośnie ryzyko błędów, które widać dopiero w mniej oczywistych scenariuszach. Dlatego w projektach produkcyjnych wolę mały zestaw precyzyjnych testów niż jeden operator używany „na wszelki wypadek”.