https://wiki.rettungsdienstblog.eu/api.php?action=feedcontributions&feedformat=atom&user=Barbra9211 2026-09-18T23:03:50Z Benutzerbeiträge MediaWiki 1.37.1 https://wiki.rettungsdienstblog.eu/index.php?title=UI_a_UX_pro_program%C3%A1tory:_praktick%C3%BD_pr%C5%AFvodce_z%C3%A1klady&diff=166429 2026-08-21T18:29:26Z

<p>Barbra9211: Die Seite wurde neu angelegt: „Klíčová je také čitelnost a přístupnost. Nepoužívejte příliš světlý text na světlém pozadí, ani malou velikost písma. Kontrast by měl být dostatečný, minimálně 4,5:1 pro běžný text. Vždy nastavte správné typy vstupů v HTML, aby se na mobilu otevřela číselná klávesnice u telefonu nebo kalendář u data. A nezapomeňte na klávesnici – uživatel by měl projít celou aplikaci pouze pomocí tabulátoru. To není jen otá…“</p> <hr /> <div>Klíčová je také čitelnost a přístupnost. Nepoužívejte příliš světlý text na světlém pozadí, ani malou velikost písma. Kontrast by měl být dostatečný, minimálně 4,5:1 pro běžný text. Vždy nastavte správné typy vstupů v HTML, aby se na mobilu otevřela číselná klávesnice u telefonu nebo kalendář u data. A nezapomeňte na klávesnici – uživatel by měl projít celou aplikaci pouze pomocí tabulátoru. To není jen otázka přístupnosti, ale i použitelnosti pro ty, kdo preferují rychlou navigaci.&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;Vestavěné nástroje IDE jsou silné, ale nejsou neomylné. Často se stává, že po automatickém refaktoringu zůstanou „mrtvé&quot; kusy kódu, které se už nikde nepoužívají. Po každé větší změně spusťte kontrolu nepoužívaných symbolů (např. pomocí analýzy kódu) a odstraňte je. Také se vyplatí věnovat pozornost tomu, co IDE nabízí při psaní – návrhy na zjednodušení nebo vylepšení kódu vám mohou ušetřit spoustu času, pokud je budete aktivně využívat.&lt;br&gt;&lt;br&gt;Jak mockovat závislosti a ověřit dispatch Použijte knihovnu pro testování, jako je Jest, ale princip funguje stejně i v jiných prostředích. Vytvořte si fiktivní store pomocí redux-mock-store, který zaznamenává všechny dispatchované akce. Do thunku pak vložíte funkci, která místo API vrátí předem definovaný objekt. Po zavolání akce zkontrolujete, jestli se v seznamu akcí objevily ty, které očekáváte. Nezapomeňte na asynchronní povahu: počkejte na dokončení pomocí async/await nebo Promise.resolve, jinak test skončí dřív, než se akce stihnou odeslat.&lt;br&gt;&lt;br&gt;Nakonec si osvojte pravidlo: testy by měly být rychlé a izolované. Pokud potřebujete ke spuštění testu databázi nebo síť, děláte to špatně. Vše, co je externí, nahraďte mockem. Tím zajistíte, že testy poběží v řádu sekund a budou spolehlivé. Tento jednoduchý postup vám umožní testovat reducery a async akce i v projektech, které nemají složité prostředí, a přitom si zachovat jistotu, že logika funguje.&lt;br&gt;&lt;br&gt;Dalším důležitým pravidlem je netestovat implementaci, ale chování. Nezáleží na tom, jak přesně thunk vypadá uvnitř, ale jaké akce vyvolá a v jakém pořadí. Proto se vyhněte kontrole, jestli byla volána nějaká konkrétní funkce kromě dispatch. Místo toho se zaměřte na to, co uživatel nebo další části aplikace skutečně vidí. Tento přístup vám umožní později změnit interní strukturu akce bez nutnosti přepisovat testy, pokud zůstane zachováno chování.&lt;br&gt;&lt;br&gt;U asynchronních akcí, jako jsou thunky, je klíčové oddělit testovanou logiku od volání API. Místo skutečného HTTP požadavku použijte mock funkci, kterou si sami definujete. Do ní vložíte očekávanou odpověď a poté ověříte, jaké akce byly dispatchovány. Například u akce, která načítá data, očekáváte dispatch akce pro začátek načítání a poté akci s daty po úspěchu. Mockování vám umožní simulovat jak úspěch, tak chybu, aniž byste museli spouštět server.&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;Osvojení si těchto nástrojů vyžaduje čas, ale návratnost je vysoká. Začněte s jednou funkcí, kterou budete používat pravidelně, a postupně přidávejte další. Zanedlouho zjistíte, že refaktoring už není nutné zlo, ale rychlá a bezpečná součást vašeho vývojového procesu. Není potřeba kupovat drahé pluginy – to, co potřebujete, už máte ve svém IDE.&lt;br&gt;&lt;br&gt;Při přechodu ze SQL na NoSQL se vyhněte pokušení kopírovat relační model 1:1. V dokumentové databázi je normální denormalizace – data, která čtete společně, ukládáte společně. Například objednávku s položkami a adresou uložíte jako jeden dokument. Není potřeba joinovat tři tabulky. Naopak, pokud často měníte adresu zákazníka a potřebujete ji konzistentní ve všech objednávkách, denormalizace způsobí problémy. Musíte sami řídit konzistenci při aktualizaci, což je častý zdroj chyb.</div>

Barbra9211 https://wiki.rettungsdienstblog.eu/index.php?title=Benutzer:Barbra9211&diff=166428 2026-08-21T18:29:24Z

<p>Barbra9211: Die Seite wurde neu angelegt: „Někdo, kdo světem interiérů žije už dlouho. Píšu o tom, jak zvládnout domácnost bez stresu. Nejraději ukazovat chytrá řešení, která zvládne každý.“</p> <hr /> <div>Někdo, kdo světem interiérů žije už dlouho. Píšu o tom, jak zvládnout domácnost bez stresu. Nejraději ukazovat chytrá řešení, která zvládne každý.</div>

Barbra9211