Optimististen päivitysten manuaalinen toteuttaminen

Manuaaliset optimistiset päivitykset alkavat palvelimen tiedoista alustetusta paikallisesta komponentin tilasta: const [items, setItems] = useState(serverItems). Tämä paikallinen tila renderöidään, ja sitä muutetaan optimistisesti. Palvelimelta haettuja tietoja EI pidä muuttaa suoraan — säilytä sen sijaan hallinnassasi oleva paikallinen kopio.

Kun käyttäjä käynnistää mutaation (napauttaa painiketta "Lisää", "Tykkää" tai "Poista"), päivitä tila heti ennen API:n kutsumista: setItems(prev => [...prev, newItem]). Käyttöliittymä näyttää muutoksen välittömästi. Varsinainen verkkopyyntö lähetetään vasta tämän päivityksen jälkeen.

Tallenna nykyinen tila ennen optimistisen päivityksen tekemistä: const previousItems = items. Tämä tilannevedos toimii palautuksen kohteena. Jos API-kutsu epäonnistuu, palauta tämä arvo. Tallenna se muuttujaan, älä tilaan, koska tarvitset sitä vain odottavan mutaation ajan.

Tee API-kutsu optimistisen päivityksen jälkeen asynkronisesti. Käytä sen ympärillä try/catch-rakennetta. Onnistumisen jälkeen voit halutessasi hakea tiedot uudelleen palvelimen tilan kanssa synkronoimiseksi tai luottaa optimistiseen tilaan, jos palvelin palauttaisi samat tiedot. Virheen sattuessa palauta tila tallennetun aiemman tilan avulla.

Lisää mutaation catch-lohkoon: setItems(previousItems). Tämä palauttaa tilan optimistista päivitystä edeltäneeseen muotoon. Näytä palautuksen jälkeen virheilmoitus. Käyttäjät ymmärtävät, että harvinaisia virheitä tapahtuu — mutta he eivät hyväksy hiljaista epäjohdonmukaisuutta.

Näytä palautuksen jälkeen virheilmoitus: "Muutoksia ei voitu tallentaa. Yritä uudelleen." Lisää mukaan Uudelleenyritys-painike, joka käynnistää saman mutaation uudelleen. Näin käyttäjä voi itse vaikuttaa tilanteeseen. Palautuksen, virhetoastin ja uudelleenyrityksen yhdistelmä käsittelee virhetilanteen hallitusti estämättä koko käyttöliittymää.

Kun lisäät uuden kohteen optimistisesti, palvelin ei ole vielä antanut sille oikeaa tunnistetta. Luo optimistiselle kohteelle väliaikainen tunniste: const tempId = crypto.randomUUID(). Käytä sitä kohteen avaimena luettelossa. Kun API vastaa onnistuneesti, korvaa väliaikainen tunniste palvelimen antamalla oikealla tunnisteella.

Onnistuneen luontimutaation jälkeen palvelin palauttaa oikean tunnisteen. Päivitä tila ja korvaa väliaikainen kohde: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Tämän yhteensovittamisen ansiosta myöhemmät toiminnot käyttävät oikeaa palvelimen tunnistetta.

Jos käyttäjä käynnistää kaksi mutaatiota nopeasti peräkkäin, vastaukset voivat saapua eri järjestyksessä kuin pyynnöt. Toisen mutaation vastaus voi saapua ennen ensimmäistä, jolloin ensimmäisen mutaation palautus saattaa korvata toisen mutaation tuottaman oikean tilan. Tämä on optimistiselle käyttöliittymälle ominainen kilpailutilanne.

Yksi ratkaisu kilpailutilanteisiin on suorittaa mutaatiot järjestyksessä jonon avulla. Kun mutaatio on käynnissä, poistakaa laukaisupainike käytöstä (asettamalla isSubmitting-tilan arvoksi true). Sallikaa seuraava mutaatio vasta, kun edellinen on valmis. Tämä heikentää hieman käyttöliittymän reagointinopeutta, mutta takaa tilan oikean järjestyksen.

Poistotoiminnoissa tallentakaa aiemmat kohteet, suodattakaa poistettava kohde pois tilasta, kutsukaa poisto-APIa ja palauttakaa tila virheen sattuessa. Poistaminen on luomista yksinkertaisempaa (tunnisteita ei tarvitse sovittaa yhteen), mutta samat periaatteet pätevät. Harkitkaa lyhyen viiveen lisäämistä ennen poistamista (näyttäkää "kumoa"-vaihtoehto) ennen API-kutsun tekemistä.

Manuaalinen toimintamalli: tallentakaa previousItems, asettakaa uusi tila setItems-kutsulla, tehkää API-kutsu, palauttakaa tila virheen sattuessa komennolla setItems(previousItems) ja näyttäkää virheilmoitus. Käyttäkää lisäyksissä crypto.randomUUID()-funktiota väliaikaisena tunnisteena ja sovittakaa se palvelimen tunnisteen kanssa yhteen onnistumisen jälkeen. Estäkää kilpailutilanteet poistamalla laukaisin käytöstä mutaatioiden ollessa käynnissä. Palautus + toast-ilmoitus + uudelleenyritys on vakiintunut tapa käsitellä virheitä käyttöliittymässä.