5 návyků, které zrychlí Redux v React aplikaci

Redux v React aplikaci často zpomalí sám vývojář, ne knihovna. Nejčastější příčinou je příliš mnoho stavu v globálním store a příliš mnoho komponent napojených na jediný objekt. Základní pravidlo zní: do Reduxu patří data, která potřebuje více částí aplikace nebo která přežijí přechod mezi obrazovkami. Lokální stav formuláře, otevřené menu nebo pozice kurzoru tam nepatří. Každý zbytečný klíč v store znamená další re-render a další místo, kde může vzniknout chyba.

Dodržování těchto osmi bodů nezaručí, že přestanete dělat chyby. Zaručí ale, že každá oprava bude mít smysl, bude ověřitelná a nezanechá po sobě víc problémů, než kolik jich vyřešila. Disciplína při bugfixech je totiž stejně důležitá jako znalost jazyka nebo frameworku – a mnohem vzácnější.

Selektory a normalizace d

Aktualizace a řešení konfliktů bez zbytečného stresu Než začnete pracovat, aktualizujte svou větev o změny z main. Použijte rebase, pokud chcete čistou historii, nebo merge, pokud chcete zachovat kontext větvení. Obě varianty jsou správné, ale tým by měl zvolit jednu a držet se jí. Rebase na veřejně sdílené větvi nedělejte, přepisovali byste historii ostatním. Konflikty řešte lokálně, nikdy neposílejte větev s nevyřešenými značkami. Po vyřešení spusťte testy a build, ne jenže soubory vypadají dobře. Častá chyba je slepé přijetí jedné strany konfliktu bez pochopení, co druhá strana měnila. Když si nejste jistí, zavolejte kolegovi a projděte změnu spolu.

Druhá častá chyba je refaktorovat příliš mnoho najednou. Označíte celý soubor, spustíte hromadnou změnu a v diffu se utopíte. Lepší je postupovat po malých krocích a po každém spustit testy. Pokud testy nemáte, uložte stav před zásahem pomocí správy verzí a po refaktoringu si projděte jen změněné řádky. Malý krok znamená malý diff, a malý diff znamená, že chybu najdete za minutu, ne za hodinu.

Offsetová paginace (?page=3&size=50) je jednoduchá na implementaci a pochopení, ale u velkých sad má dvě zásadní vady. Za prvé, databáze musí přeskočit všechny předchozí řádky, takže OFFSET 1000000 znamená plný průchod indexem. Za druhé, pokud mezi požadavky někdo vloží nebo smaže záznam, stránky se posunou a uživatel uvidí duplicity nebo naopak položky přeskočí. Kurzorová paginace tento problém řeší: místo čísla stránky posíláte neprůhledný token odvozený od posledního záznamu (například ?cursor=eyJpZCI6MTIzfQ&limit=50). Databáze pak použije podmínku WHERE id >123, což je řádově a stabilní i při zápisech.

Než začnete řešit větve a Pull Requesty, musíte se domluvit na jedné větvi, která je vždy nasaditelná. Říkejte jí klidně main nebo master, ale musí platit, že obsahuje jen to, co je otestované a připravené jít na produkci. Do této větve nikdo neposílá commity přímo. Každá změna jde přes novou větev a kontrolu. Pokud tohle není jasné, dřív nebo později se stane, že si dva lidé přepíší práci a dohledávání zabere celý den. Název pracovní větve by měl nést informaci: typ změny a krátký popis, například oprava-prihlaseni nebo nova-fakturace. Vyhněte se názvům typu test, vetev2 nebo jmeno-prijmeni.

Nakonec si nastavte ochranu hlavní větve: zakázané přímé zápisy, povinné schválení a povinné testy. Bez toho se dřív nebo později najde někdo, kdo si řekne, že to tentokrát stihne rychleji. Tato pravidla nejsou byrokracie, ale způsob, jak se k sobě chovat slušně. Tým, který je dodržuje, tráví méně času opravami a více času psaním kódu, který funguje.

První a nejčastější chyba: opravovat bez reprodukce. Pokud nedokážete chybu spolehlivě vyvolat, nemáte co opravovat – jen hádáte. Napište si minimální reprodukční rekonstrukce koupelny krok za krokem, ideálně jako automatizovaný test. Teprve pak se pusťte do změny kódu. Test, který chybu zachytí, je zároveň důkaz, že oprava funguje, a ochrana do budoucna.

Základem je krátká životnost větve. Čím déle ji držíte otevřenou, tím větší je šance, že se vzdálí od main a při sloučení vznikne konflikt v desítkách souborů. Ideálně by změna měla být hotová a sloučená během jednoho až dvou dnů. Když jde o větší práci, rozdělte ji na menší logické celky, které jdou sloučit samostatně. Před každým commitem si projděte, co posíláte. Používejte git status a git diff, ať neposíláte omylem konfigurační soubory s hesly, dočasné soubory nebo velké binárky. Do kořene projektu patří soubor, který tyto věci ignoruje, a měl by být v repozitáři od začátku.

Osmá zásada: neopravovat naslepo v produkci. Přímé změny v produkčním prostředí bez možnosti vrátit se zpět jsou riskantní. Vždy mějte připravený plán, jak změnu odvolat, a ideálně ji nejdřív otestujte v izolovaném prostředí. Pokud to nejde, alespoň minimalizujte dopad a mějte po ruce záložní postup.