Redux v Reactu bez zbytečných re-renderů a bordelu

Selektory a memoizace rozhodují o výkonu Každé volání useSelector spouští porovnání výsledku. Pokud selektor vrací nový objekt nebo pole při každém volání, komponenta se překreslí i bez změny dat. Řešením je vracet primitivní hodnoty, použít více selektorů, nebo výsledek obalit memoizací. Na odvozená data, která vznikají filtrováním či seskupováním, používejte memoizované selektory. Počítejte je mimo komponentu, ne uvnitř renderu.

Chyby, middleware a validace vstupů Express zpracovává chyby pomocí middlewaru se čtyřmi argumenty. Pokud handler vyhodí výjimku v asynchronní funkci, Express ji nezachytí — musíte ji předat přes next(err) nebo použít obalovací funkci. Bez toho server buď spadne, nebo vrátí požadavek, který nikdy nedoběhne. Druhá častá chyba je vracení surových chybových zpráv z databáze klientovi. Ty prozrazují strukturu tabulek a usnadňují útok. Posílejte obecnou zprávu a detail logujte na serveru.

Komunikace bývá podceňovaná část. Lidé, kteří na chybu narazili, potřebují vědět, že se na ní pracuje, a ti, kdo čekají na vydání, zase to, co se změní. Krátká zpráva o stavu před opravou a po ní zabrání desítkám dotazů. Stejně důležité je zapsat, proč jste zvolili horkou opravu, nebo odklad. Zápis nemá být obřad, stačí pár vět. Zpětně z něj poznáte, kde se rozhodnutí opakovaně nedaří.

Začněte tím, že si projdete posledních několik dokončených úkolů a porovnáte původní odhad se skutečností. U každého rozdílu si zapište, co čas zabralo. Typicky se objeví čekání na odpověď, dohledávání v cizím kódu, opakované spouštění buildů, příprava dat nebo vysvětlování změny kolegům. Tento seznam je cennější než jakákoli obecná procentuální přirážka, protože vychází z vašeho projektu.

Nakonec mějte store malý, akce popisné, selektory memoizované a asynchronní logiku oddělenou. Když se aplikace rozroste, přidejte slice podle domén, ne podle obrazovek. Každá doména má vlastní reducer, akce i selektory. Díky tomu se změny v jedné části neprojeví v druhé a ladění přestane být hledáním jehly v kupce sena.

Express je nejrozšířenější framework pro stavbu REST API v Node.js, ale sám o sobě nezaručuje, že výsledek bude spolehlivý. Většina problémů nevzniká v byznys logice, nýbrž v organizaci kódu, ošetření chyb a v tom, jak server zvládá souběžné požadavky. Následující body vycházejí z opakovaných chyb, které se v produkci objevují nejčastěji.

Na závěr: testujte chybové stavy, ne jen šťastnou cestu. Napište testy pro neplatný vstup, chybějící oprávnění a nedostupnou databázi. Právě tam se láme rozdíl mezi API, které funguje na lokalhostu, a API, které přežije v produkci.

Akce navrhujte jako události, ne jako settery. Místo SET_ITEMS použijte itemsLoaded nebo itemsFetchFailed. Akce by měla popsat, co se stalo, a reducer rozhodne, co to znamená pro stav. Do payloadu posílejte jen to, co reducer potřebuje. Když do akce přidáte celý objekt i s daty, která se nikdy nezmění, zbytečně nafukujete historii a ztěžujete ladění.

Typické chyby: ukládání celého API response včetně metadat, duplikování stejných dat na více místech, normalizace přes kopírování polí, která se pak musí ručně synchronizovat, a předávání dispatch přes mnoho vrstev props. Další častá chyba je příliš mnoho akcí pro jednu operaci. Sloučení do jedné akce se dvěma až třemi typy stavu (načítání, úspěch, chyba) výrazně zjednoduší reducer i testy.

Nejčastější chyba je snaha verzovat konfiguraci ve stejných větvích jako kód. Vznikne vazba, která nutí při každé změně prostředí vytvářet novou větev kódu, i když se kód nezměnil. Další častý problém je kopírování celé konfigurace mezi prostředími. Pak se do produkce snadno dostane testovací hodnota. Držte společný základ a jen odchylky pro konkrétní prostředí. Také pozor na pořadí načítání: proměnné prostředí mají obvykle přednost před souborem a soubor před výchozími hodnotami. Neošetřené pořadí vede k tomu, že aplikace běží s jinou konfigurací, než si myslíte.

Asynchronní logiku držte mimo komponenty. Thunky nebo middlewary jsou v pořádku, ale nesmí se z nich stát druhá vrstva byznys logiky. Načtení dat, transformace a uložení do storu patří do jednoho místa. V komponentě pak zůstane jen volání dispatch a čtení stavu. Pokud fetchujete data v useEffect a zároveň je ukládáte do Reduxu, hlídejte závislosti a rušte požadavky při odpojení komponenty, jinak si vyrobíte race condition.

Prvním krokem je rozdělit repozitář na dva. V repozitáři s kódem ponechte pouze výchozí hodnoty, které jsou bezpečné pro všechny, a šablony konfiguračních souborů. Skutečné hodnoty pro vývoj, test a produkci patří do repozitáře s konfigurací. Tím získáte dvě nezávislé historie. Kód se dá kdykoli vrátit zpět, aniž byste s sebou táhli změny prostředí. Konfiguraci lze měnit bez nového buildu a bez zbytečného čekání na pipeline.