Frontend Thursday vol. 78 – to już koniec TypeScript! – typy trafią do JavaScript

1. To już koniec TypeScript! – typy trafią do JavaScript

No dobra – na razie nie wiadomo czy i jeśli tak to kiedy tytułowe typy trafią do JavaScript. Również szanse na to, że ich pojawienie się zakończy żywot TypeScriptu są raczej nikłe. Musicie jednak przyznać, że udało mi się przyciągnąć Waszą uwagę. Wykorzystajmy ten fakt i przyjrzyjmy się dokładniej szalonemy pomysłowi dodania typów do JavaScriptu na jaki wpadł Microsoft.

Proposal, który zaprezentował Microsoft, dodaje do JavaScriptu składnię typów bliźniaczo podobną do tej znanej z TypeScript. Magiczny trik umożliwiający względną kompatybilność polega na tym, że interpreter traktował będzie typy w ten sam sposób w jaki traktuje komentarze – kompletnie je ignorując. Jeśli z tyłu głowy kołacze się Wam myśl, że ktoś kiedyś zrobił już coś podobnego, to python wykorzystuje typy w bardzo podobny sposób. Różnica polega na tym, że python udostępnia część metadanych o typach w runtime, natomiast JavaScript miałby pozbywać się ich kompletnie.

To, że typy będą ignorowane przez interpreter nie oznacza, że my deweloperzy nie skorzystamy z ich obecności. Podobnie jak ma to miejsce przy korzystaniu JSDoc, tak i tutaj do IDE i narzędzi deweloperskich możliwe będzie podpięcie type-checkera, który ostrzegał nas będzie przed błędami. Część deweloperów twierdzi również, że samo dodanie typów sprawia, że kod jest znacznie czytelniejszy. Ja osobiście mocno się z nimi nie zgadzam, bo typy bez podpiętego type-checkera są dla mnie oczywistym strzałem w kolano.

Warto zwrócić również uwagę na różnice pomiędzy proponowanym formatem, a znanym już JSDoc. Po pierwsze proponowany przez Microsoft format jest znacznie zwięźlejszy i czytelniejszy niż JSDoc. Po drugie możliwości JSDoc są mocno ograniczone (za jego pomocą ciężko jest zdefiniować chociażby generyki) i nowy format ma pozbywać się tych ograniczeń.

/**
 * @param {string}  p1 - A string param.
 * @param {string=} p2 - An optional param (Closure syntax)
 * @param {string} [p3] - Another optional param (JSDoc syntax).
 * @param {string} [p4="test"] - An optional param with a default value
 * @return {string} This is the result
 */
function stringsStringStrings(p1, p2, p3, p4) {
    // TODO
}

function stringsStringStrings(p1: string, p2?: string, p3?: string, p4 = "test"): string {
    // TODO
}

Proposal na razie jest dopiero na etapie zerowym, więc raczej nie należy mocno przywiązywać się do jego treści. Zanim dotrze do kolejnych etapów jego treść zmieni się zapewne jeszcze wielokrotnie. Zgodnie z jego treścią do JavaScript miałoby trafić większość funkcjonalności związanych z typami jakie znamy z TypeScript(w tym generyki i union oraz intersection types!). Łatwiej będzie więc wymienić funkcjonalności,  które nie będą wspierane, a są to enumy, namespaces, parameter properties oraz JSX. No cóż, nie można mieć wszystkiego.

Przeglądając opinie deweloperów na twitterze i reddicie nie sposób nie odnieść wrażenia, że społeczność jest wręcz zakochana w proposalu Microsoftu. Zresztą nic dziwnego, bo statyczne typowanie JavaScriptu według State of JS od lat było najbardziej oczekiwaną przez deweloperów funkcjonalnością JavaScript. Ja z przykrością muszę przyznać się, że nie płynę wraz z społecznością na tej fali zachwytu. Współczesny kod aplikacji klienckich bezwzględnie wymaga transpilacji i minifikacji, która sprawi, że typy znikną. Na usprawnieniach moglibyśmy skorzystać w trakcie developmentu, ale dostępne już dziś source mapy zaspokajają moje potrzeby. Do tego z typów w JavaScript nie skorzystają największe dostępne frameworki, bo te albo wykorzystują JSX, albo wymagają kompilacji, albo nawet wymuszają korzystanie z TypeScript. Typy w TypeScript okażą się więc przydatne w niewielkich projektach, które nie wymagają kompatybilności wstecznej przeglądarek.

Nie zrozumcie mnie źle – nie jestem przeciwnikiem typów w JavaScript. Z pewnością znajdą one swoje nisze, takie jak na przykład aplikacje serwerowe, w których nie liczy się rozmiar wynikowych plików. Ja po prostu nie potrafię się nimi zachwycić, bo wszystko czego

Jak już wspominaliśmy proposal jest na razie na etapie zerowym i Microsoft ma zamiar przedstawić go TC39 Meeting na najbliższym spotkaniu. Patrząc na reakcję społeczności proposal ten raczej trafi do kolejnych etapów. Znając jednak tempo procesów TC39, to typy do oficjalnej specyfikacji trafią najwcześniej za kilka lat i to pod postacią mocno zmienioną względem zaprezentowanego w tym tygodniu szkicu.

Źródła:

https://devblogs.microsoft.com/typescript/a-proposal-for-type-syntax-in-javascript/
https://github.com/giltayar/proposal-types-as-comments/

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. TypeScript 4.6

Ostatnie tygodnie w Microsoft musiały być bardzo pracowite, bo oprócz wspomnianego w poprzednim akapicie proposala w minionym tygodniu wydany został również TypeScript 4.6. Ja jak zwykle polecam notatkę przygotowaną przez Microsoft, bo standardowo już jest ona najwyższej jakości. Tych, którzy oczekują telegraficznego skrótu najważniejszych zmian, zapraszam natomiast poniżej.

Jedną z ciekawszych nowości jest naprawa drobnej niekompatybilności pomiędzy JavaScriptem i TypeScriptem. Ten pierwszy w konstruktorze klasy umożliwia umieszczenie fragmentu kodu przed wywołaniem super, pod warunkiem że fragment ten nie odwołuje się do this. TypeScript do tej pory na etapie kompilacji wymagał, aby wywołanie super było pierwszą akcją wywoływaną w konstruktorze. Od wersji 4.6 zachowanie to ma zostać uspójnione.

class Base {
    // ...
}

class Derived extends Base {
    someProperty = true;

    constructor() {
        // previously: error! have to call 'super()' first because it needs to initialize 'someProperty'.
        doSomeStuff();
        super();
    }
}

Druga interesująca zmiana też jest w pewnym stopniu naprawą istniejącego już błędu. Gdy kompilator sprawdza czy dwa typy mogą zostać do siebie przypisane, to przy osiągnięciu odpowiedniego poziomu rekurencji zakłada on, że typy są kompatybilne. Mimo, że na pierwszy rzut oka wygląda to przerażająco, po głębszym zastanowieniu logika ta ma oczywiście sporo sensu. Ze względu na zastosowanie strukturalnego typowanie,  niemożliwe jest porównanie definicji obiektów, co stanowi wyzwanie w sytuacji, gdy poprzez odpowiednie zastosowanie generyków da się zdefiniować klasę o nieskończonej definicji. Usprawnienie, które przygotował Microsoft nie rozwiązuje całkowicie problemów strukturalnego typowania, ale sprawia że TypeScript w niektórych przypadkach będzie w stanie wykryć niekompatybilności pomiędzy dwoma bardzo zagnieżdżonymi typami.

interface Source<T> {
    prop: Source<Source<T>>;
}

interface Target<T> {
    prop: Target<Target<T>>;
}

function check(source: Source<string>, target: Target<number>) {
    // Resolving those types structure will result in an infinite loop. 
    // Because of that compiler uses depth heuristic
    target = source;
}

interface Foo<T> {
    prop: T;
}

declare let x: Foo<Foo<Foo<Foo<Foo<Foo<string>>>>>>;
declare let y: Foo<Foo<Foo<Foo<Foo<string>>>>>;

// In TypeScript 4.5 this will work ok. In TypeScript 4.6 compiler will return error
x = y;

Ostatnią interesującą nowością jest lepsze wsparcie dla typów zależnych. Co tu dużo mówić, mała rzecz, a cieszy.

type Func = (...args: ["a", number] | ["b", string]) => void;

const f1: Func = (kind, payload) => {
    if (kind === "a") {
        payload.toFixed();  // 'payload' narrowed to 'number'
    }
    if (kind === "b") {
        payload.toUpperCase();  // 'payload' narrowed to 'string'
    }
};

f1("a", 42);
f1("b", "hello");

Tak jak wspominałem już przy okazji premiery wersji beta TypeScript 4.6, kolejne wydania tego języka od jakiegoś czasu ekscytują mnie coraz mniej. Nie odbieram tego jednak negatywnie, bo świadczy to o dojrzałości jaką udało mu się osiągnąć.

Źródła:

Announcing TypeScript 4.6

3. React 18 Release Candidate

React 18 zbliża się wielkimi krokami bo w minionym tygodniu ukazała się jego pierwsza wersja RC. Dokładnej analizy nowych funkcjonalności możecie spodziewać się przy okazji wydania stabilnej wersji. Tymczasem wspomnę tylko, że jest na co czekać, bo do nowego Reacta zmierzają zmiany do Server Renderig API, usprawniony batching renderowania przy zmianie stanu oraz nowe API dla zewnętrznych bibliotek. No i React wreszcie porzuca również wsparcie dla IE11. Trzymam tylko kciuki, że faza RC potrwa krócej niż beta, która trwała ponad 5 miesięcy.

Źródła:

https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

4. Nowe szaty MDN Docs

Najpopularniejsza dokumentacja JavaScript nieco ponad tydzień doczekała się wizualnego odświeżenia. Oprócz zupełnie nowego ostylowania strony, usprawniona została również nawigacja oraz zaprezentowane zostało nowe logo. Jednym zaprezentowane zmiany przypadły do gustu, inni natomiast twierdzą, że jest to krok w tył. Wszyscy jednak zgadzamy się, że dodanie wsparcia dla ciemnego motywu to tak zwany killer feature.

Trochę obok nowej warstwy wizualnej zapowiedziany został MDN Plus, czyli płatna subskrypcja w ramach której dostępne będą dodatkowe funkcjonalności. Na razie nie wiadomo jakie będą to funkcjonalności, ale ja z ciekawością będę śledził na jakie pomysły wpadł zespół MDN.

Źródła:

https://hacks.mozilla.org/2022/03/a-new-year-a-new-mdn/