{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/ciekawostki-typescript-2-ts-minus-typy-rowna-sie-js","result":{"data":{"markdownRemark":{"html":"

TypeScript nadzbiorem JavaScriptu

\n

Mówi się, że \"TypeScript jest nadzbiorem JavaScriptu\". Ale co to oznacza? W praktyce - wiadomo - każdy kod JavaScriptu jest poprawnym kodem JavaScriptowym. Zatem, co jest tym \"nad\" w stosunku do JavaScriptu? Otóż - system typów. I - przynajmniej koncepcyjnie, z pewnymi drobnym zastrzeżeniami, o których niżej - tylko system typów. To znaczy, że - \"kanonicznie\" (zastrzeżnia niżej) - konwersja TS do JS polega tylko na usunięciu informacji o typach. A zatem właściwie taką \"konwersję\" można by wykonać ręcznie usuwając wszystkie typy czy informacje, że dana klasa implementuje jakiś interfejs.

\n

To, co napisałem powyżej, można dobrze zaobserwować na przykładzie typescriptowych modyfikatorów dostępu w klasie. Wyobraźmy sobie, że mamy taką klasę, napisaną w TS:

\n
class Person {\n  private firstName: string\n  private lastName: string\n\n  constructor(firstName: string, lastName: string) {\n    this.firstName = firstName\n    this.lastName = lastName\n  }\n\n  public sayHello(): string {\n    return `Hi, I'm ${this.firstName} ${this.lastName}!`\n  }\n}
\n

Pola firstName i lastName zadeklarowaliśmy jako prywatne. Zatem w TS próby dostania się do nich zakończą się błędem:

\n
const john = new Person(\"John\", \"Smith\")\nconsole.log(john.firstName) // <- tu będzie błąd
\n

Jak ta klasa zostanie jednak przekonwertowana do JavaScriptu? Mniej więcej tak:

\n
class Person {\n  constructor(firstName, lastName) {\n    this.firstName = firstName\n    this.lastName = lastName\n  }\n\n  sayHello() {\n    return `Hi, I'm ${this.firstName} ${this.lastName}!`\n  }\n}
\n

A gdybyśmy w JavaScripcie chcieli się dostać do firstName? Proszę bardzo - błędu nie ma:

\n
const john = new Person(\"John\", \"Smith\")\nconsole.log(john.firstName) // <- błędu nie ma!
\n

Gdy pierwszy raz się o tym dowiedziałem, to pomyślałem: \"Ale jak to? Prywatne pole jest publiczne?... TypeScript, oszukałeś mnie...\" Ale w zasadzie to jest konsekwencja tego równania:

\n
TypeScript - (system typów) = JavaScript
\n

Jeśli zatem chcielibyśmy na 100% traktować te pola jako prywatne - bo np. piszemy bibliotekę i naprawdę chcemy ukryć jakiś szczegół implementacyjny - to mamy dwa wyjścia:

\n\n

W przypadku domknięć, należałoby napisać w TS naszą klasę mniej więcej tak:

\n
class Person {\n  public sayHello: () => string\n\n  constructor(firstName: string, lastName: string) {\n    this.sayHello() = () => {\n      return `Hi, I'm ${firstName} ${lastName}!`\n    }\n  }\n}
\n

To rozwiązanie też ma niestety swoje wady:

\n\n

Wyjątki od reguły

\n

Na koniec muszę zwrócić uwagę na dwa wyjątki od tej zasady, że transpilator jedynie usuwa informacje o typach i modyfikatory dostępu. Tymi wyjątkami są enumy oraz pewien syntactic sugar w postaci definiowania parametrów konstruktora od razu jako pól klasy.

\n

Enumy

\n

Dla programisty C#, który zaczyna przygodę z TypeScriptem - użycie enumów to coś naturalnego: przecież nie będziemy używać jakichś magic numberów! Jednakże enumy w TS zachowują się nietypowo.\nPo pierwsze, enum z wartościami liczbowymi pozwala na przypisanie do niego dowolnej liczby... (Co to za enum?!)

\n
enum WeekDay {\n  Monday = 1,\n  Tuesday = 2,\n  Wednesday = 3,\n  Thursday = 4,\n  Friday = 5,\n  Saturday = 6,\n  Sunday = 6,\n}\n\nconst wtf: WeekDay = 11 // <-- nie ma błędu!
\n

Po drugie, jeśli do deklaracji enuma dodamy const (a więc const enum), to wszystkie jego użycia zostaną potraktowane jak const w C# - w czasie transpilacji zostaną podmienione na wartości liczbowe.

\n

Po trzecie, enumy z wartościami stringowymi mają pewne pułapki: jeśli przypiszemy enuma do zmiennej, to zmiast typu string, otrzyma on typ literałowy, więc nie będziemy mogli go nadpisać, np.:

\n
enum Status {\n  Pending = \"pending\",\n  Done = \"done\",\n}\n\nlet statusText = Status.pending\nstatusText = `Status is: ${statusText}` // <-- tu będzie błąd: \"Type 'string' is not assignable to type 'Status'.\"
\n

Zamiast enuma lepiej użyć tutaj \"unię typów literałowych\", czyli:

\n
type Status = \"pending\" | \"done\"
\n

Parametry konstruktora jako pola

\n

TypeScript umożliwia zrobienie takie skrótowego zapisu:

\n
class Person {\n  constructor(public firstName: string, public lastName: string) {}\n}
\n

zamiast rozwlekłego:

\n
class Person {\n  public firstName: stirng\n  public lastName: string\n  constructor(firstName: string, lastName: string) {\n    this.firstName = firstName\n    this.lastName = lastName\n  }\n}
\n

Ten syntactic sugar jest dla TS wyjątkowy, bo właśnie też skutkuje generowanie kodu JS - czyli znów wyłamujemy się z reguły \"TS minus typy to JS\". Autor książki, o której wspominam poniżej, krytykuje używanie tego \"myku\" w TS (właśnie z takich powodów, nazwijmy to, kanonicznych), jednak dla mnie jest to bardzo wygodne. Ponadto, podobną propozycję widziałem w którejś z przyszłych/eksperymentalnych wersji C#, więc być może to jest też jakiś trend wspólny dla różnych języków. :)

\n

Ten wpis jest częścią serii o TypeScripcie, inspirowaną lekturą książki D. Vanderkama pt. \"TypeScript. Skuteczne programowanie\".

","excerpt":"TypeScript nadzbiorem JavaScriptu Mówi się, że \"TypeScript jest nadzbiorem JavaScriptu\". Ale co to oznacza? W praktyce - wiadomo - każdy kod JavaScriptu jest…","frontmatter":{"date":"01 October, 2020","path":"/blog/ciekawostki-typescript-2-ts-minus-typy-rowna-sie-js","title":"Ciekawostki Typescript #2 - TS - typy = JS"},"fields":{"readingTime":{"text":"4 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}