Frontendové zvesti #2

Dnes si prečítate, ako lepšie písať testy s Testing Library, k čomu je nástroj Testing Playground, že Vike už má v sebe čiastočnú podporu pre React Server Components, Remix a Vite je hotová vec a mali by ste plánovať upgrade. Nakoniec vám pri príležitosti vydania linuxovej verzie terminálu Warp dám zopár tipov aj na iné terminály a pri troche šťastia vás ukecám na vyskúšanie tmux-u.

Najlepšie spôsoby, ako písať testy s použitím Testing Library

Článok: https://claritydev.net/blog/improving-react-testing-library-tests

V prípade, že mám medzi čitateľmi niekoho, kto programuje frontend a ešte nepíše testy pomocou Testing Library, tak o veľa prichádza. Naozaj odporúčam sa na knižnicu pozrieť a čo najskôr ju zaradiť medzi svoje používané nástroje.

Testing Library je totiž knižnica, ktorú môžete jednoducho, rýchlo a bez zložitého nastavovania používať vo svojich Jest alebo Vitest testoch (ale aj v iných test runneroch) na overovanie správania vašich komponent. Pokiaľ používate Cypress alebo Playwright, tak vedzte, že Testing Library nie je ich náhradou, ale veľmi vhodným a rýchlejším doplnkom.

A teraz k článku. Alex Khomenko si dal tú prácu a na svojom blogu spísal tipy, ako by sa podľa neho mali písať testy pre Testing Library. Zameral sa síce na jej verziu pre React, ale všetko tam spomenuté platí aj pre iné UI knižnice.

Alex píše o tom, že pokiaľ sa len trochu dá, tak by sme mali elementy v komponente vyhľadávať pomocou *byRole funkcií (v nomenklatúre Testing Library sa týmto funkciám hovorí queries). Vďaka tomu si nepriamo otestujeme, či sú naše komponenty dobre navrhnuté aj z hľadiska prístupnosti a zároveň sa naučíme, ako ich správne vytvárať. A to je veľmi dôležité pre každého návštevníka, ktorý má s používaním nášho webu nejaké problémy (zrakové, ovládacie atď). Alex v článku ukazuje aj nejaké príklady zlých testov, ktoré následne upravuje.

Ďalej v článku rozoberá aj to, prečo by sme mali používať userEvent namiesto fireEvent. Hlavný dôvod je ten, že kým fireEvent len vyvolá udalosť pomocou API prehliadača, tak userEvent simuluje aj ďalšie veci, ktoré by sa udiali, keby udalosť vyvolával skutočný ľudský používateľ.

Pekné príklady Alex vytvoril aj pre návod, ako sa pomocou findBy* vieme zbaviť používania waitFor.

V článku je toho ešte viac, takže pokiaľ Testing Library používate, tak si ho bežte pozrieť a určite sa niečo nové naučíte.

Testing Playground

Webstránka: https://testing-playground.com/

Z Alexovho článku zmieňovaného vyššie som sa dozvedel o nástroji Testing Playground, ktorý nám pomôže s výberom vhodnej query na nájdenie elementu. Stačí do editora vložiť vygenerované HTML, pobehať myšou po náhľade a sledovať odporúčané query. Nástroj sa snaží preferovať *byRole funkcie, aby sme mali dobrú prístupnosť.

Vike má(?) podporu pre React Server Components

Stránka v dokumentácii: https://vike.dev/react

Kedysi, keď som potreboval pre svoje SPA aplikácie vo Vue.js alebo React-e pridať aj podporu pre rendrovanie na serveri (SSR) alebo generovať statickú stránku počas buildu (SSG), tak som na to používal plugin pre Vite nazývaný vite-pluggin-ssr. Už vtedy to nebol ani tak plugin, ako skôr nástroj na tvorbu vlastného frameworku pre ľubovoľnú rendrovaciu knižnicu. Medzičasom toho vie tento nástroj ešte viac a autori si to uvedomujú, tak projekt premenovali na Vike.

Keďže som postupne predsa len prešiel na Next.js, tak Vike už tak nesledujem, ale tento týždeň som zistil, že podporujú aj React Server Components. Z troch zložiek RSC majú síce podporu len pre dve: Server Actions a Progressive Rendering a aj z toho pre serverové akcie používajú Telefunc namiesto use server. Niet sa veľmi, čo čudovať. Autorom Telefunc-u je ten istý človek, ktorý stvoril Vike.

Ja som sa na Telefunc len rýchlo pozrel a musím povedať, že to nevyzerá zle. Je to menej magické, ako use server a tak aj jednoduchšie na pochopenie. Možno, keby autori React-u urobili podobné nemagické riešenie, tak by si ušetrili kopu negatívnych komentárov od komunity. Na druhej strane, keď už niekto pochopí, ako serverové akcie fungujú, tak vie, že use server je vlastne len syntax suggar pre niečo také, ako robí Telefunc.

Treťou zložkou RSC sú samotné serverové komponenty a tieto zatiaľ Vike nepodporuje, pretože podľa autorov ešte nie sú vhodné do produkcie (tie v React-e, nie vo Vike). Odporúčajú naďalej používať SSR, SSG a SPA a veria tomu, že malé výkonnostné zisky so serverovými komponentami nestoja za zložitejší programátorský zážitok (DX, Developer eXperience). Nuž, neviem. Mne sa zdá, že programátorský zážitok pred problémami používateľov uprednostňujeme posledných 15 rokov a už je na čase, aby sme hľadali používateľsky vhodnejšie riešenia a to aj za cenu (dočasne) zhoršeného DX.

Vite v Remix-e je stabilná vec

Oznámenie: https://remix.run/blog/remix-vite-stable

Remix je po Next.js asi druhý najpopulárnejší meta-framework pre React. A na rozdiel od Next.js si v Remix-e dávajú veľmi záležať na tom, aby podporovali štandardné webové API, správanie a štandardy celkovo. Pokiaľ vás štve, že Next.js poslednú dobu na štandardy kašle a niekedy ide vyslovene proti nim a máte slobodu zmeniť framework, tak pouvažujte nad Remix-om.

Remix tím 20. februára oznámil, že sa im podarilo dosiahnuť, aby bolo použite Remix-u spolu s Vite-om stabilné. Je to veľká vec, pretože od tejto chvíle budú všetky nové veci v Remix-e vyvíjané len pre Vite, dokumentácia sa bude postupne upravovať a Remix 3 bude podporovať iba Vite. Je teda čas si naplánovať upgrade.

V oznámení sa píše, že vďaka prechodu na Vite sa v Remix-e urobili nejaké nové architektonické rozhodnutia, alebo sa upravili staré a nevhodné. Menovite to je napríklad nový tzv. SPA mode, ktorý umožňuje vybuildiť celú Remix aplikáciu do statického tvaru, takže nepotrebujete JavaScript na serveri. Upravila sa konfigurácia pre basename, cieľové adresáre pre build a prišli nové spôsoby na oddeľovanie serverového a klientského kódu (.server priečinky, serverOnly$ makro na označovanie kusov kódu).

Noviniek je viac, v oznámení je každej venovaný vlastný priestor aj s linkami na prípadné detailnejšie informácie.

Warp terminál je už aj pre Linux

Oznámenie: https://www.warp.dev/blog/warp-for-linux

Toto nie je úplne frontendová novinka, ale keďže terminál je nástroj, v ktorom bežne pracujeme, tak som sa rozhodol ju sem zaradiť.

Na Mac-och už programátori mohli nejakú dobu používať terminál Warp, ktorý má príjemný a prívetivejší vizuál a to najmä pre začiatočníkov. Kombinuje terminálové rozhranie s rôznymi menu, dialógmi a comboboxami známymi z bežných aplikácií a tak pôsobí menej nepriateľsky pre "konzolovo-slabých" 😅. Okrem toho má skvelý nápovedný systém (Warp AI) a podporu pre niečo, ako bookmarkovanie príkazov.

Pokiaľ nemáte prácu v termináli radi, alebo chcete krajší zážitok, tak sa na Warp určite pozrite, možno je to niečo, čo hľadáte. Pre niekoho môže byť nevýhodou to, že nejde o open-source projekt.

Koncom februára vyšla verzia Warp-u konečne aj pre Linux, takže keď sa mi jedného dňa znepáči môj aktuálne používaný terminálový emulátor, tak si Warp pridám do kandidátov na preskúmanie.

Keby vás zaujímalo, čo používam ja, tak je to Alacritty. Rýchly terminál s jednoduchou konfigurácou v yaml formáte, rendrujúci cez GPU.

Alacritty však nemá podporu pre taby, čo niekomu môže prekážať. Ja taby nepoužívam a nepotrebujem, pretože namiesto nich mám tmux, čo je oveľa mocnejší nástroj. K tmux-u som napísal aj sériu článkov a natočil videá: predstavenie, moja konfigurácia a návod, ako si pomocou tmux-u viete vytvoriť tzv. štartovacie skripty pre projekty. K videám sa prekliknete priamo z článkov, hneď pod nadpisom je URL na Youtube.

Dám vám tipy aj na ďalšie zaujímavé terminály, na ktoré z času na čas pozriem a chvíľu skúšam:

Ešte jeden tip na terminál, ktorý som používal celé roky:

Záver

Noviniek vo frontende sa udialo samozrejme oveľa viac, než som spomenul. Opäť mám viac novo otvorených tabov v prehliadači čakajúcich na prečítanie, než som ich prečítal a zavrel. Tento týždeň je to o to horšie, že mám novú hračku. Kúpil som si Froundry, čo je pomôcka na hranie dračáku online, tak sa to teraz učím ovládať.