https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=SashaGaby5961992 2026-10-13T21:05:52Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/index.php?title=Testy_reducer%C5%AF_a_thunk%C5%AF_zvl%C3%A1dnete_i_bez_b%C4%9B%C5%BE%C3%ADc%C3%ADho_prohl%C3%AD%C5%BEe%C4%8De&diff=401452 2026-10-01T19:07:14Z

<p>SashaGaby5961992: </p> <hr /> <div>Postavit REST API v Node.js jde dvěma cestami: použít vestavěný modul http, nebo sáhnout po Expressu. Rozdíl není v tom, co je „modernější&quot;, ale v tom, kolik práce chcete řešit ručně. Holý Node.js zvládne všechno, co Express umí, jenže za cenu vlastního kódu pro routování, parsování těla požadavku, hlaviček a zpracování chyb. Express tyto vrstvy dodává hotové a nechává prostor na logiku aplikace.&lt;br&gt;&lt;br&gt;Dokumentace REST API není soutěž v kráse, ale nástroj, který má druhému vývojáři ušetřit cestu do zdrojového kódu. Pokud ji píšeš až na konci, vzniká z paměti a s chybami. Začni rozhraním a teprve pak piš implementaci. U každého endpointu nejdřív rozhodni, co vrací a co očekává, a teprve potom řeš, jak to uděláš v databázi.&lt;br&gt;&lt;br&gt;Základem je jednotný tvar odpovědí. Domluv se na obálce, která obsahuje data a chybu, ať se frontend nemusí učit nový formát u každé routy. U chyb vracej konzistentní objekt s kódem, krátkou zprávou a volitelně detailem pole, které selhalo. Vyhni se tomu, aby jedna chyba byla holý řetězec a jiná strukturovaný objekt. Právě tady vzniká většina zbytečných oprav.&lt;br&gt;&lt;br&gt;Dokumentace bývá první místo, kam se lidé dívají, ale sama o sobě nestačí. Čtěte ji kriticky: hledejte sekce o omezeních, známých chybách a verzích, ve kterých byla funkce přidána nebo naopak odstraněna. Pokud něco chybí, ověřte to v diskusních fórech nebo v systému pro hlášení chyb. Užitečné je také zjistit, jak často vycházejí opravy a zda jsou bezpečnostní aktualizace řešeny pravidelně. Databáze, která je technicky skvělá, ale nemá aktivní údržbu, se může stát pastí.&lt;br&gt;&lt;br&gt;Autentizaci a chybové stavy popiš jako scénáře. Nestačí říct, že se posílá token; napiš, co se stane, když vyprší, když chybí oprávnění a když je tělo požadavku příliš velké. Uveď konkrétní stavové kódy, které klient má očekávat, a co má v kterém případě udělat. Frontend pak nemusí hádat, jestli má obnovit přihlášení, nebo zobrazit chybu.&lt;br&gt;&lt;br&gt;Akce, reducery a middleware bez zbytečné omáčky Akce popisujte jako malé, jednoúčelové objekty s typem a minimem dat. Vyhněte se akcím, které nesou celý stav formuláře, pokud to není nutné. Reducer musí být čistá funkce: žádné volání API, žádné náhodné hodnoty, žádné mutace. Vrací nový stav přes spread operátor nebo pomocí knihovny, která immutabilitu zajišťuje. Middleware jako thunk nebo saga používejte pro asynchronní operace, ale nepřidávejte je, dokud nemáte skutečný vedlejší efekt. Často stačí thunk a složitější nástroje jen zvyšují režii.&lt;br&gt;&lt;br&gt;Nakonec: čistota není jednorázový úklid, ale návyk. Před každým commitem si přečtěte, co jste napsali, a zkuste to zkrátit, aniž byste ztratili význam. Pokud váháte, zda je kód jasný, přečtěte ho nahlas. Kde se zaseknete, tam bude zaseknutý i kolega. Nástroje jako linter a formátovač nastavte hned na začátku projektu, ne až když je kód plný nekonzistencí. Automatické formátování odstraní hádky o styl a vy se můžete soustředit na logiku.&lt;br&gt;&lt;br&gt;Propojení s Reactem řešte přes useSelector a useDispatch. Vyhněte se staršímu connect, pokud nepracujete s legacy kódem. useSelector volejte s co nejmenším výběrem a používejte memoizaci, jinak každá změna store překreslí celou komponentu. Typická chyba je vracet z selektoru nový objekt při každém volání. Řešením je createSelector nebo stabilní reference. U dispatchů dávejte pozor na nekonečné smyčky, kdy akce uvnitř useEffect spouští další akci bez správných závislostí.&lt;br&gt;&lt;br&gt;Testování a ladění odhalí většinu problémů dřív než uživatelé. Reducer testujte jako čistou funkci se vstupem a očekávaným výstupem. Akce a selektory testujte izolovaně. Do prohlížeče nainstalujte nástroj pro sledování store a časové osy akcí. Díky tomu uvidíte, která akce stav změnila a proč. Pokud se přesto ztrácíte, zvažte, zda není čas část logiky přesunout mimo Redux nebo ho úplně nahradit lehčím řešením. Redux je nástroj, ne cíl.&lt;br&gt;&lt;br&gt;Async akce testujte přes falešný dispatch a injektovaný klient Asynchronní akce nejsou čisté, protože komunikují s okolím. Klíčem je izolovat to okolí. Místo skutečného HTTP klienta předáte akci objekt s metodou, kterou v testu nahradíte. Akce by měla klienta dostat jako argument nebo přes thunk extra argument, ne ho importovat přímo. Pak v testu vytvoříte falešného klienta, jehož metoda vrací předpřipravený promise, a zachytíte všechny dispatch volání do pole. Po dokončení akce zkontrolujete pořadí a obsah dispatch volání.&lt;br&gt;&lt;br&gt;Základem je správně navržený store. Nedávejte do něj vše, co aplikace obsahuje. Držte v něm pouze data, která musí přežít překreslení komponenty nebo je sdílí více částí aplikace. Lokální stav ponechte v komponentách. Typická chyba je ukládat do Reduxu stav modálních oken, načítání jednotlivého tlačítka nebo hodnotu rozepsaného inputu. Výsledkem je obrovský store, kterému nikdo nerozumí a každá změna vyžaduje zásah do několika souborů.</div>

SashaGaby5961992 https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:SashaGaby5961992&diff=401450 2026-10-01T19:07:11Z

<p>SashaGaby5961992: Die Seite wurde neu angelegt: „Váš průvodce praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví ukazovat chytrá řešení, která zvládne každý.“</p> <hr /> <div>Váš průvodce praktickým bydlením sází na osvědčené tipy. Píšu o tom, jak zvládnout domácnost bez stresu. Nejvíc mě baví ukazovat chytrá řešení, která zvládne každý.</div>

SashaGaby5961992