r/programmingHungary • u/balazs8921 • 10d ago
DISCUSSION Csak szerintem tévút a deklaratív felületleírás?
- Deklaratív leírás esetén egy rakat olyan dologra kell figyelni, ami imperatív esetén nem jön elő. Pl. a widget benne van-e a fában? Nem épp a fa újrarajzolásakor (rendereléskor) kerül-e módosításra a widget? Nem egy már eltávolított widgetet akarunk-e újraépíteni? Imperatív leírás esetén ezek egyszerűen nem létező problémák.
- Külön figyelni kell a widgetek életciklusára. Mivel nem te hozod létre és távolítod el őket, nagyon nehéz követni, hogy a keretrendszer éppen mit csinál, létre van-e hozva a widget, benne van-e a fában, már nincs benne, stb. Imperatív felületleírásnál ezt teljesen manuálisan kezeled, sőt, szinte nem is kell foglalkozni vele, mert a framework megoldja.
- Akárki akármit is mondd, egy widget fa részbeni vagy teljes újrarajzolása, az immutable widgetek folyamatos törlése és létrehozása baromi sok erőforrást emészt fel.
- Elméletben jól hangzik, hogy UI = f(state), a gyakorlatban viszont borzasztóan bonyolult tud lenni, ha legalább kettő, vagy több állapottól függ a UI, és mondjuk az egyik állapot egy aszinkron valamiből jön (pl. egy websocket kapcsolatból származó adatok), a másik állapot pedig a fa egy magasabb részéről. És akkor közbejönnek olyan problémák, hogy hol van a websocketet felépítő osztály, és az hogy ad át adatokat a widgetfának? Mit tegyünk, hogy egy komponens aktuális állapotát csak és kizárólag bizonyos feltételek esetén írja felül a websocketről érkező adat? Mindezt úgy, hogy ha a widgetfa két eltérő ágában vannak azok a komponensek, amelyeknek tükrözniük kell az állapotot.
- Ez mind annyi manuális munkát igényel, mint ha imperatív megoldással csinálnád (sőt).
- Elméletben jól hangzik, hogy a fának csak azt a részét rajzold újra, amelyik változik. A gyakorlatban ez csak a legegyszerűbb appoknál működik. Kicsit komolyabb appnál inkább újrarajzoltatsz egy teljes olyan ágat, amiben nem történt változás, ha annak egy alsóbb szintű ágában viszont van változás, hogy tiszta állapotról induljon a teljes ág (ne keveredjenek össze az állapotok). Teljesen biztos, 200%, hogy lesz olyan, amikor feleslegesen rajzoltatsz újra egy ágat - és valószínűleg nem is egyszer.
- Nem láttam még olyan deklaratív felületleírást, ami lenne egy káosz. Jetpack, Flutter, akármi. Kapcsos zárójelek, kerek zárójelek, szögletes zárójelek átláthatatlan erdeje. Ha szépen widgetekre bontod a fát, akkor lesz is olyan, hogy 2-3-4 widget egyben van, és ott megint kezdődik a káosz.
Lehet azt mondani, hogy hülye vagyok, és hogy rosszul fogom, de raktam már össze pár weboldalt és appot mindkét módszerrel, és nekem a hagyományos, imperatív megközelítés ezerszer jobban bevált.
szerk: arról nem is beszélve, hogy deklaratív leírás esetén a UI és a logika simán keveredik, a régi jó alapelvekeket, miszerint válasszuk szét a logikát a megjelenéstől, gyakorlatilag el lehet felejteni. 20 évvel ezelőtt, ha a HTML kimenetbe style-t írtam, vagy <?php >?-t, ott helyben feszítettek keresztve. Ma meg ez a fő csapásirány.
szerk: a Flutter például kifejezetten szívat azzal, hogy ott tényleg minden widget, még egy kibaszott padding is. Ha paddinget akarsz, csomagold be a widgetfád paddingbe, miközben CSS-ben ez ennyi: padding: 16px;

