RTK Query é uma biblioteca experimental da equipe do Redux com o objetivo principal de buscar e armazenar dados em cache para seu aplicativo da web. O RTK Query utiliza o Redux por baixo do capô e é construído sobre a Redux Tool k it . O RTK Query oferece opções de configuração avançadas para lidar com suas necessidades de busca e armazenamento em cache da maneira mais flexível e eficiente possível.
Embora o RTK Query utilize o Redux por baixo do capô, isso não significa que você precisa de um conhecimento sofisticado do Redux para trabalhar com ele. Mas aprender Redux e RTK irá percorrer um longo caminho para aproveitar os recursos de gerenciamento de estado que o RTK Query pode fornecer para seu aplicativo da web.
Por que você usaria RTK Query?
Hoje, o RTK Query ainda está em seu estágio alfa, o que significa que ainda está sujeito a várias mudanças importantes em sua arquitetura e API. No entanto, ele já oferece uma solução simples e eficiente para cache e busca de dados.
O RTK Query foi construído para atender à necessidade de buscar dados ao usar o Redux como seu sistema de gerenciamento de estado. O RTK Query pode ser adicionado como um middleware e fornece poderosos React Hooks para ajudar a buscar seus dados. Apesar de seu nascimento, é seguro dizer que quando o RTK Query entrar em produção, ele será um candidato perfeito para buscar dados em aplicativos JavaScript de todos os tamanhos.
Em um pequeno aplicativo React típico (sem Redux), você poderá buscar dados com o ApiProvider que está integrado. Por outro lado, em um aplicativo maior (usando Redux), você ainda pode conectar RTK Query como um middleware em sua loja.
O agnosticismo do RTK Query facilita a integração com qualquer framework capaz de usar Redux (Vue.js, Svelte, Angular, etc.). Observe que, embora o RTK Query seja cunhado como agnóstico, ele também é extremamente opinativo, seguindo os paradigmas estabelecidos de Redux. Além disso, o RTK Query é construído com TypeScript, fornecendo suporte a tipos de primeira classe.
Buscando e armazenando dados em cache com RTK Query
Comecemos pelo princípio-você precisa configurar seu projeto para usar o RTK Query. Precisamos criar uma definição de serviço que irá buscar em nossa API pública. Para este exemplo, estamos usando uma API de Dungeons & Dragons :
import {createApi, fetchBaseQuery} de"@ rtk-incubator/rtk-query"; //Crie seu serviço usando um URL base e terminais esperados
export const dndApi=createApi ({ reducerPath:"dndApi", baseQuery: fetchBaseQuery ({baseUrl:"https://www.dnd5eapi.co/api/"}), pontos finais: (construtor)=> ({ getMonstersByName: builder.query ({ consulta: (nome: string)=> `monstros/$ {nome}` }) })
}); exportar const {useGetMonstersByNameQuery}=dndApi;
Conforme mencionado nos documentos , RTK Query prefere centralizar sua configuração de busca de dados, o que é improvável em diferentes bibliotecas de busca de dados-parte do que o torna opinativo. Centralizar nossa configuração tem seus prós e contras. Por exemplo, manter nossos ganchos de busca juntos não é uma má ideia, mas isso pode se tornar rapidamente complicado se trabalhar com uma API extensa.
A próxima etapa é adicionar este serviço à nossa loja adicionando nosso redutor gerado e nosso middleware de API. Isso ativará o armazenamento em cache, pré-busca, pesquisa e outros recursos de consulta RTK.
export const store=configureStore ({ redutor: {[dndApi.reducerPath]: dndApi.reducer}, middleware: (getDefaultMiddleware)=> getDefaultMiddleware (). concat (dndApi.middleware)
});
Em seguida, você precisa envolver o provedor, como faria com uma loja Redux básica, então você pode consultar seus componentes usando o gancho de consulta definido anteriormente.
import * as React from"react";
import {useGetMonstersByNameQuery} de"./services/dnd";
função padrão de exportação App () {
//Usar um gancho de consulta busca automaticamente os dados e retorna os valores da consulta
const {dados, erro, isLoading}=useGetMonstersByNameQuery ("aboleth");
Retorna ( {erro? (²²²²²²²²² <> Oh não, ocorreu um erro ): está carregando ? ( <> Carregando... ): dados ? ( <> {data.name}
{data.speed.walk}
): nulo}
);
}
Código de aplicativo completo acessível aqui: https://codesandbox.io/s/hardcore-dijkstra-8xgk7
Dados mutantes
Às vezes, você precisa criar ou atualizar seus dados. O RTK Query ajuda a fazer isso de uma maneira comum. O gancho useMutation fornecido retorna uma tupla contendo uma função de gatilho e um objeto contendo os resultados do gatilho. Em contraste com useQuery , a mutação só é realizada quando o gatilho é chamado.
Em uma configuração muito mais avançada, você pode ter um caso de uso em que precisa sincronizar seu cache local com o servidor depois de executar uma mutação-isso é chamado de revalidação. RTK Query fornece dois cenários para lidar com este caso de uso, e você pode decidir qual usar com base em suas necessidades:
- Invalidando tudo de um tipo
- Invalida seletivamente uma lista
Ao usar mutações RTK Query, você também terá todas as ferramentas de que precisa para implementar o comportamento de atualização otimista: você pode usar a fase onStart de uma mutação, onde define manualmente os dados em cache por meio de updateQueryResult . Caso ocorra um erro, você pode usar onError junto com patchQueryResult para voltar ao estado anterior.
Onde o cache entra em ação?
O armazenamento em cache é automático no RTK Query. Se seus dados mudarem (ou seja, forem invalidados), a nova busca ocorrerá automaticamente apenas para os elementos que mudaram. Isso é tratado por meio da poderosa queryCachedKey do RTK Query.
Depois que uma solicitação é feita, o RTK Query serializa os parâmetros para fornecer uma queryCachedKey exclusiva. Essa chave é então verificada em todas as solicitações futuras para evitar novas buscas desnecessárias. Se você precisar revisar esse comportamento, pode sempre chamar a função refetch fornecida pelo seu gancho.
O comportamento do cache é perfeitamente ilustrado nos documentos junto com um CodeSandbox exemplo. Isso mostra como os recursos de busca e armazenamento em cache automatizados ajudam a reduzir a quantidade de solicitações.
Status de consulta
Também é importante observar como o levantamento da dor, os estados retornados pela consulta, pode ser para o desenvolvedor. rtk-query expõe os estados das solicitações que podem ser usados diretamente em nosso aplicativo, conforme mostrado no exemplo acima
isUninitialized: false;//A consulta ainda não começou. isLoading: false;//A consulta está sendo carregada pela primeira vez. Sem dados ainda. isFetching: false;//A consulta está em busca, mas pode conter dados de uma solicitação anterior. isSuccess: false;//A consulta contém dados de um carregamento bem-sucedido. isError: false;//A consulta está atualmente em estado de"erro".
Busca condicional
Como mencionado acima, useQuery busca automaticamente seus dados e lida com o cache. O RTK Query fornece uma maneira de interromper a execução automática de uma consulta com um parâmetro booleano skip que pode ser ad dedicado ao gancho de consulta que ajudará a gerenciar esse comportamento. Definir skip como false afeta fortemente a forma como seus dados são buscados e armazenados em cache.
Tratamento de erros
Os erros são retornados por meio da propriedade error fornecida pelo gancho. O RTK Query espera que você retorne cargas úteis (erros ou sucessos) em um formato específico para ajudar na inferência de tipo.
retornar {erro: {status: 500, dados: {mensagem:'razões do erro'}};
Se precisar editar o formato de retorno atual, você pode usar uma baseQuery personalizada, que o ajudará a moldar os dados retornados.
Para ajudá-lo a lidar com seus erros com facilidade, o RTK Query expõe um tente novamente o utilitário com o qual você pode agrupar sua baseQuery para criar um backoff exponencial de um número especificado de tentativas ( maxRetries ).
Além disso, o RTK Query também permite que você gerencie seus erros em um nível macro , o que pode ajudá-lo a registrar erros de chamadas assíncronas não atendidas.
Sondagem
Você também pode ter a sensação de ter um servidor em tempo real usando o pollingInterval exposto em seus ganchos useQuery . Este parâmetro assume um número em milissegundos, que mais tarde será o intervalo no qual seus dados são atualizados. Além disso, você também pode atualizar manualmente seus dados.
Pré-busca
A pré-busca é simplesmente buscar dados antes que eles sejam realmente necessários-por exemplo, se você precisar da próxima página de dados paginados buscados antes de serem realmente solicitados.
O RTK Query lida com isso permitindo que você envie dois argumentos: isOlderThan e force . isOlderThan executará a consulta com base em um booleano ou um carimbo de data/hora, e force irá ignorar o argumento isOlderThan e executar a consulta mesmo se estiver presente no cache.
Gerador de código
Uma vez que é centralizado e o RTK Query funciona com seus ganchos, pode se tornar rapidamente complicado escrever endpoints de API completos em seu arquivo de serviço. Para lidar com isso, o RTK Query fornece um CodeGen que funciona com esquemas OpenAPI.
Personalização
É crucial que cada biblioteca cliente de API seja totalmente personalizável; um bom exemplo é Axios. Isso permite que os desenvolvedores tenham a capacidade de lidar com comportamentos padrão, interceptores e autenticação sem a necessidade de repetir o código.
createApi é o ponto principal onde o RTK Query será configurado. Ele expõe parâmetros como:
-
baseQuery, que pode ser personalizado para criar interceptores ou formatos de retorno de molde -
endpoints, que é o conjunto de operações que você executa em seus servidores -
setupListeners, que é um utilitário para ajudar a gerenciar a refetching de forma global ou granular - M uch mais para lidar com suas chamadas de API e loja Redux
Comparação com consulta de reação
O RTK Query assemelha-se à consulta reactiva na forma como utiliza ganchos. No entanto, as duas bibliotecas têm abordagens ligeiramente diferentes.
O RTK Query se concentra em aproveitar o poder do Redux para fornecer um método muito mais eficiente e declarativo para buscar dados. Ele também pretende ser agnóstico por natureza, com uma forte dependência do Redux Toolkit.
Suas estratégias de cache também são bastante diferentes: o RTK Query é declarativo na invalidação de dados e sua chave de cache é criada por meio de endpoints e argumentos, enquanto o react-query usa uma chave de cache manual para invalidação e caches por chaves de consulta definidas pelo usuário.
O RTK Query fornece uma comparação mais ampla aqui .
Conclusão
Quando chegar à produção, o RTK Query certamente será um ótimo complemento para as equipes que usam o Redux para o gerenciamento de estado. Os primeiros sinais mostram uma grande promessa-já oferece uma solução simples e eficiente.
A postagem Consulta RTK: O futuro da busca de dados e o cache para Redux apareceu primeiro no LogRocket Blog .
