Frontend Thursday vol. 92 – Reassure, JoyUI, Components Encyclopedia

1. Reassure – testy wydajności komponentów zrobione dobrze

Na pewno chociaż raz zdarzyło Wam się optymalizować niewydajny komponent. Jeśli macie szczęście, to proces ten zaczął się od wykrycia regresji w Lighthouse odpalanym na continuous integration. Jeśli macie trochę mniej szczęście, to słaba wydajność została zgłoszona przez manualnych testerów, lub co gorsza użytkowników. W tym momencie zwykle zaczyna się praca pod presją czasu. Najpierw szukamy zepsutego komponentu, potem pracujemy nad szybką naprawą i czym prędzej robimy release. Co bardziej skrupulatni do Pull Requesta dołączą screenshot z wynikami Lighthouse. W znaczącej większości przypadków pod presją czasu zabraknie nawet tego – nie mówiąc już o dodaniu testów regresji, czy przygotowaniu dokładnego raportu na temat wydajności. A co, jeśli powiedziałbym Wam, że możemy uniknąć podobnych regresji wydajności? 

Reassure, to nowa biblioteka do pisania testów wydajności Reactowych komponentów. Jej API mocno przypomina to znane z k6 – narzędzie do tworzenia testów wydajności REST-owych serwisów. Zaczynamy od definicji scenariusza interakcji z komponentem, a następnie odpowiednio konfigurujemy test runner (liczba pętli itp.). Potem zostaje już tylko odpalić test i obserwować wyniki.

test('Count increments on press', async () => {
  const scenario = async (screen: RenderAPI) => {
    const button = screen.getByText('Action');
    
    await screen.findByText('Count: 0’);
    fireEvent.press(button);
    fireEvent.press(button);
    await screen.findByText('Count: 2');
  };

  const stats = await measureRender(
    <Counter />, 
    { scenario, runs: 20 }
  );
  await writeTestStats(stats);
});

Reassure będzie można wpiąć w pipeline continuous integration i zdefiniować budżety wydajnościowe lub porównywać wyniki z poprzednimi wersjami komponentu. Zakładając wysokie pokrycie testami, o spadku wydajności dowiemy się już z PR wprowadzającego regresją. Ponadto continuous integration od razu wskaże nam zepsuty komponent, a winowajców szukać będziemy tylko w kodzie z danego Pull Request

W przedstawionej w poprzednich akapitach beczce miodu jest jednak łyżka dziegciu – wysokie pokrycie testami wydajności. Koszt pisania i utrzymywania dużej ilości testów może okazać się naprawdę wysoki. Mimo wszystko dla Reassure widzę sporo zastosowań. Zazwyczaj w aplikacji możemy wyznaczyć krytyczne komponenty i to stworzyć testy tylko dla nich. Ponadto liczę też, że Reassure stanie się moim bazowym narzędziem do pracy nad optymalizacją. Używanie skomplikowanych DevTools i manualne wyklikiwanie flow użytkownika nie są ani najbardziej optymalnym, ani najbardziej reprodukowanym sposobem mierzenia wydajności.

Na ten moment Reassure jest w zamkniętej becie, ale w najbliższych tygodniach projekt ma przejść na model Open Source. Mocno trzymam kciuki, zwłaszcza, że za biblioteką stoi polski software house callstack (jeśli któryś z autorów biblioteki to czyta – dobra robota!).

Źródła:

https://www.callstack.com/open-source/reassure

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. Joy UI – Material UI bez Material Design

MUI (dawniej Material UI), to chyba najpopularniejsza biblioteka komponentów dla Reacta. Jej największą wadą (i równocześnie zaletą) jest implementacja języka projektowania Material Design (kocham te spolszczenia ❤️). Tak długo jak interesowało Was podążanie za wytycznymi Google, Material UI sprawdzał się doskonale. Niestety kiedy interesowało nas stworzenie własnej biblioteki komponentów czekała nas droga przez mękę. Było to możliwe, ale ilość tworzonej konfiguracji nakazywała powątpiewać, czy na pewno jest to dobra droga.

Joy UI ma być Material UI, ale bez Material Design. Patrząc na API obie biblioteki wyglądają wręcz bliźniaczo podobnie. Mamy tu więc do czynienia z wszystkim co najlepsze w Material UI (API, Acessability) bez tego co nadmiarowe (Material Design).

<Box sx={{
   p: 2,
   pb: 1,
   display: 'flex',
   alignItems: 'center',
   justifyContent: 'space-between         
}}>
  <Typography
    fontSize="xs2"
    textColor="text.tertiary"
    textTransform="uppercase"
    letterSpacing="md"
    fontWeight="lg"
  >
  Filter by
  </Typography>
  <Button size="sm" variant="plain" sx={{ fontSize: 'xs', px: 1 }}>
    Clear filters
  </Button>
</Box>

Niestety Joy UI, na razie jest we wczesnej alfie i stabilnego wydania ma doczekać się dopiero w drugiej połowie 2022. Ja czekam niecierpliwie, bo nie tak dawno rozważaliśmy użycie MUI w jednym z projektów, ale ostatecznie z niego zrezygnowaliśmy właśnie przez trudność z nadpisaniem zachowań zdefiniowanych w Material Design.

Źródła:

https://mui.com/blog/first-look-at-joy/

3. Encyklopedia komponentów od Storybook

Wzmianki o Storybooku pojawiają się w naszych przeglądach dosyć regularnie i już nie raz wspominałem, że osoba odpowiedzialna za ich marketing powinna dostać podwyżkę (statystycznie częściej piszę o Storybook, niż o React!). W tym tygodniu firma ogłosiła powstanie wielkiej encyklopedii komponentów i ponownie informacja ta rozeszła się po frontendowym internecie dosyć szeroko. 

W encyklopedii zebranych zostało ponad 5000 komponentów, w tym część od takich firm jak GitHub, BBC czy Audi. Spora część z zebranych komponentów linkuje również kod źródłowy. Jeśli kiedyś będziecie szukać  inspiracji, czy to wizualnych, czy nazewniczych, to już wiecie gdzie szukać.

W minionym tygodniu na blogu Storybooka ukazał się jeszcze jeden bardzo ciekawy wpis – krótki wywiad z Bradem Frostem. W artykule twórca Atomic Design dzieli się z nami jego odpowiedzią na pytanie: dlaczego większość prób stworzenia design systemu kończy się fiaskiem. Jeśli szukacie krótkiej, ale ciekawej lektury na długi weekend to mocno polecam.

Źródła:

https://storybook.js.org/blog/component-encyclopedia/

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. Fastify v4

Pomimo tego, że prasówka ta nazywa się “Frontend Thursday”, to staram się tutaj również przemycać najważniejsze nowości z backendowej części JavaScriptu. Podobnie będzie i tym razem, bo kilka dni temu doczekaliśmy się fastify 4.0. Na nową wersję biblioteki  czekaliśmy prawie 2 lata i niestety nie doczekaliśmy się większych rewolucji. Nowości to z mojej perspektywy przede wszystkim drobne usprawnienia, ale liczę na to, że ktoś wyprowadzi mnie z błędu. Jeśli jesteście ciekawi co dokładnie się zmieniło, to w źródłach znajdziecie notkę towarzyszącą wydaniu.

PS: Jeśli do tej pory o fastify nie słyszeliście, to polecam Wam ten artykuł, z którego dowiecie się dlaczego szybko powinniście nadrobić braki i dlaczego express jest już pieśnią przeszłości.

Źródła:

https://medium.com/@fastifyjs/fastify-v4-ga-59f2103b5f0e