Kada promenite vrednost jedne promenljive u Reactu, SolidJS-u ili Vue-u, interfejs se gotovo trenutno prilagođava novom stanju. Iza tog naizgled jednostavnog procesa krije se jedan od najvažnijih problema u razvoju modernih aplikacija. Kako ažurirati samo ono što je zaista promenjeno, bez nepotrebnog izvršavanja koda i bez prikazivanja nekonzistentnih podataka korisniku?
To pitanje dovelo je do razvoja različitih modela reaktivnosti, odnosno načina na koji sistem prati zavisnosti između podataka i odlučuje kada nešto treba ponovo izračunati. Iako većina programera svakodnevno koristi frameworks-ove koji rešavaju ovaj problem umesto njih, upravo izbor modela reaktivnosti često određuje koliko će aplikacija biti brza, skalabilna i laka za održavanje.
Reaktivnost je mnogo više od automatskog osvežavanja interfejsa
Najlakši način da se razume reaktivnost jeste kroz spreadsheet. Zamislite tabelu sa stotinama ili hiljadama formula. Kada promenite jednu ćeliju, ne treba ponovo izračunati celu tabelu, već samo formule koje od nje zavise.
Potpuno isti princip koriste moderni frameworks. Svaka promena stanja pokreće lanac zavisnosti koji na kraju dovodi do ažuriranja korisničkog interfejsa.
Na papiru to zvuči jednostavno, ali u velikim aplikacijama graf zavisnosti može sadržati desetine hiljada čvorova. Zbog toga dobar reaktivni sistem mora da ispuni nekoliko važnih uslova.
Pre svega, isti podatak ne bi smeo da se računa više puta tokom jednog ciklusa ažuriranja. Zatim, potrebno je izračunati samo one delove sistema koji su zaista pogođeni promenom. Korisnik nikada ne bi smeo da vidi privremeno nekonzistentno stanje u kojem je jedan deo interfejsa ažuriran, a drugi još uvek prikazuje stare podatke. Uz to, moderne aplikacije često zahtevaju i dinamičke zavisnosti, odnosno mogućnost da se veze između čvorova menjaju tokom izvršavanja aplikacije.
Upravo način na koji različiti sistemi rešavaju ove probleme deli ih na nekoliko osnovnih pristupa.
Push model je brz, ali lako može da napravi višak posla
Kod push reaktivnosti svaki čvor koji promeni vrednost odmah obaveštava sve čvorove koji od njega zavise. Promena se praktično "gura" kroz ceo graf zavisnosti dok ne stigne do krajnjih rezultata.
To je razlog zbog kog se ovaj model koristi u brojnim event sistemima, observable bibliotekama i stream arhitekturama. Čak se i Promise lanci mogu posmatrati kao pojednostavljena verzija push reaktivnosti, gde svaka naredna operacija čeka rezultat prethodne.
Najveća prednost ovog pristupa jeste njegova preciznost. Ako se promeni samo jedan podatak, sistem neće dirati ostatak aplikacije, već će obraditi isključivo zavisne delove.
Problem nastaje kada više različitih puteva vodi do istog čvora. U takvoj situaciji isti deo sistema može biti izračunat nekoliko puta tokom jednog ažuriranja, iako je dovoljan samo jedan prolaz.
Zamislite komponentu koja zavisi od dva različita podatka. Ako oba podatka promene vrednost gotovo istovremeno, ista komponenta može dobiti dva ili više zahteva za ponovnim izračunavanjem. Kod malih aplikacija razlika je zanemarljiva, ali u velikim sistemima ovakvo ponašanje može značajno povećati broj nepotrebnih operacija.
Postoji još jedan problem koji programeri nazivaju glitch. To je kratkotrajno stanje u kojem je jedan deo aplikacije već izračunao nove vrednosti, dok drugi još uvek koristi stare podatke. Ako aplikacija u tom trenutku pročita stanje sistema, može dobiti rezultat koji nikada nije trebalo da postoji.
Zbog toga implementacija push modela često zahteva dodatne algoritme za određivanje redosleda izvršavanja kako bi svaki čvor bio obrađen tačno jednom i u pravom trenutku.
Pull model razmišlja potpuno drugačije
Ako push model šalje promene unapred kroz sistem, pull reaktivnost radi upravo suprotno. Umesto da čvorovi međusobno šalju obaveštenja, svaki od njih traži najnovije vrednosti svojih zavisnosti tek kada mu one zaista zatrebaju.
Na prvi pogled, ovaj pristup podseća na običan lanac funkcijskih poziva. Jedna funkcija poziva drugu, ona zatim poziva sledeću i tako sve dok se ne izračuna konačan rezultat.
Upravo zbog toga pull modeli prirodno rešavaju jedan od najvećih problema push pristupa. Pošto se ceo lanac izvršava u jednom prolazu, mnogo je teže doći do nekonzistentnih međustanja koja mogu izazvati glitch.
Međutim, ovaj model otvara sasvim novi izazov. Kako sistem uopšte zna koje delove aplikacije treba ponovo izračunati ako nigde ne čuva informaciju o tome ko od koga zavisi?
Zašto ni push ni pull nisu dovoljno dobri
Iako oba pristupa imaju ozbiljne prednosti, nijedan ne rešava sve probleme modernih aplikacija.
Kod push modela najveći izazov predstavlja kontrola redosleda izvršavanja. Što graf zavisnosti postaje složeniji, raste i verovatnoća da će isti čvor biti obrađen više puta ili da će aplikacija nakratko završiti u nekonzistentnom stanju.
Sa druge strane, pull model nema taj problem, ali uvodi drugi. Sistem često nema predstavu koji će izlazni podaci zaista biti pogođeni promenom ulaza, pa lako može da završi tako što ponovo računa mnogo više nego što je potrebno.
Zbog toga pull sistemi gotovo uvek zavise od keširanja. Jednom izračunata vrednost čuva se kako bi mogla ponovo da se iskoristi, ali tada nastupa dobro poznati problem cache invalidation. Čim se promeni jedan ulazni podatak, sistem mora tačno da zna koje keširane vrednosti više nisu validne. Upravo zbog toga se cache invalidation godinama smatra jednim od najtežih problema u softverskom inženjerstvu.
Push-pull model pokušava da spoji najbolje iz oba sveta
Umesto da bira između dva pristupa, veliki broj modernih frameworks-a koristi push-pull reaktivnost.
Ideja je iznenađujuće jednostavna.
Prvi korak koristi logiku push modela, ali bez izračunavanja novih vrednosti. Kada se promeni neki ulazni podatak, sistem samo prolazi kroz graf zavisnosti i označava sve čvorove koji će morati da budu ponovo obrađeni. Oni dobijaju takozvani dirty status.
U toj fazi ne izvršava se nijedna skupa operacija. Sistem samo pamti šta je postalo zastarelo.
Tek nakon toga dolazi pull faza.
Kada aplikaciji zaista zatreba nova vrednost, engine prolazi samo kroz čvorove označene kao dirty, računa njihove nove rezultate, čisti oznake i vraća sistem u konzistentno stanje.
Drugim rečima, push faza odgovara na pitanje šta treba ažurirati, dok pull faza rešava pitanje kada i kako to ažurirati.
Zašto ovaj pristup odgovara modernim frameworks-ima
Ovakva organizacija rada donosi nekoliko važnih prednosti.
Svaki čvor obrađuje se samo jednom tokom jednog ciklusa ažuriranja. Delovi aplikacije koji nisu pogođeni promenom ostaju potpuno netaknuti. Pošto se računanje obavlja tek kada su sve potrebne informacije dostupne, izbegavaju se i privremena nekonzistentna stanja koja mogu izazvati glitch.
Još važnije, sistem zadržava podršku za dinamičke zavisnosti. Komponente mogu da menjaju svoje veze sa drugim delovima aplikacije tokom izvršavanja bez potrebe za skupim ponovnim organizovanjem kompletnog grafa.
Upravo zbog toga slični principi danas postoje u brojnim modernim bibliotekama i frameworks-ima. Iako implementacije nisu identične, cilj je isti. Minimizovati broj izračunavanja, sačuvati konzistentnost podataka i omogućiti da aplikacija ostane brza čak i kada broj komponenti nastavi da raste.
Reaktivnost je danas pitanje arhitekture, a ne samo performansi
Programeri često reaktivnost povezuju isključivo sa bržim renderovanjem korisničkog interfejsa. Međutim, njen značaj je mnogo širi.
Način na koji framework upravlja zavisnostima direktno utiče na potrošnju memorije, opterećenje procesora, predvidivost izvršavanja i složenost održavanja aplikacije. Kako projekti rastu, upravo ove razlike počinju da određuju da li će sistem ostati jednostavan za razvoj ili će svaka nova funkcionalnost dodatno komplikovati postojeći kod.
Zbog toga se rasprava o push i pull modelima ne vodi samo među autorima frameworks-a. Ona postaje sve važnija i za razvojne timove koji žele da razumeju šta se zapravo dešava ispod apstrakcija koje svakodnevno koriste.
Na kraju, ne postoji univerzalno najbolje rešenje. Push modeli nude jednostavnu distribuciju promena, pull modeli olakšavaju održavanje konzistentnosti, dok push-pull reaktivnost predstavlja kompromis koji u praksi uspešno spaja prednosti oba pristupa. Upravo zato danas čini osnovu mnogih savremenih frameworks-a i ostaje jedan od najznačajnijih obrazaca u razvoju modernih web aplikacija.
0 komentara