Čitelný JavaScript: co vyhodit a čím nahradit

Než uděláte první potvrzení změn, založte soubor, který vyjmenuje ignorované cesty. Bez něj se do historie dostanou tisíce souborů z knihoven a každá změna závislosti zaplaví rozdíly, ve kterých se nedá nic najít. Stejně důležité je nastavit jméno a e-mail, protože podle nich se přiřazují jednotlivé změny. Pak teprve inicializujte repozitář a přidejte první dávku souborů. Kontrolujte, co se chystá k uložení, a to ještě před samotným potvrzením.

Čistý kód v JavaScriptu neznamená krásně barevné zvýraznění v editoru. Znamená kód, kterému po půl roce porozumíš i ty sám, a který kolega opraví bez toho, aby se bál něco rozbít. Největší problém nebývá složitá logika, ale zbytečný chaos: nejasné názvy, dlouhé funkce a proměnné, které mění význam podle toho, kde se zrovna použijí.

Chybové stavy řešte centrálně. Jeden middleware na konci registrace routerů, čtyři argumenty, žádné posílání odpovědi uvnitř. V něm rozhodněte, zda jde o známou chybu, nebo o neočekávanou výjimku. U neočekávané zalogujte stopu a klientovi pošlete obecnou zprávu bez detailů. Nikdy neposílejte do odpovědi celý stack trace, ani v interním prostředí. Zároveň nastavte process.on('unhandledRejection'), aby pád nezůstal bez záznamu.

Funkce, která má přes 30 řádků, obvykle dělá víc věcí. Rozdělte ji. Každá funkce by měla mít jednu odpovědnost a ideálně vracet hodnotu, ne měnit okolní stav. Vyhněte se hlubokému vnořování if bloků – použijte guard clauses na začátku funkce. Místo if (podminka) { ... } else { ... } často stačí otočit podmínku a vrátit se včas. Tím se sníží počet úrovní odsazení a kód se čte shora dolů jako příběh.

Jakmile zvládnete základy, začněte používat větve. Pro každou novou funkci nebo opravu si vytvořte samostatnou větev a do hlavní větve slučujte až hotovou a otestovanou práci. Tím se vyhnete tomu, že rozpracovaný kód blokuje ostatní změny. Pokud pracujete sami, může se to zdát zbytečné, ale zvyk se vyplatí ve chvíli, kdy se k projektu připojí kolega nebo když se potřebujete rychle vrátit k poslední stabilní verzi. Slučování řešte průběžně, ne jednou za měsíc – čím déle větev žije, tím větší konflikty vás čekají.

Selektory a memoizace: kde lidé přestávají Selektory by měly být čisté a pokud možno memoizované. Když vytváříte novou referenci při každém volání, například state.items.filter(...) bez memoizace, komponenta se překreslí při každé akci, i když se data nezměnila. Řešením je createSelector z knihovny Reselect. Ten si pamatuje vstupy a přepočítá výstup jen tehdy, když se změní relevantní část stavu. Pozor ale na to, že memoizace funguje pouze pro jeden argument. Pokud selektor používáte s parametry, musíte vytvořit novou instanci selektoru pro každou kombinaci, jinak si budete předávat špatná data.

Redux sám o sobě nezaručí výkon. Problém většinou nevzniká v store, ale v tom, jak komponenty odebírají data. Pokud použijete useSelector bez rozmyšlení, každá změna v store může spustit překreslení i tam, kde to není potřeba. Základ je vrátit z selektoru co nejmenší a co nejstabilnější hodnotu. Místo celého objektu vracejte konkrétní pole, která komponenta skutečně používá. Když potřebujete více hodnot, použijte shallowEqual z React-Redux nebo více selektorů. Tím výrazně omezíte zbytečnou práci.

Další pastí je ignorování struktury store. Normalizovaná data – tedy entity uložené podle ID a seznamy pouze s těmito ID – výrazně zjednodušují aktualizace. Když máte hluboko vnořené objekty, každá změna znamená kopírování celé větve. To je pomalé a náchylné k chybám. Normalizace sice ze začátku vypadá jako práce navíc, ale u větších aplikací se vyplatí. Stejně tak nepoužívejte Redux pro data, která přicházejí ze serveru a mají krátkou životnost. Na to stačí lokální stav nebo knihovna pro načítání dat.

Druhou častou chybou je ukládat do Reduxu vše. Lokální stav, jako otevřené menu nebo text ve formuláři, do store nepatří. Redux je pro sdílená data, která potřebuje více částí aplikace, případně pro data, jež mají přežít navigaci. Pokud do store cpe­te i to, co zvládne useState, zvyšujete složitost a nutíte komponenty reagovat na změny, které se jich netýkají. Držte store co nejmenší a účelový.

Poslední věc: middleware a thunky. Není nutné používat thunk na všechno. Pokud potřebujete řešit složité asynchronní scénáře, zvažte redux-saga nebo redux-observable, ale vždy s ohledem na to, kolik toho tým zvládne udržovat. Příliš mnoho vrstev abstrakce vede k tomu, že se ztrácí přehled o tom, co se v aplikaci děje. Redux je nástroj, ne cíl. Když ho používáte vědomě a s ohledem na výkon, bude aplikace svižná a předvídatelná.