Any vs Unknow - TypeScript
02/01/2023
3 min read
Używanie TypeScript chroni nas przed błędami już na etapie kompilacji. Są jednak przypadki, gdy programiści wyłączają tę ochronę, używając any lub unknown. Dzisiaj wyjaśnię, jak te opcje się różnią oraz czy warto je w ogóle używać.
any
Użycie
any wyłącza sprawdzanie typów, które wykonuje TypeScript. Możemy przypisywać wartości dowolnego typu do zmiennej.let amount: number = 123;let description: any;description = 1;description = "ABC";amount = description;
Kod powyżej nie zwróci żadnego błędu na etapie kompilacji. TypeScript faktycznie pomija sprawdzanie typów, jakbyśmy pisali w Vanilla JS. Ten prosty przykład spowoduje błąd czasem wykonania, gdy zamiast typu
number użyjemy string. Dużo gorszy będzie scenariusz z obiektami, gdy gdzieś w aplikacji będzie używana niezdefiniowana właściwość, co może potencjalnie spowodować awarię aplikacji i pustą stronę.Powinniśmy unikać typowania przez
any. Tracimy wszystkie zalety TypeScript. To jest bardzo pomocne, gdy nowi programiści dołączają do projektu i nie mogą nauczyć się dużo o aplikacji, gdy każdy typ jest any. W moich projektach (biznesowych i prywatnych) zawsze staram się zainstalować "eslint", który chroni mnie przed użyciem any.unknown
unknown działa podobnie do any. Również możemy przypisywać wartości dowolnego typu do zmiennej, ale tutaj TypeScript zapewnia pewne częściowe sprawdzanie typów.let amount: number = 123;let description: unknown;description = 1;description = "ABC";amount = description;
Kod powyżej zwróci błąd:
Type 'unknown' is not assignable to type 'number'.(2322)
Oznacza to, że możemy przypisywać zmienne typu
unknown do innych. W tym przypadku powinno się zapewnić sprawdzanie typów, na przykład przez prosty polecenie if z typeof.let amount: number = 123;let description: unknown;description = 1;description = "ABC";if(typeof description === "number") {amount = description;}
any vs unknow - kiedy użyć czego?
Najlepiej nie używać żadnego z nich. Typowanie naszego kodu za pomocą "any" / "unknown", świadomie narażamy się na potencjalne błędy podczas działania aplikacji. Jednak jeśli jesteśmy zmuszeni do użycia któregokolwiek z nich (np. nie jesteśmy pewni, jakiego typu będzie), lepiej używać "unknown", ponieważ w przeciwieństwie do "any" zapewnia minimalne sprawdzanie typów.
Personalnie używam
unknown / any w kilku przypadkach- refaktoryzacja projektu z JS na TS - podczas zmiany rozszerzenia pliku z
.jsna.ts, zmienne, których nie mogę szybko oznaczyć, są oznaczane jakoanyz komentarzy todo, aby poprawić jak najszybciej - Podczas prototypowania niektórych funkcjonalności, gdzie obecna wartość jest mało istotna (zawsze oznaczam ją komentarzem
//TODO, aby nie zostawiaćany - W testach jednostkowych przy symulowaniu trudnych danych wejściowych
Spróbujmy dbać o jakość kodu poprzez poprawne i dokładne typowanie zmiennych, metod itp., a użycie
any niech będzie tylko ostatecznością z komentarzem wyjaśniającym potrzebę jego użycia.
