Implementando atualizações otimistas manualmente

As atualizações otimistas manuais começam com o estado local do componente inicializado com dados do servidor: const [items, setItems] = useState(serverItems). Esse estado local é o que você exibe e o que modificará de forma otimista. Você NOT deve modificar diretamente os dados obtidos do servidor — mantenha uma cópia local sob seu controle.

Quando o usuário inicia uma mutação (clicando em "Adicionar", "Curtir" ou "Excluir"), faça a atualização do estado imediatamente, antes de chamar a API: setItems(prev => [...prev, newItem]). A interface reflete a alteração instantaneamente. Somente depois dessa atualização você envia a solicitação de rede real.

Antes de fazer a atualização otimista, capture o estado atual: const previousItems = items. Esse instantâneo é o seu ponto de reversão. Se a chamada à API falhar, você restaura esse valor. Armazene-o em uma variável (não no estado), pois só precisará dele durante a mutação pendente.

Depois da atualização otimista, faça a chamada à API de forma assíncrona. Envolva-a em try/catch. Em caso de sucesso, você pode opcionalmente buscar os dados novamente para sincronizá-los com o estado do servidor ou confiar no estado otimista se o servidor retornaria os mesmos dados. Em caso de falha, use o estado anterior capturado para fazer a reversão.

No bloco de tratamento de erro da mutação: setItems(previousItems). Isso restaura o estado para o que era antes da atualização otimista. Depois da reversão, exiba uma notificação de erro. Os usuários entendem que falhas raras acontecem — o que não toleram é uma inconsistência silenciosa.

Depois de fazer a reversão, exiba uma mensagem de erro: "Não foi possível salvar as alterações. Tente novamente." com um botão "Tentar novamente" que execute a mesma mutação outra vez. Isso dá autonomia aos usuários. A combinação de reversão + notificação de erro + nova tentativa trata o caso de falha de forma adequada, sem bloquear toda a interface.

Ao adicionar um novo item de forma otimista, o servidor ainda não atribuiu um ID real. Crie um ID temporário para o item otimista: const tempId = crypto.randomUUID(). Use-o como chave do item na lista. Depois que a API responder com sucesso, substitua o ID temporário pelo ID real atribuído pelo servidor.

Depois de uma mutação de criação bem-sucedida, o servidor responde com o ID real. Atualize o estado para substituir o item temporário: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Essa reconciliação garante que as operações seguintes usem o ID correto do servidor.

Se o usuário iniciar duas mutações em rápida sucessão, as respostas poderão chegar fora de ordem. A resposta da segunda mutação pode chegar antes da primeira, e a reversão da primeira pode substituir o estado correto resultante da segunda. Essa é uma condição de corrida específica das interfaces otimistas.

Uma solução para condições de corrida é serializar as mutações usando uma fila. Enquanto uma mutação estiver em andamento, desative o botão acionador (definindo o estado isSubmitting como verdadeiro). Permita a próxima mutação somente depois que a anterior for concluída. Isso sacrifica parte da capacidade de resposta, mas garante a ordem correta do estado.

Para operações de exclusão: capture os itens anteriores, filtre o item excluído do estado, chame a API de exclusão e reverta em caso de falha. A exclusão é mais simples que a criação (não há reconciliação de ID), mas os mesmos princípios se aplicam. Considere adicionar um breve atraso antes da exclusão (exibindo uma opção de "desfazer") antes de fazer a chamada à API.

Por que os itens adicionados de forma otimista precisam de um ID temporário?

O padrão manual: capture previousItems, use setItems com o novo estado, faça a chamada à API, reverta em caso de falha usando setItems(previousItems) e mostre um erro. Para adições, use crypto.randomUUID() como ID temporário e faça a reconciliação com o ID do servidor em caso de sucesso. Evite condições de corrida desativando o acionador durante as mutações em andamento. Reversão + notificação + nova tentativa é a experiência de usuário padrão para falhas.