Executando verificação de segurança...
4
deployDeSexta
1 min de leitura ·

FrontEnd: Fetch após atualização no banco ou modificar o state? 🤔#opinião

Boas pessoal! 👋

Atuando em projetos já trabalhei de ambas formas, e direto me coça a cabeça... depois de um POST, insere/deleta/modifica direto no state, ou faz um GET pra atualizar o state por completo? Quero saber a opinião de vocês! 🤔

Opção 1: Fazer um fetch pra buscar os dados atualizados do servidor? 🔄
Opção 2: Modificar diretamente o state do componente? ⚡️

Sei que as duas opções têm seus prós e contras, mas às vezes fico em dúvida sobre qual usar em cada situação.

Pensei em alguns pontos:

  • Consistência dos dados: Se eu modificar o state direto, corro o risco de ter dados inconsistentes, né? 😖
  • Performance: Será que fazer um fetch toda vez que atualizar o banco não pesa na performance? 🤔
  • Experiência do usuário: Mudar o state direto deixa a interface mais fluida, mas e se os dados não estiverem 100% sincronizados? #ferrou kk' 😕

E aí, qual a opinião de vocês? Me ajudem a decidir! 🙏

#react #javascript #frontend #webdev #state #fetch #api #database #discussao #duvida

Carregando publicação patrocinada...
6
Robindark

As vezes você quer ter uma melhor experiência de usuário tendo uma atualização otimista e quer que a interface seja atualizada imediatamente após uma ação e antes de receber a confirmação do servidor. Nesse caso você pode reverter o estado caso a requisição falhe mostrando algum tipo de mensagem de erro para o usuário.

Imagine que você está desenvolvendo uma funcionalidade de "like" para posts em uma rede social. Quando o usuário clica no botão de like, você quer que o feedback visual seja imediato, mas a ação real de registrar o like depende de uma requisição ao backend demora um certo tempo.

Essa abordagem melhora a responsividade da interface, fazendo o usuário sentir que suas ações têm efeito instantâneo, mesmo em cenários de latência de rede.

1
faustinopsy

eu como usuário nao gosto dessa abordagem, visto que o LinkedIn age assim, muitas vezes faco reação e vou embora, mas depois de um tempo volto e a reação nao foi feita, pois ela é desfeita.

1
devcarlosalberto

Eu faço da utilização de interface otimista mas enquanto lia o post pensei a mesma coisa que o @faustinopsy no comentário ao lado, para uma rede social por exemplo a pessoa der um like e voltar no histórico de curtidas pode se deparar com a falta de uma curtida que ela fez para voltar ao post (por exemplo). Acho que pra uma interface otimista o backend precisar ter como tratativa para todos os possíveis erros até que uma curtida por exemplo seja processada.

Agora imagine um sistema onde o usuário edita seu perfil, uma interface otimista seria ótima.

5
wbartz

Eu normalmente prefiro não fazer um novo fetch, ou espero o BFF (quando existe) me retornar os dados atualizados na própria resposta do PATCH/PUT/POST (quando eu construo o BFF, costumo usar essa abordagem para evitar novos fetchs), ou utilizo a abordagem do Front otimista, assumindo que houve sucesso e atualizando o state, ai se caso o back me retornar algum erro, informo isso ao usuário.
Considerando que o front aguarde a requisição dar sucesso, e só então você atualizar o state, na grande maioria da vezes não deve ter problemas de sincronia entre os dados.

2
lipeneves

Eu faço um novo fech, pois em todas as empresas que trabalhei esse era o padrão que eles usavam, e nunca achei que o ganho de performance valesse a pena o esforço de atualizar localmente, a não ser quando vou trabalhar com react native, aí uso offline first (mas aí já é outro caso).

2
klawdyo

As minhas requisições de criação e de atualização retornam o objeto atualizado. Assim eu o adiciono ou o atualizo no state.
Eu não atualizo logo quando crio/edito pois geralmente meus posts só vão com os dados mínimos necessários e muitas outras coisas são criadas no backend de acordo com as regras de negócios.
Por exemplo:
Pra criar um pedido é um array de objetos com o id do produto e quantidade. O cliente é só um id. Endereço é só um id. Mas o retorno volta completão pra eu meter no state

2
clacerda

Após um POST para criar um recurso, o servidor deve responder com 201 Created e um cabeçalho Location contendo o URI do novo recurso. O cliente deve então fazer um GET para esse URI. Essa é a forma correta segundo o padrão HTTP (RFC 7231). Modificar o state localmente sem confirmação do servidor (via GET após o POST) pode levar a inconsistências e só deve ser feito com muita cautela em casos específicos, como atualizações otimistas. Portanto, a resposta é sempre usar o Location e um GET.

2
RafaellaDenlavor

Você pode utilizar libs como SWR ou React Query pra assim que uma requisição POST for realizada para modificar um dado, você invalidar os dados atuais e ele irá efetuar uma nova requisição em busca dos dados frescos.

Assim como também consegue atualizar os dados em casos como: a internet acabou de voltar após uma queda, revalidar dados assim que o usuário volta pra aba da aplicação, entre outros casos.