Frontend Thursday vol. 41

1. Plany dla React 18

Jeśli porównać ilość treści z oficjalnych kanałów Angulara i Reacta, to nie sposób nie uznać, że to właśnie framework od Google rozwija się ostatnio prężniej. Jeśli natomiast przyjrzeć się sprawie głębiej to okazuje się, że publikacje dotyczące Reacta pojawiają się rzadziej, ale jak już się pojawiają to zazwyczaj są to niezłe bomby. Nie inaczej jest i tym razem, bo po nijakim React 17, w tym tygodniu ogłoszona została alfa Reacta 18, a wraz z nią kilka naprawdę ciekawych nowości.

Autor Frontendowego Czwartku dowiadujący się, że po pół roku posuchy w środowisku Reacta wydarzyło się coś ciekawego

Zanim przejdziemy do konkretów zatrzymajmy jeszcze się na chwilę przy zmianach dotyczących community i rozwoju biblioteki. Nowej wersji Reacta towarzyszy powstanie React Working Group, które to ma być przestrzenią do komunikacji między społecznością, a ludźmi stojącymi za implementacją nowych funkcjonalności. Dyskusje odbywać się będą w ramach Github Discussions i na ten moment skupiają się one wokół ogłoszonej właśnie wersji alfa.

Przeglądałem sobie pobieżnie dyskusje toczące się na React Working Group i muszę przyznać, że na ten moment ciężko tam znaleźć pytania bez odpowiedzi, a w większości wątków udzielają się znane nazwiska ze środowiska

Co ciekawego znajdziemy w nowym Reactie? Lista nowości jest krótka (blogpost ogłaszający alfę skupia się tylko na trzech), dlatego postaram się pokrótce przyglądnąć im wszystkim. Zacznijmy od zmiany, która zaskoczyła mnie w negatywny sposób, bo byłem pewny, że React od dawna posiada taką funkcjonalność. Jak się okazuje, do tej pory React był w stanie zagregować kilka aktualizacji stanu w jednym renderze, ale tylko jeśli były one wywołane w ramach obsługi przeglądarkowych zdarzeń. Oznacza to, że jeśli wewnątrz setTimeout lub then wywoływaliście dwa setState to skutkowało to dwoma renderami. No cóż, na szczęście od wersji 18 domyślnie wszystkie aktualizacje będą grupowane, a poprzednie zachowanie wymusić będzie można poprzez opakowanie setState w flushSync.

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);
  function handleClick() {
    fetchSomething().then(() => {
      setCount(c => c + 1); // In React 17 this causes a re-render
      setFlag(f => !f); // In React 17 this causes a re-render
      // React 18 and later will only re-render once at the end (that's batching!)
    });
  }
  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h2 style={{ color: flag ? "blue" : "black" }}>{count}</h2>
    </div>
  );

Kolejna nowość na szczęście zaskakuje w dużo bardziej pozytywny sposób. Nowa metoda startTransition umożliwia zgrupowanie zmian, które wymagają skomplikowanego re-renderu i wykonania ich nie blokując interakcji użytkownika ze stroną. Co ciekawe jeśli startTransition zostanie wywołane po raz kolejny zanim poprzednie wywołanie zostanie zakończone to React automatycznie anuluje tą starszą tranzycję.

import { startTransition } from 'react';
// Urgent: Show what was typed
setInputValue(input);
// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setSearchQuery(input);
});

Na koniec zostawiłem sobie moim zdaniem największą bombę, czyli wsparcie Suspense w SSR. Jak ma to działać? Do tej pory SSR odbywał się w następujących synchronicznych krokach: załaduj potrzebne dane, wyrenderuj HTML i prześlij go do przeglądarki, załaduj JavaScript, włącz JavaScript z załadowanym HTML’em. W takim modelu wolno odpowiadające API, lub spory bundle JavaScriptu powodował opóźnienia dla użytkownika. Od React 18, wykorzystując Suspens będziemy mogli podzielić nasze strony na mniejsze części, dla których cykl ten odbywał się będzie niezależnie. Oznacza to, że przykładowo wolne API do wczytywania komentarzy nie spowolni pojawienia się treści artykułu, a spory bundle dotyczący paska nawigacji nie odsunie w czasie momentu, kiedy sekcja komentarzy stanie się interaktywna.

<Layout>
  <NavBar />
  <Suspense fallback={<BigSpinner />}>
    <Suspense fallback={<SidebarGlimmer />}>
      <Sidebar />
    </Suspense>
    <RightPane>
      <Post />
      <Suspense fallback={<CommentsGlimmer />}>
        <Comments />
      </Suspense>
    </RightPane>
  </Suspense>
</Layout>

Muszę przyznać, że przez ostatnie miesiące trochę szyderczo patrzyłem na tempo rozwoju React. Teraz React jednym blogpostem sprawił, że czuję się głupio bo przeglądając nowości dotyczące Angulara z perspektywy czasu zdają się jakoś wyjątkowo… błahe.

Źródła:

https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html
https://github.com/reactwg/react-18/discussions/21
https://github.com/reactwg/react-18/discussions/41
https://github.com/reactwg/react-18/discussions/37
https://github.com/reactwg/react-18

2. Safari ogłasza wsparcie dla WebExtensions

W minionym tygodniu miało miejsce WWDC, czyli małe święto wszystkich kochających urządzenia z jabłkiem. Co prawda nie zapowiedziano oczekiwanych przez wszystkich nowych procesorów z serii M, ale pojawiło się kilka ciekawych ogłoszeń (o których więcej będziecie mogli przeczytać zapewne w naszej sobotniej edycji przeglądu). Te które interesują nas najbardziej to oczywiście zmiany zmierzające do Safari i WebKita.

Bez tego Pana konferencja Apple to już nie to samo, ale trzeba przyznać, że od jakiegoś czasu przed każdy ich eventem internet zapiera oddech w oczekiwaniu na to co zostanie pokazane

Wśród ogłoszonych nowości szczególnie wybija się dodanie w Safari wsparcia dla WebExtenstion. Nie byłoby w tym nic zaskakującego, gdyby nie fakt, że nowy format rozszerzeń w odróżnieniu od obecnego AppExtensions, dostępny będzie również na iPhonach i iPadach. Jest to o tyle ciekawe, że kilka dni po zapowiedzi ze strony Apple, powstało WebExtensions Community Group Charter, w którego składzie znajdziemy ludzi zarówno z Apple jak i Google i które to odpowiedzialne będzie za wypracowanie wspólnego API. Jeśli WebExtensions pojawią się wkrótce w Chrome to być może po raz pierwszy możliwe będzie tworzenie między przeglądarkowych rozszerzeń. A, no i dla użytkowników Safari współdzielenie rozszerzeń między urządzeniami brzmi jak feature, który może w końcu skłoni mnie do spróbowania tej szatańskiej przeglądarki.

Jeśli chodzi o pozostałe nowości to raczej ciężko doszukać się tutaj już większych sensacji. Mamy tutaj trochę usprawnień dla automatycznego uzupełniania haseł, trochę usprawnień dla WebAssembly i generalnie całkiem długą listę drobnych nowości. Pełne release notes Safari znajdziecie poniżej, a ja jeśli miałbym wskazać najbardziej oczekiwane przeze mnie zmiany to byłyby to wsparcie dla aspect-ratio i top level await. No cóż, nie bez przyczyna Safari nazywane jest współczesnym Internet Explorerem 😉