Miért Riverpoddal kezeljük az állapotot a Flutter-alkalmazásainkban

Mire való valójában az állapotkezelés

Az állapotkezelésről szóló viták hamar hitvitává fajulnak, ezért érdemes tisztázni, mi a tényleges mérnöki feladat. Az alkalmazás állapotát a widgetfa bármely pontjáról el kell tudni olvasni, kiszámíthatóan kell tudni módosítani, és felület indítása nélkül is tesztelhetőnek kell lennie. Minden megoldás – a Provider, a Bloc, a GetX, a Riverpod vagy a sima setState – más kompromisszumot köt e három igény és a kielégítésükhöz szükséges körítés között.

Ügyfélprojekteknél ez a döntés kétszer is számít: először nekünk, fejlesztés közben, aztán annak, aki utánunk viszi tovább az appot. Egy ötletes, de nehezen átlátható architektúra abban a pillanatban teherré válik, amikor a kódbázis gazdát cserél. Ezért mi az explicit, jól dokumentált és nehezen elrontható megoldásokat részesítjük előnyben.

Mit csinál jól a Riverpod

A Riverpod a Provider újragondolt változata ugyanattól a szerzőtől, csak a legnagyobb szerkezeti hibától megszabadítva: a providerek már nem a widgetfában élnek. Ez egyetlen változtatás, de a következményei éles projektben nap mint nap megmutatkoznak:

• —Fordítási idejű biztonság – ha nem létező providert olvasol, azt a fordító jelzi, nem pedig futás közben omlik össze egy olyan képernyő, amit a QA épp nem tesztelt
• —Nincs BuildContext-függés – az üzleti logika widget nélkül is hozzáfér az állapothoz, így bárhonnan hívható és könnyen unit tesztelhető
• —Célzott újrarajzolás – minden widget pontosan arra az állapotra iratkozik fel, amit használ, így egyetlen mező változása nem rajzolja újra az egész képernyőt
• —Explicit függőségek – a provider maga mondja meg, mitől függ; az objektumgráf a kódból kiolvasható, nem a háttérben áll össze varázsütésre
• —Beépített aszinkron kezelés – a FutureProvider és a StreamProvider a betöltés, a hiba és az adat állapotát típusként kezeli, nem egy boolean flagre épülő konvencióként

Miért hagyjuk ki a kódgenerálást

A Riverpodhoz létezik annotációalapú kódgeneráló réteg is. Mi tudatosan nem használjuk, hanem kézzel írjuk a providereket. A kódgenerálás minden módosítás után build_runner-lépést követel, minden diffbe generált fájlokat kever, és egy második szintaxist is meg kell hozzá tanulni. Amit cserébe ad – valamivel tömörebb deklarációkat –, az nem éri meg a mindennapi súrlódást és a hosszabb betanulást.

Kézzel írt providerekkel a mentális modell egyszerű marad: az fut, amit olvasol. Az éles Flutter-appjainkban, köztük az Invoice Guruban is, a teljes állapotréteg sima, kézzel írt providerekből áll, és ez a döntés minden eddigi Flutter- és Riverpod-frissítést jól átvészelt.

Hol döntenénk másképp

Nincs olyan alapértelmezés, amely minden helyzetben megállja a helyét. Ha egy kiforrott Bloc-architektúrára épülő kódbázist veszünk át, azt Blocban bővítjük tovább: egy élő termékben az architektúra egységessége fontosabb, mint a személyes preferencia. Egy kétképernyős, egyszerű segédappnál pedig a sima setState pár ValueNotifierrel teljesen elég; oda állapotkezelő keretrendszert bevezetni puszta körítés, valódi haszon nélkül.

Nem az a lényeg, hogy a Riverpod minden szempontból a legszebb megoldás. Hanem az, hogy egy csapatnak legyen egyetlen, mindenki által jól értett alapértelmezése, és egy rövid lista arról, mikor indokolt eltérni tőle. Ettől marad karbantartható egy egész ügyfélprojekt-portfólió.