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
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.
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.
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).
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
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.
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.