Az elmúlt években rengeteg motion munkát adtunk ki. Lottie az After Effects exportokhoz, CSS keyframe a kis dolgokra, GSAP amikor rendes timeline kell. Mindegyiknek megvan a maga helye, és a mai napig használjuk őket.

Egy dolog azonban mindig kínos maradt: az interaktív animáció átadása. Bármi, ahol a vizuálnak reagálnia kell egy kattintásra, egy hoverre vagy egy adatra a UI-ból. A motion designer és a fejlesztő közti kör általában képernyőfotókba, JSON-piszkálásba és “tudnál itt lassítani egy kicsit?” kommentekbe fulladt.

A Rive az első olyan eszköz, amivel ez a kör végre normálisan zár. Mostanra elég érett ahhoz, hogy ne csak demókban, hanem éles weboldalakon is használjuk. Ez a poszt arról szól, hogy a Rive animáció hol fér be a webes munkafolyamatba, és hogy mi marad így is a fejlesztő dolga.

Mit csinál máshogy a Rive

Röviden: ahelyett, hogy lefagyasztott animációt exportálnánk és JS-ből triggerelnénk, a Rive fájlon belül építünk egy állapotgépet. Vannak inputok, átmenetek, feltételek. Az animáció tudja, hogy mit kell csinálnia, neked nem kell minden lépést kívülről irányítanod.

Ezzel az átadás is megváltozik. A designer kiad egy .riv fájlt nevesített inputokkal (pl. isHovering, mood), és a weboldal csak beállítja az értékeket. Nincs többé visszafejtés.

Pár dolog, amiért egy Rive animáció megéri a tanulást:

  • Állapotgép a fájlban. A logika a motion mellett él, nem szétszórva a JS-ben.
  • Nevesített inputok és triggerek. Tiszta szerződés a design és a kód között.
  • Skálázható vektor. Ugyanaz a .riv jól néz ki 13 colos laptopon és 5K monitoron is.
  • Pici fájlméret. A karaktereink jellemzően 10 és 80 KB között vannak.
  • Egy forrás, sok platform. Web, iOS, Android, Flutter, game engine-ek.

Egy élő példa, nem stockból

Ez itt egy saját fájl a demóink közül. Az Advent Adventure jobb első referencia ide, mert látszik rajta, hogy a Rive animáció nem csak karakterloop lehet: kis jelenet, kattintható részek, hover állapotok, és közben továbbra is egyetlen .riv fájl.

A Triangle Mascot posztban egy kisebb Rive karakter animációt szedünk szét, ha a tisztább embed részletek és a state machine érdekel.

Mi marad a weboldal dolga

A .riv fájl csak a fél munka. A weboldalnak is hozzá kell tennie a magáét. Pár dolog, amibe rendszeresen belefutunk Rive fejlesztés közben:

  • Runtime választás. @rive-app/webgl2, ha kellenek a mesh deformációk és a feathering. @rive-app/canvas, ha fontosabb a bundle méret.
  • Canvas méretezés. Mindig a resizeDrawingSurfaceToCanvas()-t hívd az onLoad-ban, és sose állítsd be kézzel a canvas.width vagy canvas.height értékét. Az utóbbi szétlövi a renderert, és úgy néz ki, mintha a fájl lenne hibás.
  • Resize kezelés. Ablakméret, orientációváltás, layout shift. Mindegyiknél újra kell hívni a méretezést.
  • Takarítás. Unmountoláskor riveInstance.cleanup(). A runtime C++ objektumokat tart életben.
  • Több példány egy oldalon. useOffscreenRenderer: true, hogy közös renderert használjanak.
  • Fallback. SSR, lassú net, blokkolt domainek. Döntsd el előre, mi jelenik meg, ha a fájl nem tölt be.
  • QA. iOS Safarin teszteld korán. A meglepetések általában ott laknak.

Nem nehéz, de egyik sem szállítja le magát. Ezért mi a webes animáció Rive embedjét rendes komponensként kezeljük, nem egy elejtett <canvas> tag-ként.

Hol használjuk a Lupiannál

A Rive jó nekünk karakteres pillanatokra, onboardingra, dashboard widgetekre, hero animációkra és minden olyan apró interaktív részletre, ami régen Lottie vagy video lett volna. A demo oldalunkon van pár ilyen, data bindinggal együtt. A dev oldal az, ahol szándékosan törünk dolgokat.

Ha az érdekel, hogyan kerül be ez egy éles weboldalba, a fő Lupian oldal végig ezeket a Rive példákat használja.

Mi jön legközelebb

A következő posztban szétszedjük a Triangle Mascot fájlt. Utána szeretnénk rendesen írni a data bindingról, a több példányos performance-ről és pár tapasztalatról a scripting API-val. Ha van olyan, amiről te akarsz olvasni, írj nekünk.