Kui süveneme tänapäevaste rakenduste arenduse maailma, mõistame, et olek on lihtsalt iga väärtus, mis aja jooksul muutub. Olgu tegemist lihtsa muutuja, ruumi andmebaasi või puutetundliku animatsiooniga, olek määrab, mida kasutaja igal hetkel näeb. Selle teabe salvestamise ja värskendamise valdamine on erinevus laitmatult töötava rakenduse ja seletamatute vigadega täidetud rakenduse vahel.
Deklaratiivsetes keskkondades nagu Jetpack Compose või React muutub mõtteviis täielikult: me ei muuda enam ekraanielemente käsitsi, vaid kirjeldame liidest praeguse oleku põhjal . Kui olek muutub, joonistatakse liides automaatselt ümber, seda protsessi nimetatakse ümberkompositsiooniks. Selleks, et see sujuvalt toimiks, vajame selgeid mustreid, mis väldivad andmete ebajärjekindlust.
Jetpack Compose'i riigi põhitõed
Compose'i mõistmiseks peate leppima sellega, et ekraani värskendamise ainus viis on funktsiooni uuesti kutsumine värskendatud argumentidega . Kui proovite tekstivälja kasutada ilma selle olekut haldamata, märkate, et see ei kuva midagi; see juhtub seetõttu, et komponent ei muuda ennast, vaid peegeldab pigem saadud väärtust.
Selle lahendamiseks on meil remember API , mis võimaldab meil objekti esialgse komponeerimise ajal mällu salvestada ja selle järgnevate rekomponeerimiste ajal taastada. Kui soovime, et andmed jääksid ellu ka ekraani pööramise või konfiguratsiooni muutmise korral, on ideaalne lahendus kasutada rememberSaveable , mis salvestab teabe süsteemipaketti.
Kui me räägime muutujatest, mis peaksid käivitama visuaalseid muutusi, kasutame mutableStateOf . See loob jälgitava oleku, mis muutmisel annab Compose'ile käsu rekomponeerida kõik funktsioonid, mis seda konkreetset väärtust loevad.
Tugeva riigi täiustatud mustrid
Ainult muutujate salvestamisest ei piisa; rakenduse skaleeritavuse tagamiseks peame rakendama ühtse tõeallika (SSOT) põhimõtte . See tähendab, et kõik ekraaniolekud pärinevad ühest autoriteetsest allikast, tavaliselt suletud klasside või liideste kaudu, mis defineerivad kõik võimalikud kasutajaliidese stsenaariumid, tagades seega, et kompilaator sunnib meid iga olekut käsitlema.
Teine oluline sammas on oleku muutumatus . Olemasoleva objekti muutmise asemel loome soovitud muudatustega uue koopia (kasutades andmeklasside „kopeerimismeetodit”). See väldib kardetud võidujooksutingimusi samaaegsetes keskkondades ning muudab oleku üleminekud jälgitavaks ja hõlpsasti silutavaks.
Tsükli lõpuleviimiseks rakendasime sündmustepõhised uuendused . Selle asemel, et kasutajaliides olekut otse muudaks, saadab see sündmuse (näiteks klõpsu või trükitud teksti) ülesvoolu ja oleku omanik otsustab, kuidas seda töödelda. See mudel on ühesuunalise andmevoo (UDF) alus , kus olek voolab alla komponentideni ja sündmused voolavad üles loogikasse.
Olekukonteinerid: ViewModel vs Flat klassid
Sõltuvalt keerukusest saame valida, kuhu loogika paigutada. Android ViewModel on äriloogika jaoks parim valik. Selle peamine eelis on see, et see jääb ellu ka pärast tegevuse taasloomist ning integreerub sujuvalt Navigationi ja Hiltiga, võimaldades andmetel rakenduses navigeerimise ajal säilida.
Teisest küljest on olemas kasutajaliidese loogika oleku konteinerid , mis on tavaliselt lihtsad, vormindamata klassid. Need tegelevad lühiajalisemate ülesannetega, näiteks kas nuppu tuleks kuvada kerimisasendi põhjal või õiguste haldamisega. Erinevalt ViewModelist on neil sama elutsükkel kui liidesel ja need luuakse tavaliselt kohandatud meeldejätmisfunktsioonide abil.
On ülioluline mitte edastada ViewModeli otse alamkomponentidele, kuna see seoks vaate loogikaga ja muudaks testimise keerulisemaks. Õige lähenemisviis on edastada ainult vajalikud olekud ja delegeerida sündmused lambda-avaldiste abil, säilitades seeläbi modulaarsuse ja lihtsustades eelvaadete loomist.
Testimis- ja kvaliteedistrateegiad
Kui olek on muutumatu ja sündmustepõhine, muutub rakenduse testimine tõeliselt nauditavaks ülesandeks. Saame kontrollida, kas ViewModel toodab vastuseks konkreetsele sündmusele oodatud uuenduse ilma graafilist liidest käivitamata, esitades otseseid väiteid saadud oleku kohta.
Kasutajaliidese testimisel peaks keskenduma sellele, et komponendid kajastaksid täpselt oma olekut ja et kasutaja interaktsioonid käivitaksid õiged sündmused. Loogika esitusest eraldades saame iga osa eraldi testida, tagades, et vea- või laadimisolekud kuvatakse õigesti.
Osariikide haldamine React ökosüsteemis
Kuigi me räägime Androidist, on kontseptsioonid väga sarnased Reactis toimuvaga. Ka siin on olemas lokaalne olek , mida haldab `useState` konks, mis võimaldab igal komponendil hallata oma sisemisi andmeid. Kui meil on vaja teabe jagamiseks mitut komponenti, kasutame andmete edastamiseks vanemalt lapsele propse.
Rekvisiitide liiga paljudele tasemetele edastamise (prop-ide puurimise) probleemi vältimiseks pakub React konteksti `useContext` kaudu , luues tsentraliseeritud andmesalvestuse. Suuremahulistes rakendustes kasutatakse sageli Reduxit , mis rakendab poodi, toiminguid ja reduktoreid oleku prognoositavaks ja globaalseks haldamiseks.
Nagu Compose'i puhul, ei manipuleeri React DOM-iga käsitsi; selle asemel kirjeldab see erinevate visuaalsete olekute liidest . Andmevoog jääb võtmetähtsusega: olekut värskendatakse kindlate funktsioonide abil, mis põhjustab komponentide uue teabega uuesti renderdamise.
Arhitektuur, kus olek on ennustatav ja loogika vaatest eraldatud, võimaldab palju sujuvamat arendust. Olenemata sellest, kas kasutate Androidis ViewModelsi, veebis Reduxit või lihtsalt oleku ülendamist vanemkomponendiks, peitub võti andmete järjepidevuse säilitamises ja ühesuunalise voolu austamises, et rakendus oleks pikaajaline hooldatav.