• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    VOY
    VOY --- ---
    SULTHAN: Strilet do nohou se muzes cimkoliv, to je pravda, ale nevazany pouzivani useState a useEffect hooku je zas vyjimecne kvalitni footgun :-).
    JARDABEREZA
    JARDABEREZA --- ---
    BESH: Chápu, asi bych to musel vidět na vlastní oči :-D

    SULTHAN: No myslel jsem to tak, že se naučít jenom ten Reactí subset JS a HTML a odignoruješ ten zbytek např. "getElementById" atd. Nebo místo čistého HTML používáš komponenty nějakého design systému. Minulý rok na Frontkonu už říkali, že chodí juniorní vývojáři co umí slušně react, ale v čistém HTML a JS prostě neodešlou ani formulář.
    SULTHAN
    SULTHAN --- ---
    BESH: Střílet do nohou se můžeš čímkoliv. A dropdown není zas tak jednoduchá věc, zejména pokud má být responsive & accessible
    BESH
    BESH --- ---
    JARDABEREZA: Tohle nebyla stiznost na React, ja sam na FE nic jineho nepouzivam uz leta a ani to nemam v planu. Spis takova pravidelna fascinace, jak se Reactem nekteri lidi umi brutalne strilet do nohou. Zamotavaji se do spleti state hooku, z kterych se pak vymotavaji effect hooky, vsechno silene prekombinovane a obcas mi z toho proste zustava rozum stat. U rozbalovaciho seznamu odkazu je to proste do oci bijici over-engineering. React je dobry sluha, ale moc zly pan.
    SULTHAN
    SULTHAN --- ---
    JARDABEREZA: Hele, React je JS, respektive TS, takže těžko se můžeš učit React a neumět javascript. Stejně tak si neumím představit, jak chceš používat React bez znalosti HTML.
    React je jen velmi jednoduché rozšíření javascriptu, které ti umožňuje deklarativně psát pseudo-HTML kód, ale bez javascriptu a HTML si v tom nevrzneš.
    Jinak teda ani na HTML ani na javascriptu není moc co se učit.
    FARIN
    FARIN --- ---
    PJOTRIK: Vsechno mas ve FE je prave to SPA. Nerikal bych tomu extrem, to je realita dneaka a industry standard.

    Puvodne zasny SPA neexistovalo a vsechno se psalo na serveru. Jenze tam se neda resit interakce a delit to na server a klient cast se u tech slozitych aplikaci ukazalo neprakticky.
    PJOTRIK
    PJOTRIK --- ---
    FARIN: Tohle uz je z meho pohledu extremni pripad, kdy mas celou aplikaci jen ve frontendu. Server je vlastne jen DB, stejne dobre by API mohlo byt SQL misto GraphQL, to vubec nevnimam jako klient/server appku
    PJOTRIK
    PJOTRIK --- ---
    FARIN: drag&drop nebo file upload jako argument beru. I kdyz si myslim ze to jde ekvivalentne resit nejakou izolovanou komponentou, ktera tuhle funkcionalitu vyresi a osobne bych vybral tohle reseni. Ale chapu ze to je osobni preference.

    Validace si myslim ze jde stejne dobre resit roundtripem pres server, kde je to megajednoduchy volani, odpadne ti duplikace. Opet, prinejlepsim osobni preference IMO.

    U toho stavu ale nerozumim. Stav muzes resit na serveru, typicky naopak musis (viz KEJML). API je v tomhle reseni ekvivalentni aplikaci, takze server vi, co se ma v UI vyrenderovat a vrati to. Cache na klientu neexistuje, takze invalidace odpada.
    FARIN
    FARIN --- ---
    KEJML: Právě že vůbec. A třeba GraphQl to umožňuje tohle hezky oddělovat (tím neříkám že je to nutný, ale tady ten decoupling jde dál než třeba u REST API). Server poskytuje nějaký stav objektů a to kde se objeví a jak se prezentují je věc frontendu a tam se taky nad tím vrství ta komplexita.
    KEJML
    KEJML --- ---
    FARIN: No ale stejně ten složitý stav, který SPA udržuje, musíš nakonec synchronizovat se serverem a server ho musí celý znát, jinak o něj uživatel přijde. Takže máš ve výsledku složitý stav v SPA a stejně složitý stav na serveru.
    JARDABEREZA
    JARDABEREZA --- ---
    BESH: Proč to ty lidi dělají... možná se vracíme trochu zpátky k té abstrakci. A brzy tu může být nebo už je generace programátorů co nebudou umět HTML a JS, ale místo toho se naučít třeba jenom React a pokud na trhu bude odpovídající poptávka, tak s tím nemusí mít problémy. Ale důvodů může být samořejmě víc.
    FARIN
    FARIN --- ---
    PJOTRIK: složítý je typicka ta aplikace kterou skrz SPA tvoříš, resp. její vnitřní stav. Dokud děláš neco co je spíš web kde jsou od sebe jasně oddělený stránky a dobře to pasuje na model request / response a potřebuješ to obohatit nějakou interaktivitou tak htmlx (případně alpine.js) je hezká přímá možnost bez toho aby člověk musel setupovat nejaký komplikovaný stack.

    Nejde tolik o rychlost (i když SPA je většinou pocitově o něco responzivnější) ale o management stavu. U těch komplexních aplikaci to není tak že by jsi s nějakou uživatelskou akcí vyrenderoval jeden fragment html a ten na stránce vyměnil. Často se změna propisuje do více míst, invaliduje cache apod.

    Navíc přístup všechno na serveru dost naráží třeba u formulářu. Tam řešíš validace, drag&drop reoredring seznamů, file upload přes drop souboru .... stejně to obsluhuješ netriviálně na straně klienta.

    Druhá věc je že ty deklarativní knihovny hezky fungují dokud to jde dobře deklarativně popisovat. A jak se to začne komplikovat tak to jde do špaget. V tohmel jsou knihovny jako React / Svelte univerzálnější a umožnují lepé aplikaci strukturovat a i ten syntax cukřík je tak hezčí.

    Ale možná pod tímhle rozumíš právě to graficky intenzivni UI.
    PJOTRIK
    PJOTRIK --- ---
    FARIN: no a k tomu bych rad slysel argumenty, proc nenahradis? Ja v tom vidim sanci nechat fakt veskerou logiku na serveru a web mit opravdu trivialni.

    Chapal bych nejaky graficky intenzivni UI, ktery musi okamzite reagovat (i kdyz i to Datastar tvrdi ze zvlada dostatecne rychle, nemam vyzkouseno, ale furt tam musis pocitat s latenci site). Ale co je na SPA inherentne slozityho?
    FARIN
    FARIN --- ---
    PJOTRIK: je to fajn na jednoduchý věci. Na složitější SPA nebahradis.
    KEJML
    KEJML --- ---
    PJOTRIK: My jsme backendisti, kteří potřebují rychle prototyp frontendu, tak to kolega poměrně rychle napsal s pomocí htmx a zatím dobrý. Ale produkční kód to není a osobně jsem to mimo základních tutoriálů ještě neviděl vůbec.
    PJOTRIK
    PJOTRIK --- ---
    Ale abych nebyl jenom za zapsklyho dedka - uz chvili se divam na HTMX a Datastar a to vnimam jako zavan opravdu sveziho vetru a zpusob jak by mel fungovat webovy stack. Zadny JSON API, GraphQL, javascriptovy SPA, ale primocara opravdu RESTful aplikace... po 20 letech co jsem utekl pred javascriptem mam znova chut delat i frontend. Delate s tim nekdo, co si o tom myslite?
    KLEINZACH
    KLEINZACH --- ---
    SH_PANDA: tak to me je mentalne 60 a vidim vsude naplasti a hlineny nozicky :)
    CERMI_FOX
    CERMI_FOX --- ---
    BESH: většinou je za tím nějaký designér, který to tak nakreslil, a klient, který to chtěl přesně tak, jak je to nakresleno, a W3C, které nedovoluje (nedovolovalo) dostatečně stylovat formulářové prvky. Zrovna dropdown menu si každý browser renderoval po svém.
    BESH
    BESH --- ---
    LITTLELI: Ad "reseni je slozitejsi nez problem". To mi povidej. Ja ted zrovna videl jedno React reseni dropdown menu s odkazama a byla to hierarchie nekolika komponent, kazda s nejakym vlastnim state a onChange callbackama, kde teda na konci byla implementace Listboxu z @headlessui. Netusil jsem, ze se mi jeste nekdy zasteskne po klasickem CSS ul->li menu, ale tohle bylo na me fakt moc. Proc si to ty lidi delaj. :(
    LITTLELI
    LITTLELI --- ---
    JANFROG: K něčemu to je. Teď ještě všichni kolektivně musí přijít k čemu :-)
    PJOTRIK: Tak to jsem furt 2. Spíš to mám posunutý takhle: Když se hrabu ve starých paperech, tak dopamin se normálně dostavuje. Horší jsou ty nový věci, často mi přijde, že řešení je složitější než problém, který to řeší. Ale furt myslím, že 2 :-)
    Kliknutím sem můžete změnit nastavení reklam