Signal - nowy sposób na zarządzanie stanem aplikacji - Frontend Weekly vol. 104

1. Signals – nowa biblioteka do zarządzania stanem aplikacji od twórców Preact

Obserwując ilość dostępnych bibliotek, dyskusji i opinii na temat zarządzania stanem aplikacji w Reactie, można odnieść, że jest to swego rodzaju fetysz tej społeczności. W tym tygodniu mamy coś specjalnego dla wszystkich fanatyków stanu aplikacji – nową bibliotekę od twórców Preacta.

Nowa biblioteka nazywa się Signals. Jeśli gdzieś z tyłu głowy świta Wam, że gdzieś już to słyszeliście, to macie rację. SolidJS, czyli alternatywa dla Reacta bez Shadow DOM, zamiast `useState` posługuje się właśnie `useSignal`. Signala z Preact i SolidJS łączy całkiem sporo, jednak zdecydowanie nie są to dwie tożsame koncepcje.

Zacznijmy jednak od motywacji twórców Preacta do stworzenia kolejnej biblioteki do zarządzania stanem. Jak to zwykle bywa, wszystkie dostępne na rynku rozwiązania nie zaspokajały potrzeb autorów biblioteki. Narzędzie takie jak Redux czy MobX wprowadzają sporo boilerplate’u, a ich wydajność jest dyskusyjna. Proste podejście z useState sprawdza się w początkowych etapach życia aplikacji, ale wraz z jej rozrostem zaczyna cierpieć na problemy z props-drilling i niewydajnym renderowaniem. Konteksty, które stają się w takim momencie naturalną alternatywą, również nie są idealne. Pozwalają co prawda “przeskoczyć” przez kilka poziomów VirtualDOM, ale ich liczba szybko rośnie, a odpowiednia optymalizacja wymaga zręcznego posługiwania się memonizacją.

Signal w swojej koncepcji jest pewnym pudełkiem na wartość. Kiedy wartość w pudełku zmienia się, automatycznie aktualizowane są wartości we wszystkich pudełkach zależnych. Proces powtarza się, aż wszystkie pudełka zostaną zaktualizowane. Na pierwszy rzut oka bardzo przypomina to połączenie useState i useEffect, ale zwróćcie uwagę, że sygnał definiowany jest globalnie. Umożliwia to w momencie zmiany wartości w pudełku, odświeżenie tylko tych komponentów w VirtualDOM, które od niego zależą.

import { signal, computed } from "@preact/signals";

const count = signal(0);
const double = computed(() => count.value * 2);
effect(() => console.log(double.value)));

function Counter() {
  return (
    <button onClick={() => count.value++}>
      {count} x 2 = {double}
    </button>
  );
}

To oczywiście jeszcze nie koniec zalet Signals. Na przestrzeni życia aplikacji, referencja sygnału nie zmienia się, więc nie musimy obawiać się niechcianych renderów. Zarówno funkcja `computed` jak i `effect` nie wymaga listy zależności i wykrywa je automatycznie. Co więcej, jeśli zależności ulegną zmianie, ale końcowa wartość pozostaje taka sama, dalsze zależności nie będą odświeżane.

Signals to biblioteka napisana w czystym JavaScript, ale jak widzieliście na przykładach powyżej, autorzy zadbali o przygotowanie specjalnych integracji zarówno z Preact jak i React. Szczególnie ciekawie prezentuje się ta pierwsza. Jeśli w JSX wykorzystamy signal, zamiast signal.value, to będzie on traktowany jako osobny komponent. To oznacza, że jeśli zmieni się jego wartość, Preact zamiast renderować cały komponent rodzic, odświeży tylko krótki fragment tekstu.

// In this example whole Counter component will be re-rendered on count change
const count = signal(0);

function Counter() {
 return (
    <>
       <SomeOtherComponent/>
       Value: {count.value}
    </> 
  );
}

// In this example only count value will re-render on count change
const count = signal(0);

function Counter() {
 return (
    <>
       <SomeOtherComponent/>
       Value: {count}
    </> 
  );
}

Jeśli zastanawiacie się, jak to możliwe, że cała ta magia działa, to wybrałem się w podróż do kodu źródłowego za Was. Signals to tak naprawdę prosta implementacja wzorca projektowego obserwator (ach te polskie nazwy

Na zakończenie mały bonus dla wszystkich Angularowców, którzy dotarli aż do końca tej sekcji. Kiedy twórcy Signals pisali, że biblioteka może być wykorzystywana z dowolnym frameworkiem, to naprawdę nie żartowali. Na twitterze dokopałem się do bajecznie prostej integracji z flagowym frameworkiem od Google. Dodanie do niej obsługi ChangeDetection.OnPush to zaledwie kilka linijek kodu i znajdziecie ją w pierwszej odpowiedzi wątku.

Źródło: https://twitter.com/ashh640/status/1567469254034825216?s=20&t=ayfvUBJOY9u9ie4s7VzTpQ

Źródła:

2. React Native 0.70 – Hermes wreszcie domyślny

O nowym, szybszym i lepszym silniku renderowania dla React Native słyszy się już od dawna. Po raz pierwszy został on zaprezentowany światu w połowie 2019 roku i dedykowany był dla telefonów z Androidem na pokładzie.

W Wiśle upłynęło sporo wody, zanim zespół Facebooka przygotował również wersję na system iOS. Wywołało to jednak małą furorę, bo było pierwszym przypadkiem kiedy na urządzeniach z jabłuszkiem działał silnik inny niż JavaScriptCore. Co więcej, działo się to za przyzwoleniem samego Apple.

Niespełna pół roku temu, zespół React Native ogłosił, że Hermes jest już na tyle stabilny, że wkrótce stanie się domyślnym silnikiem JavaScript dla ich frameworku. W tym tygodniu, wraz z premierą React Native 0.70, wreszcie doczekaliśmy tej historycznej chwili.

Pozostałe nowości w React Native 0.70 dotyczą głównie nowej eksperymentalnej architektury. Dla przypomnienia składają się na nią Turbo Modules (wydajna integracja z natywnym kodem), Fabric Renderer (nowy renderer, który ma ujednolicić działanie pomiędzy platformami) oraz Codegen (automatyczne generowanie niezbędnych plików C++). Wszystkich zainteresowanych szczegółami na pewno ucieszy fakt, że jedną z nowości jest zupełnie nowa dokumentacja.

W poszukiwaniu daty premiery nowej architektury przeczesałem zarówno dokumentację, jak i bloga React Native. Cóż, na razie wszystko wskazuje na to, że pozostanie ona jeszcze długo w fazie eksperymentalnej.

Źródło: https://devs.lol/meme/waiting-for-react-native-1-0-javascript-267

Źródła:

https://reactnative.dev/blog/2022/09/05/version-070

3. Uwolnić JavaScript! – list otwarty twórcy Node.js i Deno

Historia JavaScript jest szalona i pełna zawirowań. Zwłaszcza jej początki i legenda o stworzeniu całego języka w 10 dni. Na pewno nie raz już ją słyszeliście, ale i tak nie odmówię sobie jej przytoczenia.

Jest rok 1995 i Brendan Eich pracuje właśnie w Netscape. W wolnym czasie lubi on projektować swoje własne, proste języki programowania. Pewnego dnia w pracy dostaje szansę wykorzystać doświadczenie zdobyte po godzinach i dostaje zadanie stworzenia języka skryptowego na potrzeby flagowego produktu firmy. Na wykonanie zadania dostaje zatrważające 10 dni, ale mimo wszystko zakasa rękawy i bierze się do roboty. W trakcie rozmowy przy kawie z jednym z kolegów z biura przyznaje, że jego język przetrwa kilka tygodni, albo 20 lat. No cóż, niewiele się pomylił.

Powiązania między Javą, a JavaScriptem również nie są przypadkowe. Lata dziewięćdziesiąte to okres, kiedy programowanie w Javie było cool, a programiści C++ z utęsknieniem patrzyli na projekty pisane właśnie w obiektowej Javie. Pod modę na Javę chciał się podpiąć również Netscape ze swoim nowo powstałym językiem. Miał on nie tylko przypominać Javę, ale również jego nazwa powinna kojarzyć się od razu z najbardziej pożądanym językiem na rynku. W ten sposób narodził się JavaScript.

Jak wiemy, historia sukcesu Netscape nie trwała długo. W 1999 roku firma Netscape połączona została z firmą America Online (AOL). Po zakończeniu procesu połączenia, firma weszła również w ścisłą współpracę z Sun Microsystems. W 2002 roku współpraca została zakończona, a w wyniku zawirowań znak towarowy JavaScript pozostał w rękach Sun Microsystem. W 2009 roku firma ta została skolei kupiona wraz ze znakiem towarowym przez Oracle.

Na dzień dzisiejszy Oracle nie wykorzystuje nigdzie znaku towarowego JavaScript. Firma nie uczestniczy również aktywnie w jego rozwoju w ramach ECMAScript. To właśnie do tego faktu odnosi się w głównej mierze argumentacja Ryan Dahla, w jego otwartym liście do Oracle. Prosi on w nim o zmianę licencji znaku towarowego JavaScript i przekazanie go w ręce społeczności. Gdyby tak się wydarzyło ECMAScript mógłby wreszcie stać się po prostu JavaScriptem lub JavaScript Standard Committee. Ciężko nie zgodzić się, że znacząco uprościłoby to całą sytuację nazewniczą. Jeśli jesteście zainteresowani, to oryginalną treść listu znajdziecie w źródłach poniżej.

Signal – nowy sposób na zarządzanie stanem aplikacji – Frontend Weekly vol. 104

1. Signals – nowa biblioteka do zarządzania stanem aplikacji od twórców Preact

Źródła:

2. React Native 0.70 – Hermes wreszcie domyślny

Źródła:

3. Uwolnić JavaScript! – list otwarty twórcy Node.js i Deno

Źródła:

Odkryj więcej świetnych treści!