Frontend Thursday vol. 83 - Typescript 4.7 beta, Ladle

1. TypeScript 4.7 beta

Release Trains to jedna z lepszych rzeczy jakie przydarzyły się środowisku IT. Rzadkie releasy i skomplikowane migracje zastąpiliśmy częstymi wydaniami wymagającymi minimalnych zmian w kodzie. To wszystko prawda, ale jestem ciekaw ilu z Was było przed przeczytaniem nagłówka tej sekcji powiedzieć jaki numerek ma najnowsza obecnie wersja TypeScript i jakie przyniosła nowości. No cóż, w życiu tak już czasem bywa, że pełne ekscytacji i przygód życie w poszukiwaniu stabilności zamieniamy na umiarkowanie ciekawą codzienność.

TypeScript 4.6 ukazał się zaledwie półtora miesiąca temu, a kilka dni temu światło dzienne ujrzała beta TypeScript 4.7. Próbowałem przypomnieć sobie nowości jakie wniosło poprzednie duże wydanie, ale poległem z kretesem. Na szczęście w 73 edycji naszego przeglądu znalazłem odpowiedź (usprawniono rozwijanie rekurencyjnych typów i dodano możliwość wykonania kodu w konstruktorze przed super) i wcale nie dziwi mnie, że już wtedy ziewałem z nudy.

Nie popadajmy jednak w marazm i z nadzieją spójrzmy na nowości jakie przynosi TypeScript 4.7. Największą ze wszystkich jest chyba wsparcie dla ECMAScript Module w Node.js. Moduły w JavaScript to prawdziwa góra lodowa, dlatego wszystkim, którzy nie są zaznajomieni z tematem polecam film od Przeprogramowanych poświęcony w całości temu zagadnieniu.

Co składa się na wsparcie dla ECMAScript Modules? Przede wszystkim do tsconfig.json i package.json trafiają nowe pola, które decydować będą o tym w jaki sposób traktowane są importy w danym module. Do tego dochodzi wsparcie dla plików `.mts` i `.cts`, które kompilowane będą odpowiednio do plików `.mjs` i ‘.cjs`. Oczywiście jak zawsze w przypadku modułów, temat jest dużo bardziej złożony, dlatego wszystkich zainteresowanych szczegółami odsyłam do notki Microsoftu.

Nowa edycja TypeScript jak zwykle przynosi również drobne usprawnienia inferencji typów. Wersja 4.7 będzie lepiej radzić sobie z analizą przepływu kodu, dzięki czemu w wielu przypadkach będzie w stanie zawęzić inferowane typy Usprawniona została również inferencja typów metod w obiektach.

declare function f<T>(arg: {
    produce: (n: string) => T,
    consume: (x: T) => void }
): void;

// Works
f({
    produce: () => "hello",
    consume: x => x.toLowerCase()
});

// Works
f({
    produce: (n: string) => n,
    consume: x => x.toLowerCase(),
});

// Was an error, now works.
f({
    produce: n => n,
    consume: x => x.toLowerCase(),
});

// Was an error, now works.
f({
    produce: function () { return "hello"; },
    consume: x => x.toLowerCase(),
});

// Was an error, now works.
f({
    produce() { return "hello" },
    consume: x => x.toLowerCase(),
});

Kolejną nowością jest wprowadzenie Instantiation Expressions, które w zwięzły sposób pozwalają zawęzić typ danej funkcji, czy klasy. Ciężko to wytłumaczyć, więc po prostu zerknijcie na przykład poniżej:

interface Box<T> {  value: T; }

function makeBox<T>(value: T) {
    return { value };
}

// In TypeScript 4.6
const makeStringBox: (string: string) => Box<string> = makeBox;

// In TypeScript 4.7
const makeStringBox = makeBox<string>;

makeStringBos(42); // TypeScript correctly rejects this.

Na koniec zostawiłem sobie prawdziwą bombę: wariancja typów. Nie wchodząc w szczegóły, wariancja w przypadku generycznych typów pozwala określić czy dane typy mogą zostać do siebie przypisane na podstawie struktury dziedziczenia ich generycznych parametrów. Dogłębne wytłumaczenie jak działa wariancja zdecydowanie nie mieści się w formule naszych przeglądów, dlatego zainteresowanych odsyłam do dokumentacji Kotlina, który zdecydował się na taką samą nomenklaturę jak TypeScript (czyli słowa kluczowe in i out). Po co nam wariancja w strukturalnie typowanym języku? Na chłopski rozum, wszystkie typy można rozwinąć i porównać. Jak się okazuje, w przypadku skomplikowanych zagnieżdżonych typów sprawdzenie wariancji będzie znacznie szybsze niż ich rozwijanie.

interface Animal {
    animalStuff: any;
}

interface Dog extends Animal {
    dogStuff: any;
}

type Getter<out T> = () => T;
type Setter<in T> = (value: T) => void;

let animalGetter: Getter<Animal>;
let dogGetter: Getter<Dog>;
animalGetter = dogGetter; // This will work
dogGetter = animalGetter; // This will throw an error

let animalSetter: Setter<Animal>;
let dogSetter: Setter<Dog>;
animalSetter = dogSetter; // This will throw an error
dogSetter = animalSetter; // This will work

Czy TypeScript mnie zawiódł? Wyjątkowo wydaje się, że wydanie 4.7 będzie jednym z bardziej interesujących. Z ostatecznymi wyrokami poczekajmy jeszcze do momentu, kiedy pewne będzie czy wszystkie przedstawione tutaj funkcjonalności dotrą do stabilnej wersji.

Źródła:

https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/
https://kotlinlang.org/docs/generics.html
https://www.youtube.com/watch?v=5upaxzBNbmQ&t=12s

2. Leniwy Storybook i alternatywy

W ostatnich tygodniach Storybook doczekał się wreszcie sensownej alternatywy w postaci projektu Ladle. Narzędzie to jest alternatywą typu “Drop-In” (to znaczy, że nie powinno wymagać od Was żadnych zmian w istniejących storiesach) i chwali się między innymi 20x mniejszą paczką wynikową i 10x szybszym startem w trybie developmentu. Lepszy performance osiągnięto dzięki wykorzystaniu nowoczesnych narzędzi do budowania aplikacji takich jak Vite i Rollup. Wady? Na ten moment Ladle wspiera tylko Reactowe projekt i jeśli podczas konfiguracji Storybooka grzebaliście w konfiguracji Webpacka to migracja może nie wyglądać tak kolorowo.

Całe szczęście Storybook nie stoi w miejscu i również nieustannie pracuje nad poprawą wydajności. W wersji 6.4 (o której w szczegółach pisaliśmy w 66 edycji naszego przeglądu) dodane zostało wsparcie dla code splitting, co znacząco przyspieszyło początkowe ładowanie. Do wersji 6.5 trafi natomiast Lazy Compilation, co zwiastuje prawdziwą rewolucję jeśli chodzi o Developer Experience. Poprzez kompilację jedynie wymaganych do wyrenderowania obecnego widoku komponentów czas do zobaczenia pierwszego story zmalał 4x. Ponadto dzięki odpowiedniemu zastosowaniu cache’y kolejne buildy są jeszcze 2x szybsze.