Executando verificação de segurança...
12

🌸 Uma forma mais ELEGANTE de consumir API's

Prós e contras / quando utilizar a biblioteca react-query

Au au

O que é react-query e qual dor ela resolve ?

Por mais que a lib tenha mudado de nome ( para TanStack Query ), iremos chama-la de react-query por aqui, ok ?

No site da lib ela é descrita como : "A biblioteca de busca de dados ausente para aplicativos da web, mas em termos mais técnicos, torna muito fácil buscar, armazenar em cache, sincronizar e atualizar o estado do servidor em seus aplicativos da web. "

O que podemos interpretar para : "Sou uma lib que te ajuda a fazer seu fetch de forma mais eficaz por meio de hooks próprios, armazenar esses dados em cache para melhora de performance, fazer uma tela de loading mais fidedigna. Além de deixar o código mais legível e fácil de manuzear "

Qual outra forma de se fazer isso ?

Se já utilizou react em um projeto, provavelmente já se trombou com a seguinte sintaxe :

Codigo react consumindo api da forma tradicional.

Explicando o código seria :

Importar o axios e criar um state auxiliar pra cada funcionalidade ( error, data e loading ... ) :

Explicando os states.

Utilizar nosso amigo UseEffect para toda vez que o componente ( ou tela ) for carregado, chamar nossa função para bater na API e trazer esses dados para setar em nosso State de data.

Mas antes setamos nossos dois states de error e loading, para dar a impressão de que está "carregando.." e que "nao deu erro", o que é uma mentira, pois o que esta acontecendo é "ainda nao bati na api, nao sei o que esta rolando por la".

Dessa forma a primeira coisa que sua função faz nao é bater na api, mas sim setar os varios states.

Recomendo a leitura de " Why useEffect is a bad place to make API calls " : https://articles.wesionary.team/why-useeffect-is-a-bad-place-to-make-api-calls-98a606735c1c

Explicando o UseEffect.

e depois finalmente consumir esses dados e estados no nosso return em jsx :

Consumindo esses dados e estados no nosso return em jsx.

Por mais que não esteja tão fiel com a realidade, essa lógica ainda funciona ! E se seu app não tiver um número grande de usuarios e requisições, creio que esse código servirá sem grandes problemas ao seu propósito .

Qual dor o React-Query resolve ?

  • Tratamento de erros: o React Query fornece uma maneira integrada de lidar com erros de solicitações do servidor. Isso pode ajudá-lo a lidar facilmente com cenários de erro comuns, como falhas de rede e erros de servidor.
    Com isso, tchau tchau setIsError e derivados, agora controlar estados de error e Loading com hooks proprios do react-query ficou muito melhor :

  • Podemos tambem fazer uma pastinha chamada hooks e rechear de hooks com as requisições pra cada endpoint, ou api's.
    Com isso não precisaremos necessariamente ter esse corpo deselegante de useEffect com uma nova função de chamada em cada componente/tela .

  • Código simplificado: o React Query pode ajudar a simplificar seu código, reduzindo a quantidade de código clichê que você precisa escrever para lidar com as respostas do servidor.

👉🏽 E o diferencial chave da lib, pra mim é :

  • Cache: a camada de cache do React Query pode ajudar a melhorar o desempenho do aplicativo, reduzindo o número de solicitações de rede necessárias para recuperar dados.
    Isso pode melhorar a capacidade de resposta do aplicativo e reduzir a carga do servidor pra caramba.

  • Atualizações otimistas: o React Query permite que você atualize o cache com atualizações otimistas, o que significa que você pode atualizar a interface do usuário antes de aguardar a resposta do servidor. Isso pode fazer com que seu aplicativo pareça mais rápido e responsivo.

Quando não utilizar ?

Por melhor que seja a lib, temos que ter cuidado pra não utilizarmos de Over Engineering

  • Curva de aprendizado: o React Query tem sua própria API e pode levar algum tempo para aprender como usá-la de maneira eficaz. Também é necessário entender os conceitos subjacentes da biblioteca, como cache, invalidação e assim por diante.

  • Nem sempre necessário: para aplicativos menores, pode não ser necessário usar o React Query. Os recursos de cache e tratamento de erros podem não ser tão úteis em aplicativos de pequena escala, onde o desempenho não é uma grande preocupação.

  • Integração com código existente: se você estiver adicionando React Query a uma base de código existente, talvez seja necessário refatorar seu código existente para funcionar com a biblioteca. Isso pode ser demorado e aumentar a complexidade geral do seu código.

  • Sobrecarga: como qualquer biblioteca, o React Query tem uma sobrecarga em termos de tamanho e desempenho do pacote. Para aplicações pequenas, essa sobrecarga pode não ser justificada.

Considerações finais

Esse artigo não tem a intenção de te ensinar a utilizar o react-query, porém você pode seguir o passo a passo pela documentação :
https://tanstack.com/query/v4/docs/react/installation

Ou se precisar de um vídeo, temos a Fernanda Kipper :
https://www.youtube.com/watch?v=ZI9uLACYAd0

Ou um mais específico sobre cache :
https://www.youtube.com/watch?v=YmS5uo9ty2Q

Espero que esse post seja útil !
Para algum feedback ou mais conteúdo, me siga no twitter ou github

Carregando publicação patrocinada...
3

Show! Um ponto muito interessante que a galera não costuma sacar do React Query é que ele é primariamente um gerenciador de estados, e a grande mágica disso é que ao utilizá-lo você elimina uma tonelada de boilerplate que normalmente escreveria para controlar todo o fluxo de requisições, tem uma parte bem legal na doc sobre isso. Em resumo, sair de uma arquitetura que usa Redux para React Query + Zustand simplifica muito as coisas.

P.S.: Não vou cuspir no prato que comi hahahahaha, Redux Toolkit + RTK Query também é um ótimo combo, mas sem dúvidas menos intuitivo.

2
2

Legal mano, texto muito bem escrito. Aqui no trampo não utilizamos, vou dar uma estudada e apresentar a ferramentas pra galera, pois vamos fazer uma atualização completa do app e estamos na fase do levantamento de ferramentas que vamos usar.

1

React Query é uma excelente ferramenta, utilizo já a pouco mais de um ano e as vezes ele quebra um galho muito bom em caching quando o Backend não prove de forma correta

1
2

coloquei ali no exemplo,nao é deselegante, só é menos escalavel ( talvez ) .. mas ainda acho que toda a forma é valida, basta saber em qual contexto utilizar !

1
3

Na verdade o axios faz as chamadas pelo metódo GET por padrão, então se é esse o método que você precisa não é necessário defini-lo na requisição.

1
1

Usamos em todos os fronts react que temos na empresa que trabalho, simplesmente facilita muito a vida e dá uma experiência de usuário bem melhor por conta do cache e dos updates otimistas.

Única coisa que tivemos que alterar foi trocar o cache pra ser armazenado no indexeddb ao invés do localStorage, as vezes o localStorage lotava de tanto cache e atrapalhava um pouco outras funcionalidades que utilizam diretamente o localStorage.

1

Que interessante. Ta tendo um movimento de volta ao MPA e essa lib ajuda muito
na questão do movimento de volta a deixar o estado no servidor!

0
2

Não existe forma burra. Existem diversas formas de ser implementado, boas e ruins. A utilização do react-query traz facilidades no que diz respeito a tratamento de cache, erros e feedback para o usuário, sendo assim o desenvolvedor não precisa criar diversos estados auxiliares para suprir esses tratamentos, tão pouco lidar com os mesmos de forma manual (como no exemplo do setLoading e/ou cacheamento do lado do cliente).