Se você é um desenvolvedor, seja especializado em back-end ou front-end, é provável que já tenha sentido aquele "receio" ao mexer com o CSS. Afinal, quem nunca estilizou uma parte específica da aplicação e acabou vendo os estilos adicionados "vazarem" para outros elementos inesperadamente?

Esse problema é mais comum do que se imagina, mas a boa notícia é que há uma solução prática e eficiente para evitá-lo. A chave está na utilização das classnames em CSS. Elas são ferramentas poderosas que permitem separar a estilização de elementos, além de servirem como seletor para aplicar estilos específicos.

O grande desafio está em escolher nomes adequados e semânticos para essas classnames. Muitas vezes, ao criar nossas classes, não damos a devida atenção à semântica dos nomes utilizados. Como resultado, acabamos com conflitos e, consequentemente, esse "vazamento" indesejado de estilos ocorre.

Mas não se preocupe! Com algumas boas práticas e um pouco de cuidado ao nomear suas classes, é possível evitar esses problemas e tornar a estilização mais confiável.

Quando falamos sobre estilização e organização de código CSS, o modelo BEM (Block Element Modifier) se mostra uma ferramenta incrivelmente importante e útil. Ele nos permite separar pequenas partes da aplicação em componentes distintos, proporcionando uma abordagem mais estruturada e fácil de dar manutenção. Vamos entender melhor como esse modelo funciona na prática.

Ao pensarmos em componentes, visualizamos elementos que fazem parte de um contexto específico e que podem ser dinâmicos, ou seja, capazes de se adaptar e modificar seu estilo conforme necessário. O modelo BEM é especialmente eficiente para lidar com essa dinamicidade.

A sigla BEM é composta pelas iniciais de três conceitos fundamentais:

B - Block (Bloco): Representa o componente em si, uma parte maior e independente da aplicação que pode conter vários elementos internos.

E - Element (Elemento): São as partes menores e individuais que compõem o bloco. Eles estão sempre associados ao bloco ao qual pertencem e não têm significado ou funcionalidade quando usados isoladamente.

M - Modifier (Modificador): São as variações dos blocos ou elementos, responsáveis por alterar seu estilo ou comportamento. Eles nos permitem reutilizar estilos básicos em diferentes contextos.

A aplicação que será utilizada contém apenas um textfield para simplificar. As tecnologias utilizadas são: React, Typescript e node-sass. Temos um simples componente de TextField. Analisando este componente, podemos perceber que ele já é um bloco, ou seja, já contém alguns elementos internos (label e o input). Dessa forma, um possível nome de classe que represente esse bloco está no código abaixo.

Link da aplicação: https://codesandbox.io/s/name-conventions-class-css-0yc985

// src/components/TextField/index.tsx
import { InputHTMLAttributes } from "react";
import "./styles.scss";

interface InputProps extends InputHTMLAttributes<HTMLInputElement> {
  errorMessage?: string;
  label?: string;
}

export function TextField({ name, label, errorMessage, ...props }: InputProps) {
  return (
    <div className="textfield-container">
      ...
    </div>
  );
}


No código acima temos uma div com classeName textfield-container. Como podemos identificar o modelo BEM neste caso? O nosso bloco está identificado como textfield-container. Neste caso não foi necessário utilizar um elemento e nem modificador(Modifiers). Se você escreve muito código JavaScript ou Typescript, escrever variáveis em camelCase é uma prática comum. O problema é que essa forma de nomenclatura não é adequada para CSS. Uma forma adequada seria usar strings delimitadas por hífen. Esta é uma convenção de nomenclatura CSS bastante padrão. É sem dúvida mais legível. Além disso, é consistente com os nomes das propriedades CSS.

/* Adequado */
.textfield-container {}

/* Não adequado */
.textfieldContainer {}

/* src/components/TextField/styles.scss */
.textfield-container {
  display: flex;
  flex-direction: column;
}

.textfield-item__name {
  margin-top: 8px;
  padding: 5px 10px;
  border-radius: 8px;

  &.--error {
    border: 1px solid red;
  }
}

.textfield-message__error {
  color: red;
}

Observe que temos uma nova classename chamada textfield-item__name apresenta um bloco textfield-item e um elemento, que neste caso é o __name que se refere ao input para capturar o nome do usuário. Além disso, possuí também um modifier --error caso esse componente de TextInput tenha alguma mensagem de erro a ser mostrada.

import { InputHTMLAttributes } from "react";
import "./styles.scss";

interface InputProps extends InputHTMLAttributes<HTMLInputElement> {
  errorMessage?: string;
  label?: string;
}

export function TextField({ name, label, errorMessage, ...props }: InputProps) {
  return (
    <div className="textfield-container">
      {!!label && (
        <label className="textfield-label" htmlFor={name}>
          {label}
        </label>
      )}
      <input
        {...(label ? { id: name } : {})}
        className={`textfield-item__name ${errorMessage && "--error"}`}
        type="text"
        {...props}
      />
      {!!errorMessage && (
        <span className="textfield-message__error">{errorMessage}</span>
      )}
    </div>
  );
}


Perceba que os nomes escolhidos para as classnames estão de acordo com o contexto em que estão inseridas. Dessa forma, até certo ponto, conseguiremos evitar o vazamento de estilos para outras partes da aplicação. Além disso, conseguimos também tornar nosso componente mais dinâmico com os modifiers. Os modifiers contém um prefixo com dois hifens seguidos, por exemplo, --error. 

Temos algumas ferramentas que valem muito a pena serem utilizada desde o início do projeto. O styled-components é uma dessa ferramentas e também o css-modules que permitem um isolamento melhor de seletores com classenames.

Um detalhe muito importante é que a escolha de nomes para classenames vai de acordo com a sua equipe. Quando entramos em um projeto em andamento devemos seguir o padrão que já está sendo implementado.

Creio que todo desenvolvedor seja back-end ou front-end tem aquele "receio" de mexer com o CSS. Faz uma estilização em uma parte específica da aplicação e os estilos adicionados acabam "vazando" para outros elementos. As classes em CSS são altamente utilizadas para poder separar a estilização e também utilizada como seletor e muita das vezes não tomamos o cuidado necessário ao escolher nomes para nossas classes, que consequentemente podem ocorrer esse "vazamento" de estilos.

Boas práticas em classname no CSS

Durante meus estudos direcionado para questões de projeto e implementação de banco de dados, encontrei algo bastante interessante e que seria legal compartilhar. A SQL tem diversas regras e abordagem para lidar com valores NULL e que se dividem da seguinte forma:

Valor desconhecido (existe, mas não é conhecido);
A data de nascimento de uma pessoa não é conhecida, e por isso é representada por NULL no banco de dados.

Valor não disponível (existe, mas é propositalmente retido);
Uma pessoa tem um telefone residencial, mas não deseja que ele seja listado, por isso ele é retido e representado como NULL no banco de dados.

Valor não aplicável (o atributo é indefinido para essa tupla)
Um atributo Conjuge seria NULL para uma pessoa que não fosse casada, pois ele não se aplica a essa pessoa.

Em resumo, cada valor NULL na sua forma atômica é considerado diferente de qualquer outro valor NULL nos diversos registros do banco de dados. Ou seja, nos sistemas de gerenciamento de banco de dados (SGBD) baseados na SQL, o resultado do operação NULL = NULL não resulta em TRUE e nem e FALSE. Quando temos uma operação envolvendo valores nulos, a SQL vai retornar UNKNOWN ou TRUE ou FALSE. 

Como fazemos para comparar valores nulos na SQL?

Vamos começar analisando a seguinte tabela de usuario.

A SQL permite consultas que verificam se o valor de um atributo é NULL. Em vez de usar os operadores = ou <> para efetuar as comparações dos valores de atributos com NULL, a SQL tem seus operadores específicos para este propósito que são IS ou IS NOT. Agora, como podemos utilizar esses operadores? Veja no exemplo abaixo a execução do seguinte comando: selecione o nome das pessoas que a coluna "BIRTH_DATE" possui valores NULL.

De modo similar, podemos exemplificar como o operador IS NOT funciona.

Devemos usar os operadores IS e IS NOT para efetuar comparação de atributos com valores NULL, porque a SQL considera cada valor NULL sendo distinto de cada outro valor NULL, de modo que a comparação de igualdade não é apropriada. Portanto, é muito importante conhecer os fundamentos das tecnologias que estamos utilizando em nossos projetos, para poder ter um real controle do que elas estão fazendo.

Sistemas de banco de dados - Shamkant B. Navathe e Ramez Elmasri

Durante meus estudos direcionado para questões de projeto e implementação de banco de dados, encontrei algo bastante interessante e que seria legal compartilhar.

Como a SQL lida com valores NULL

O Next.js a partir da sua versão 10.2 será utilizado o webpack 5 trazendo mais benefícios para aplicação.

Não será mais necessário habilitar o webpack 5 no next.config.js. Isso será feito de forma automática pelo Next. Antes do lançamento desta versão, era necessário habilitar o webpack 5 dessa forma:

// next.config.js
module.exports = {
  future: {
    webpack5: true,
  },
} 

Inicialização
O tempo de inicialização utilizando next dev está aproximadamente 24% mais rápido.

Fast-Refresh
Seu tempo foi otimizado de 100ms a 200ms.

Mais flexibilidade no Redirects e Rewrites
Agora oferecem suporte a uma propriedade has para corresponder aos cookies de entrada, cabeçalhos e query strings.

Build mais rápido
Após o cache temos um build com aproximadamente 60% mais rápido. 

// Usando npm
npm i next@latest 

// Usando yarn
yarn add next@latest

O Next.js a partir da sua versão 10.2 terá o webpack 5 trazendo mais benefícios para aplicação.

Next.js 10.2 - Utilizando o webpack 5.

Neste post será abordado conceitos do atomic design aplicado ao desenvolvimento de design system com react. Vou mostrar um exemplo de aplicação e como podemos organizar as pastas separando cada componente.

O criador desta metodologia se chama Brad Frost. Atomic design é uma metodologia para construir design system que divide os elementos de uma página em:

Os Átomos são pequenas parte de uma página. Essa parte é fundamental para a construção de blocos de componentes maiores. Dentro desses elementos podemos incluir uma variedade de fontes, cores, e formas que possam se adequar nas partes do layout que serão inseridos. Na imagem abaixo podemos observar, dentro da nossa aplicação, o que seria considerado como um átomo.

Podemos perceber que cada item da sidebar pode ser considerado como a menor elemento desta página. Já que podemos tanto utilizar dentro do menu da sidebar como também como uma opção que o usuário pode fazer o logout da aplicação.

Nesta parte da metodologia é onde vamos poder combinar nossos átomos para poder formar elementos maiores do layout. Podemos observar na imagem abaixo.

Da mesma forma que podemos formar as moléculas combinando os átomos, podemos construir nossos organismos combinando as moléculas e os átomos. Observe na imagem abaixo.

Agora que já temos todos os componentes necessário para a construção dessa aplicação de exemplo, podemos montar nossos templates. O template como principal objetivo é fornecer aqueles componentes que são comum entre todas as páginas evitando códigos duplicados e facilitando a manuntenção. Na imagem abaixo, temos que a Sidebar será um componente comum entre as páginas.

Com o nosso template base pronto, já podemos contruir cada página. Na imagem abaixo temos a página "Message" contruída com elementos do template.

Podemos perceber que ao separar nossos componentes em partes menores, construímos outros elementos mais complexos e evitamos a duplicação de código e replicação de lógica dos componentes. Sendo assim, ao organizar nossos componentes com base na metodologia atomic design, nos permite desenvolver layouts cada vez mais robustos.

Segue o link da aplicação no codesandbox https://codesandbox.io/s/atomic-design-y1d1s

https://bradfrost.com/blog/post/atomic-web-design/

https://brasil.uxdesign.cc/atomic-design-redesenhando-os-entreg%C3%A1veis-de-designers-e-desenvolvedores-da8886c7258d

Construindo componentes reutilizáveis com conceitos do Atomic Design

A ideia principal deste conceito é a geração de páginas estáticas durante o tempo de build. Essas páginas podem ser enviadas para uma CDN e disponibilizadas globalmente em poucos segundos. Como nem tudo são flores, temos um probleminha. Vamos imaginar um e-commerce com 10000 produtos e para cada produtos temos que gerar uma página estática. Se essas páginas são geradas no build da aplicação, vamos ter um atraso considerável até que todas as páginas estejam prontas. Sendo assim, quanto mais páginas eu tenho que gerar de forma estática maior será o tempo de build.

O problema com a geração de sites estáticos: como o tempo de construção aumentam linearmente com o número de páginas, você pode ficar preso por horas até que seu site seja construído.

Mesmo que cada página fosse gerada estaticamente em torno de 1 ms, ainda levaria horas para reconstruir todo o site. Para grandes aplicações da web, escolher a geração completa de sites estáticos não é o primeiro passo. As equipes em grande escala precisam de uma solução híbrida mais flexível e personalizada. 

Atualmente, estamos encontrando cada vez mais o conteúdo do site separado do código. O uso de um CMS Headless permite que os criadores de conteúdo publiquem alterações sem envolver um desenvolvedor. No entanto, com sites estáticos tradicionais, esse processo pode ser lento. Vamos imaginar no seguinte exemplo, parecido com o primeiro. Considere e-commerce com 100.000 produtos. Os preços dos produtos mudam com frequência. Quando um criador de conteúdo alterar o preço de um determinado produto de R$ 100,00 para R$ 75,00 como parte de uma promoção, seu CMS usa um webhook para reconstruir todo o site. Não é viável esperar horas para que o novo preço seja refletido. Quando o tempo de build se torna longo podem ocorrer despesas adicionais. Idealmente, sua aplicação deve ser inteligente o suficiente para entender quais produtos foram alterados e atualizar essas páginas de forma incremental sem a necessidade de uma reconstrução completa. Aí que entra o Incremental Static Regeneration (ISR).

O Nextjs permite você criar ou atualizar as página estáticas após o build da aplicação. Incremental Static Regeneration permite que os desenvolvedores e criadores de conteúdo usem a geração estática por página, sem a necessidade de reconstruir todo o site. Com o ISR, você pode manter os benefícios do estático enquanto aumenta a escala para milhões de páginas. Podemos dizer que as novas páginas serão geradas de forma incremental pelo Nextjs.

Considerando o exemplo anterior com e-commerce de 100.000 produtos. Sem o ISR, o tempo de build poderia levar várias horas. Mas com o ISR podemos escolher entre:

Minimizar o tempo de build
Gerando os 1.000 produtos mais comprados no momento do build e as próximas páginas serão geradas sob demanda. Conforme o acesso do usuário.

Maior taxa de acerto de cache
Gerando 10.000 produtos no momento do build, garantindo que mais produtos sejam armazenados em cache antes da solicitação do usuário. O restante das páginas serão geradas sob demanda.

Para realizar essa geração de estáticos, o Next espera que seja exportado da página um função chamada getStaticProps.

// pages/products/[slug].js

export async function getStaticProps({ params }) {
  return {
    props: {
      product: await getProductFromDatabase(params.slug)
    },
    revalidate: 60
  }
}


Ao especificar revalidate: 60, informamos para o Next.js para usar ISR para está página. Sendo assim, a cade 60 segundos está página terá seu conteúdo atualizado e uma nova versão estática será gerada.

Com o Next.js podemos definir quais produtos serão gerados no momento do build e quais sob demanda.Vamos gerar apenas os 1.000 produtos mais comprados no momento do build, fornecendo ao getStaticPaths uma lista dos 1.000 principais IDs de produto. Precisamos configurar como Next.js fará um "fallback" ao solicitar qualquer um dos outros produtos após a construção inicial. Existem três opções para escolher: blocking, true e false.

fallback: "blocking" (Recomendado)
Quando uma solicitação é feita para uma página que não foi gerada, Next.js irá renderizar a página no servidor na primeira solicitação. As próximas solicitações para está página, a versão entregue será do cache. As páginas são entregues sob demanda.

fallback: "true"
Quando uma solicitação é feita para uma página que não foi gerada, Next.js irá servir imediatamente uma página estática com um estado de carregamento na primeira solicitação. Quando o carregamento dos dados for concluído, a página será renderizada novamente com os novos dados e armazenada em cache. Solicitações futuras servirão ao arquivo estático do cache.

fallback: "false"
Se nenhum ID foi passado no "paths", será retornado um 404. 

// pages/products/[slug].js

export async function getStaticPaths() {
  const products = await getTop1000Products()
  const paths = products.map((product) => ({
    params: { slug: product.id }
  }))

  return { paths, fallback: ‘blocking’ }

O Next.js se concentra em primeiro lugar no usuário final. A “melhor solução” é relativa e varia de acordo com a natureza da aplicação. Ao permitir que os desenvolvedores alternem entre as soluções sem sair dos limites da estrutura, o Next.js permite que você escolha a ferramenta certa para o projeto dando uma maior flexibilização no desenvolvimento.

A ideia principal deste conceito(Static-Site Generation) é a geração de páginas estáticas durante o tempo de build. Essas páginas podem ser enviadas para uma CDN e disponibilizadas globalmente em poucos segundos. Como nem tudo são flores, temos um probleminha. Vamos imaginar um e-commerce com 10000 produtos e para cada produtos temos que gerar uma página estática. Se essas páginas são geradas no build da aplicação, vamos ter um atraso considerável até que todas as páginas estejam prontas. Sendo assim, quantas mais páginas eu tenho que gerar de forma estática maior será o tempo de build.

Incremental Static Regeneration (ISR) com Nextjs

A API de armazenamento na web fornece recursos que permitem os navegadores armazenar dados através de chave/valor. Neste artigo será abordado em tópicos, as principais diferenças entre cada uma das formas de armazenamento na web que são: LocalStorage, sessionStorage e os cookies.

Os dados armazenados no localStorage e no sessionStorage estão disponíveis apenas no loado do cliente (Browser). Já os cookies, podemos ter acesso tanto no lado do servidor como também no cliente.

Todos os dados armazenados nos cookies e no localStorage estão disponíveis em qualquer parte da aplicação. Dizemos que os valores são globais. Já no sessionStorage, está disponíveis apenas na aba que aplicação foi iniciada.

Os cookies fornecem um armazenamento de 4KB enquanto que no localStorage e SessionStorage possuem capacidade de 5MB respectivamente.

LocalStorage
Os dados armazenados são mantidos até serem excluído explicitamente pela aplicação. Sendo assim, mesmo que janela/aba seja encerrada ou até mesmo depois de reiniciar o computador, os dados ainda estarão salvos.

SessionStorage
Os dados são mantidos somente enquanto a janela/aba está aberta. 

Cookies
Com está forma de armazenamento, podemos definir o tempo de expiração conforme a necessidade da aplicação.

Principais diferenças - LocalStorage x SessionStorage x Cookies.

Este pequeno tutorial tem por finalidade mostrar como podemos criar um simples hook para realizar chamadas a API. Durante o desenvolvimento de uma aplicação para estudo, identifiquei que poderia abstrair essa lógica de chamada a API além de adicionar um loading e realizar capturas de quaisquer erros que tenham ocorrido durante o envio da requisição. Será utilizada a API do github.

Como se trata de um pequeno tutorial, assumo que:

Tenha o axios instalado em sua aplicação. Se não estiver, pode instalar com o comando abaixo;

// src/hooks/useAxios.ts

import axios, { AxiosRequestConfig } from 'axios'
import { useEffect, useState } from "react";

type UseAxiosParams = {
  url: string
  // Podemos acrescentar mais métodos de acordo com a necessidade
  method: 'get' | 'post' | 'put' | 'delete'       
  config?: AxiosRequestConfig | undefined
  initialValue?: any
}

const http = axios.create({
  baseURL: 'https://api.github.com'
})

export function useAxios<T>({
  url,
  method,
  config = undefined,
  initialValue
}: UseAxiosParams) {
  const [data, setData] = useState<T>(initialValue)
  const [error, setError] = useState('')
  const [loading, setLoading] = useState(false)

  useEffect(() => {
    (async () => {
      try {
        switch (method) {
          case 'get':
            setLoading(true)
            const response = await http.get(url, config)
            if (response.status === 200) {
              setData(response.data)
            }
            break;

          // outros métodos
          default:
            break;
        }
      } catch (error) {
        setError(error.message)
      } finally {
        setLoading(false)
      }

    })()
  }, [url, method])

  return { data, loading, error }
}


Temos apenas um exemplo com o método get dentro do switch.

Este arquivo tem o intuito de mostrar como podemos utilizar o hook criado. Desconsidere as tags HTML utilizada no retorno da página Repository.

// src/pages/Repository/index.tsx

import { useAxios } from '../../hooks/useAxios';

interface Repository {
  full_name: string;
  description: string;
  stargazers_count: number;
  forks_count: number;
  open_issues_count: number;
  owner: {
    login: string;
    avatar_url: string;
  }
}

const Repository: React.FC = () => {
  const { data, loading } = useAxios<Repository>({
    url: `repos/facebook/react`,
    method: 'get'
  })

  return (
    <>
      {respositoryLoading && <h1>Carregando...</h1>}
      {repository && (
        <RepositoryInfo>
          <header>
            <img src={repository.owner.avatar_url} alt="git" />
            <div>
              <strong>{repository.full_name}</strong>
              <p>{repository.description}</p>
            </div>
          </header>
          <ul>
            <li>
              <strong>{repository.stargazers_count}</strong>
              <span>Stars</span>
            </li>
            <li>
              <strong>{repository.forks_count}</strong>
              <span>Forks</span>
            </li>
            <li>
              <strong>{repository.open_issues_count}</strong>
              <span>Issues abertas</span>
            </li>
          </ul>
        </RepositoryInfo>
      )}
    </>
  );
}

export default Repository;


Criando um simples hook de fetch com axios

A biblioteca TanStack Query é uma poderosa ferramenta para gerenciar o cache de consultas em aplicações React. Uma das características fundamentais dessa biblioteca são as "Query Keys", que são chaves usadas para identificar e gerenciar o cache das consultas de forma eficiente. Neste artigo, vamos explorar o uso adequado das Query Keys e como tirar o máximo proveito dessa funcionalidade.

Em essência, TanStack Query gerencia o cache de consultas com base em Query Keys. As Query Keys precisam ser um Array no nível superior e podem ser tão simples como um Array com uma única string ou tão complexas quanto um Array contendo várias strings e objetos aninhados. Enquanto a Query Key for serializável e única para os dados da consulta, ela pode ser utilizada.

A forma mais simples de uma chave é um Array com valores constantes. Esse formato é útil para recursos genéricos de lista/índice e recursos não hierárquicos. Imagine a seguinte situação: sua aplicação possui uma lista de usuários e você deseja criar um cache específico para essa lista. Com a TanStack Query e suas Query Keys, isso se torna uma tarefa simples e eficiente! Veja exemplo:

// Uma lista de usuários
useQuery({ queryKey: ['users'], ... })

Na imagem ilustrativa, podemos ver o cache sendo criado e identificado de forma clara.

A versatilidade das Query Keys não para por aí! Elas também permitem que você descreva consultas mais complexas, como recursos hierárquicos ou aninhados. Dessa forma, você pode passar informações adicionais para identificar de forma única os dados da sua consulta. Seja um ID, um índice ou até mesmo um objeto com parâmetros extras, as Query Keys têm a flexibilidade necessária para ajustar a consulta conforme suas necessidades. Veja exemplos:

// Uma usuário individual
useQuery({ queryKey: ['users', 1]})

// Paginação de uma listagem de usuários baseado em uma consulta
useQuery({ queryKey: ['users', page, query]})

E tem mais uma vantagem que merece destaque: as Query Keys são determinísticas! Isso significa que não importa a ordem das chaves nos objetos, o cache funcionará perfeitamente, garantindo eficiência e precisão nas consultas. As consultas a seguir são consideradas iguais:

useQuery({ queryKey: ['users', { status, page }], ... })
useQuery({ queryKey: ['users', { page, status }], ... })
useQuery({ queryKey: ['users', { page, status, other: undefined }], ... })

Entretanto, as seguintes Query Keys não são iguais. A ordem dos itens no Array importa!

useQuery({ queryKey: ['users', status, page], ... })
useQuery({ queryKey: ['users', page, status], ... })
useQuery({ queryKey: ['users', undefined, page, status], ... })

Inclua variáveis importantes nas Query Keys 

As Query Keys descrevem unicamente os dados que estão sendo buscados, portanto, devem incluir todas as variáveis utilizadas nas funções de consulta que podem ser alteradas. Por exemplo:

export function useUser(id: number) {
  return useQuery({
    queryKey: ['user', id],
    queryFn: () => getUser(id),
  })
}

A função useUser é uma forma de utilizar a biblioteca TanStack Query para obter informações de um usuário específico de forma eficiente, aproveitando o recurso de cache inteligente oferecido pela biblioteca. Sempre que a função useUser é chamada com um novo ID, a consulta é realizada e os resultados são armazenados em cache, proporcionando uma melhor experiência de uso para os usuários da aplicação.

É importante ressaltar que as Query Keys agem como dependências para suas funções de consulta. Incluir variáveis dependentes na Query Key garantirá que as consultas sejam armazenadas em cache independentemente, e sempre que uma variável mudar, as consultas serão refeitas automaticamente (dependendo das configurações de "staleTime"). 

https://tanstack.com/query/latest/docs/react/guides/query-keys

Último post

Utilize as Query Keys da biblioteca TanStack Query da forma correta