devel.cz

Actor Model (AM) resi concurrent pristup k nejakemu stavu. Myslim, ze uplne stejne vyhody v jednovlaknovem prostredi JS se daji ziskat enkapsulaci stavu v normalnich objektech, ktere reprezentuji komponenty.

Immutability v UI je pak jen odpovedi na asynchronicitu JS a jeji inherentni slozitost. V prostredi jednoho vlakna pak AM dava vicemene jen zaruky zachovanych invariantu mezi zpracovanim dvou zprav, cehoz se podle me ale da uplne stejne dosahnout i za pomoci normalni funkci, protoze se nebudou vykonavat paralelne. Spravnost tech invariantu musi v obou pripadech autor stejne resit sam, concurrency model uz se pak jen postara o jejich zachovani.

Kompozici potom AM resi stejne jako objekty, akorat u vetsiny AM implementaci je misto jednoducheho new nebo IoC potreba resit vlastni spravu proxy objektu (i kdyz v pripade JS tam bude ta proxy nadbytecna).

V cem by AM implementace mohly trochu pomoct, je error handling. Failovani/zahazovani/znovuvytvareni actoru je vec, ktera sice stoji mimo AM samotny, ale z praktickych duvodu to snad vsechny "vazne" AM implementace nejak resi. Je mnohem pohodlnejsi si nastavit supervisor, ktery mi v pripade chyby znovuvytvori actor v nejakem default stavu, nez abych na kazde urovni nejak resil try/catch a nebo nechal vsechny chyby probublat az do top-level handleru a uzivateli napsal "Neco se pokazilo". Nemam ale zdani, jak si v tomhle stoji JS implementace. Taky mi prijde, ze tohle je vec vhodnejsi spis pro vypocetni nebo IO actory, zatimco UI actor asi moc casto nebude fatalne failovat.

Moje rada zni, ze pokud se v jednovlaknovem JS UI chces drzet mutable stavu jednotlivych komponent, AM neda o moc vic, nez rozumne navrzene objekty s enkapsulovanym stavem.