https://www.politiballwiki.net/w/api.php?action=feedcontributions&feedformat=atom&user=NewtonBeaver64 2026-08-22T14:44:49Z User contributions MediaWiki 1.43.1 https://www.politiballwiki.net/w/index.php?title=Redux_v_Reactu:_praktick%C3%BD_pr%C5%AFvodce_pro_%C4%8Dist%C5%A1%C3%AD_k%C3%B3d&diff=45515 2026-08-21T17:29:04Z

<p>NewtonBeaver64: Created page with &quot;Při práci s GraphQL si ale dejte pozor na typické chyby. První je přetížený server kvůli neomezené hloubce dotazů – klient může požádat o vnořené vztahy do nekonečna, což způsobí pomalé odezvy. Řešení je omezit maximální hloubku dotazu nebo použít šablonu pro povolené dotazy. Druhou častou chybou je ignorování cache. REST snadno využije HTTP cache pro GET požadavky, ale GraphQL pracuje s jedním endpointem, takže cache musíte řeš...&quot;</p> <hr /> <div>Při práci s GraphQL si ale dejte pozor na typické chyby. První je přetížený server kvůli neomezené hloubce dotazů – klient může požádat o vnořené vztahy do nekonečna, což způsobí pomalé odezvy. Řešení je omezit maximální hloubku dotazu nebo použít šablonu pro povolené dotazy. Druhou častou chybou je ignorování cache. REST snadno využije HTTP cache pro GET požadavky, ale GraphQL pracuje s jedním endpointem, takže cache musíte řešit na aplikační úrovni. Pokud to zanedbáte, může se váš server zbytečně zatěžovat.&lt;br&gt;&lt;br&gt;Při škálování aplikace se vám bude hodit rozdělení store do menších modulů, tzv. slices pomocí nástroje Redux Toolkit. Ten vám poskytne createSlice, který automaticky generuje akce a reduktory. Díky tomu píšete méně boilerplate kódu a méně chyb. Redux Toolkit také zahrnuje Immer, který umožňuje psát mutující zápis, ale pod kapotou stále vytváří neměnné aktualizace. Pokud přecházíte ze staršího kódu, postupně migrujte – není nutné předělávat vše najednou.&lt;br&gt;&lt;br&gt;Testování mobilních aplikací se od webového testování liší v několika zásadních ohledech. Kromě funkčnosti musíte ověřit chování na různých verzích operačních systémů, velikostech displejů a typech zařízení. Základním pravidlem je začít s testovací strategií už ve fázi návrhu, ne až po dokončení vývoje. Nejčastější chybou je spoléhat pouze na manuální testy – bez automatizace nestihnete pokrýt všechny kombinace a regresní chyby se objeví až u uživatelů.&lt;br&gt;&lt;br&gt;Volba mezi REST API a GraphQL není otázkou módy, ale praktických potřeb. Obě technologie řeší komunikaci mezi klientem a serverem, ale každá jiným způsobem. REST staví na zdrojích a HTTP metodách, GraphQL na dotazech, které si klient definuje sám. Než se rozhodnete, zvažte, jaká data vaše aplikace skutečně potřebuje a jakým způsobem je bude konzumovat.&lt;br&gt;&lt;br&gt;Nezapomínejte na bezpečnostní testování. I malá aplikace může obsahovat citlivá data, proto vždy testujte šifrování přenosu, ukládání tokenů a oprávnění. Použijte základní penetrační testy: zkuste odchytit provoz přes proxy, zkuste přepsat hodnoty v žádostech a podívejte se, zda aplikace správně ošetřuje neplatné vstupy. Často se zapomíná na testování oprávnění na pozadí – aplikace by měla fungovat i po odepření přístupu k poloze nebo kontaktům, ne jen okamžitě spadnout.&lt;br&gt;&lt;br&gt;Pomalé načítání stránek odrazuje návštěvníky a zhoršuje pozici ve vyhledávačích. Než začnete přidávat cache nebo komprimovat obrázky, zjistěte si, kde je skutečný problém. Otevřete si vývojářské nástroje prohlížeče, přejděte na záložku síť a podívejte se, které soubory se načítají nejdéle. Často to nejsou obrázky, ale zbytečné skripty třetích stran, které blokují vykreslení stránky. Nejprve odstraňte vše, co nepoužíváte, a teprve poté řešte optimalizaci.&lt;br&gt;&lt;br&gt;Kdy naopak sáhnout po GraphQL? GraphQL vyniká tam, kde máte složité datové vztahy a potřebujete efektivně agregovat data z více zdrojů. Typickým příkladem je mobilní aplikace, která pro jednu obrazovku potřebuje kombinaci uživatele, jeho přátel, příspěvků a komentářů. V RESTu byste museli volat několik endpointů a pak data skládat na klientovi. GraphQL umožňuje poslat jeden dotaz, který vrátí přesně to, co potřebujete, bez nadbytečných dat.&lt;br&gt;&lt;br&gt;Další praktické hledisko je verzování API. REST obvykle řeší změny pomocí verzí v URL (např. /v2/…), což je jednoduché a zpětně kompatibilní. GraphQL tuto potřebu částečně odbourává, protože klient si říká o konkrétní pole a vy můžete přidávat nová, aniž byste stará odebrali. To je výhoda při rychlém vývoji, ale vyžaduje to disciplínu – pokud začnete odebírat pole, starší klienti se okamžitě rozpadnou. Vždy mějte jasnou politiku pro deprecation a sledujte, které klienti jaká pole používají.&lt;br&gt;&lt;br&gt;Pro efektivní testování si nejprve vytvořte matici zařízení. Rozdělte trh podle reálného zastoupení operačních systémů a verzí. Nepokoušejte se testovat na všem, vyberte si reprezentativní vzorek: nejnovější vlajkové lodě, dva až tři středně staré modely a jedno zařízení s nízkou pamětí. Právě starší hardware často odhalí problémy s výkonem, které na nových telefonech nepostřehnete. Pro testování offline režimu a slabého signálu použijte emulátor s omezením přenosové rychlosti – ušetříte čas i peníze za reálná zařízení.&lt;br&gt;&lt;br&gt;Častým nešvarem je ukládání celých odpovědí z API do store bez dalšího zpracování. Místo toho si definujte stav, který reprezentuje různé fáze: loading, success, error. Ukládejte samotná data, ale také informaci o tom, kdy byla načtena. To vám umožní implementovat cache nebo refetch bez zbytečné duplicity. Při práci s asynchronními akcemi použijte middleware jako Redux Thunk nebo Redux Saga. Thunk je jednodušší a dostačuje pro většinu případů. Hlavně se vyhněte volání API přímo v reduktoru – to je častá chyba, která vede k vedlejším efektům a ztěžuje testování.</div>

NewtonBeaver64