Frontend Thursday vol. 55

1. TC39 obraduje na temat pipeline operator

Lubicie czasem pokłócić się o coś, co może nigdy nie osiągnąć statusu produkcyjnego? Jeśli tak, to trafiliście w dobre miejsce. W minionym tygodniu w sieci rozgorzała dyskusja na temat nowego pipeline operatora, który przebił się do drugiego etapu procesu TC39 (jeśli nie kojarzycie TC39 to polecam ten artykuł, natomiast w telegraficznym skrócie proces składa się z 4 etapów i może ciągnąć się naprawdę długo). Nowa składnia ma oferować natywne łańcuchowe łączenie funkcji, z którym do tej pory deweloperzy radzili sobie poprzez funkcję pipe.

// prosta implementacja funkcji pipe, jaką możecie spotkać obecnie w niektórych bibliotekach
function pipe(initialArg, ...fns) {
  return fns.reduce((prevValue, fn) => fn(prevValue), initialArg);
}
 
const result = pipe(
  2,
  (x) => x ** 2,
  (x) => x - 1,
);

// Propozycja nowej składni
const result = 2 |> ^ ** 2 |> ^ - 1;

// Propozycja nowej składni z wykorzystaniem funkcji
const result = 2
  |> squared(^)
  |> subtractOne(^);

// A tak w nowej składni wyglądałby RxJS
source$
  |> filter((x) => x % 2 === 0)(^)
  |> map((x) => x * x)(^)
  |> concatMap((x) => of(x + 1, x + 2, x + 2, x + 4))(^)
  |> ^.subscribe(console.log);

Skąd wzięły się dyskusje wokół tego tematu? Otóż pipeline operator można zaimplementować używając jednej z dwóch składni. Ta która trafiła do drugiego etapu to Hack Pipeline, natomiast wersja odrzucona przez TC3 potocznie nazywana jest na część języka z którego się wywodzi F# Pipeline. Alternatywna składnia zamiast wykorzystywać ^, niejawnie przekazuje wynik poprzedniej funkcji jako ostatni argument do kolejnej. Takie zachowanie umożliwia łatwiejszą migrację dla bibliotek samodzielnie implementujących metodę pipe (jak wspomniany wcześniej RxJS) i pozwala na wykorzystanie powszechnie używanych arrow functions.

// Operator pipe w składni znanej z F#
const result = 2
  |> (n) => n ** 2
  |> (n) => n - 1;

const result = 2
  |> squared
  |> subtractOne

source$
  |> filter((x) => x % 2 === 0)
  |> map((x) => x * x)
  |> concatMap((x) => of(x + 1, x + 2, x + 2, x + 4))
  |> result$ => result$.subscribe(console.log);

Przeglądając internetowe opinie mam wrażenie, że szala opinii przechyla się w stronę rozwiązania przyjętego przez TC39, ale zdecydowanie nie jest to trywialny temat. Jeśli jesteście zainteresowani dogłębną analizą wad i zalet poszczególnych implementacji to odsyłam Was do artykułu twórcy RxJS, który znajdziecie w źródła (fragmenty kodu, które widzicie powyżej pochodzą właśnie stamtąd).

Szczerze mówiąc obie składnie są dla mnie akceptowalne – jako wielbiciel programowanie funkcyjnego chciałbym wreszcie po prostu zobaczyć pipeline operator w oficjalnej specyfikacji. No i dobrze zobaczyć, że TC39 obraduje też nad czymś więcej niż kolejne metody do formatowania dat.

Autor Frontendowego Czwartku, kiedy dowiedział się, że TC39 Meeting obradowało na temat czegoś ciekawego. Przysięgam, tak było 😀

Źródła:

https://benlesh.com/posts/tc39-pipeline-proposal-hack-vs-f-sharp/

2. Node 16.9.0 umożliwi korzystanie z pnpm i yarn bez instalacji

Kilka dni temu doczekaliśmy się kolejnej wersji minor Node.js. Nie byłoby w tym pewnie nic interesującego, gdyby nie pojawienie się eksperymentalnego menadżera menadżerów pakietów nazwanego Corepack. Jego zadaniem jest wykrywanie na podstawie pola “packageManager” w package.json odpowiedniego menedżera pakietów, zainstalowanie go i przekazywanie do niego komend użytkownika. Jak tłumaczą twórcy zachowanie to ma uspójnić menadżery pakietów z jakich korzystają deweloperzy w jednym zespole i wyeliminować bugi wynikające z drobnych różnic między zachowaniem poszczególnych narzędzi. Co ciekawe obecnie Corepack wspiera yarn i pnpm, ale nie wspiera samego npm.

Pakiety w npm to prawdziwa korporacja skoro menadżery mają swoich menedżerów. Pytanie tylko, czy nie poszło to o krok za daleko?

W naszym zespole jawnie podzieleni jesteśmy na użytkowników yarn i npm i do tej pory nie sprawiło nam to większych trudności. Ciężko jednak zaprzeczyć, że zamrażanie zależności jest dobrą praktyką i nikomu jeszcze nie zaszkodziło. Szkoda tylko, że Node do tej pory nie oferuje natywnego rozwiązania do zarządzania wersją środowiska uruchomieniowego.

Źródła:

https://nodejs.org/en/blog/release/v16.9.0/?fbclid=IwAR3A_JmfNyP5P_vGsA-SIMM8tyNXK9I9FHcIVHZLy70mao1et8YX0HyKt4A

3. Nowy progresywny format obrazów od Google: JPEG XL

Jak to mówią, tydzień bez Data Science to tydzień stracony! Tym razem mamy dla Was nowy format obrazów zaproponowany przez Google.a on wykorzystywać sztuczną inteligencję, aby przyspieszyć ładowanie zdjęć. Dzięki wykorzystaniu sieci neuronowej możliwe jest wykrycie, na które części zdjęcia w pierwszej kolejności będzie patrzył użytkownik. Znalezione miejsca ładowane są od razu z dużym poziomem szczegółowości, a pozostała część doładowywane jest później. Demo zaprezentowane przez Google wygląda imponująco, ale patrząc na tempo adaptacji progresywnych obrazów w Firefox i Safari możemy jednak przewidywać, że JPEG XL nieprędko stanie się powszechnie obsługiwany (o ile kiedykolwiek do tego dojdzie).