Só um comentário adicional caso alguém tenha ficado na dúvida... Ele não faz requisição pra atualizar a listagem toda, isso é via cache, mas é feita a requisição pra enviar o post do novo produto pra API
Opa Felipe, Então posso deixar a chamada na Api somente na primeira renderização do component e ir controlando as mutations por cache, que depois quando o component for renderizado novamente, a listagem estará corrigida com as seguintes mutations adicionadas pelo useMutation?
@@GhostDev7 sim, quando ele renderizar novamente, em um reload de página, por exemplo, o que foi enviado no post retornará também. Caso queira forçar a chamada, dê uma olhada em "invalidate query" do React Query.
Tava procurando conteúdo sobre isso e aparece isso no meu yt. Bom demais, mano. Vou começar a usar react-query nos meus projetos pra solidificar o conhecimento.
Muito interessante esse update do cache. Trabalhei numa fintech e usávamos React Query. No caso de uma mutation, eu fazia um invalidateQuery no cache key (que eram armazenadas num outro arquivo) e rolava um refetch, atualizando em todos os lugares que usavam essa cache key. Acho que por ser um app de investimentos, fazer um invalidate é mais interessante dado que outros usuários influenciam nos dados em tela React Query é incrível pois nos possibilitou abandonar de vez o Redux (pessimamente configurado) Parabéns Diego pelo ótimo conteúdo
Eu também não entendi bem o motivo dele ele não ter utilizado o invalidateQuery. Em outro vídeo eu vi ele fazendo a mesma coisa. Você acha que há alguma razão para utilizar a abordagem dele ao invés do invalidateQuery?
@@raphox a razão é que em alguns casos você não precisa fazer outra requisição http para manter o estado da sua aplicação atualizado, principalmente se for em um caso que apenas um usuário influencia nos dados da tela, como dito pelo joseph
Sim, perfeito, em alguns tipos de apps um invalidate é muito melhor que atualizar o cache, tipo um saque no banco, você quer que o saldo sempre seja o mais fiél possível, não faz sentido ficar controlando cache no front-end.
Boa! Trabalho num produto admin utilizado por 1,5k operadores diariamente. Ele tem diversas listagens de recursos de mais de 1,5M de clientes. Então estão sempre sofrendo mutações. Por conta desse cenário utilizamos o invalidate. Mas utilizamos o RTK Query. A feature de invalidação e refetch automático dele é muito mais fácil de gerenciar do que o do React Query. Mas ambas são excelentes soluções pra data fetching e caching!
Normalmente, quando eu ainda utilizava um state normal do React para lidar com requisições à API, normalmente também não fazia uma nova requisição GET para atualizar todos os dados. Se fosse um create, por exemplo, faria a requisição create e com o retorno desta sendo o novo dado criado, eu acrescentaria isso ao state, o que já seria refletido em tela, sem necessidade do refetch.
Exato, mas daí sem o React Query precisamos ficar passando funções de dentro de um componente para o outro ou criar um contexto para atualizar esses dados.
É útil em alguns casos, mas o problema que sempre tenho com essa abordagem, é no caso de a lista ser paginada, ordenada e filtrada, esse novo item incluso precisa ser paginado, ordenado e filtrado de acordo com os dados que estão no banco para mostrar (ou não) em tela. E ai eu sempre sou obrigado a retornar da API.
Era esse comentário que eu estava procurando. Vc acha q compensa fazer um app de dashboard igual esse q ele fez, direto no next por causa das server actions?
Sim, mas ainda é algo difícil de ter como "padrão" pra toda aplicação, ainda está muito embrionário e, dado experiências pessoais, com muitos bugzinhos misteriosos.
Beleza maneiro, mas se por acaso você vai editar esse item "novo", alterar o nome por exemplo do produto, quando for chamar o update, qual ID vai passar para o backend?
Muito bom, como vc faria em caso de listagem com paginação no servidor? Levando em conta que temos a quantidade total de registros la em baixo, a quantidade de itens em tela, ex:10, dessa forma se mutasse a lista acrescentando ficaria 11. Etc... melhor consultar a lista atualizada?
Mas digamos que mais de um usuário atualizou a lista. A lista iria ficar desatualizada justamente porque não foi feita a requisição. Sei que nesse caso iria abrir espaço para uma discussão de websocket e etc. Porém se a lista tiver muitas atualizações a conexão não for "socket" não vale a pena carregar de novo a lista, visto que os dados seriam mais confiáveis...meio q um trade-off
O Next.js com o app router trouxe essa funcionalidade com o uso de revalidate, server actions, server components e etc... mas eu pessoalmente prefiro muito mais essa solução utilizando o React Query no pages router. A sintaxe é infinitamente melhor, mais simples, intuitiva e ta bem mais estavel tambem. O site roda liso demais e sem sofrimento nenhum pra fazer.
Achei a lib legal e facil de usar mas pra mim isso parece um global state d qlqr forma. Assim como no redux vc tinha store.estado.propriedade vc agora tem um cache[key].propriedade; Essa funcao de mutation é a msm coisa q um dispatch de uma action do redux; e essa funçao setQueryData é o reducer q atualiza a store. Em outras palavras, pra mim essa lib é um redux 2.0 com uma sintaxe melhor q criar aquelas funcoes de mapDispatchToProps e mapDispatchToProps. Sobre "HTTP state" acho q é uma limitacao da funcionalidade q essa lib entrega pois podemos armazenar esses caches de qlqr operacao executada e nao apenas as operacoes oriundas de requisicoes HTTP. Ex.: poderiamos ter um cliente q se conecta a um websocket e a cada evento ouvido atualizamos o cache atraves de uma mutation.
Sim, Douglas, e até nos exemplos do RQ (reacr-query) ele trabalha com requisições que nem usa o http, justamente para os iniciantes não se limitarem apenas a isso. E com RQ podemos definir a validade do cache, o tempo que ele ainda é valido (mesmo que vencido) e o período que queremos para ele ser revalidado. Ele é muito útil para rodar a aplicação mesmo sem conexão com a internet. Também possui funcionalidades para ativar a revalidação quando o usuário volta a página e/ou quando o componente é renderizado/montado em tela
Isso é exatamente o que eu estou precisando fazer na minha aplicação, porém não estou usando tanstack. Como estou usando NextJS 14 com server components, meus componentes são assíncronos e eu faço a requisição com Axios. No caso de alterar em tempo real o meu componente de carrinho ao adicionar um item, a requisição é feita com sucesso, mas o novo item só era mostrado como adicionado ao carrinho ao recarregar a página. Pra solucionar isso, somente no meu componente de carrinho não estou usando o Axios, estou usando o fetch nativo com um objeto de configuração { next: { tags: ['...'] } } pra fazer o revalidateTag('...'). Problema é que em produção minha aplicação quebra sempre ao abrir o carrinho (mesmo sem adicionar nenhum item), sendo que em development funciona perfeitamente. O que pode ser, alguém pra me ajudar?
Maneiro ! Optimistic Updates, certo ? Mas após adicionar utilizando o "variables"e preenchendo com dados "temporários" em que momento eu posso atualizar esses dados para os dados reais da api ?
isLoading é o resultado da junção da informação de que não há informação no cache ainda (isPending) + a informação de que a queryFunction foi chamada, ou seja, isLoading = isPending && isFetching Essa diferença existe porque há a possibilidade de instanciar uma query sem invocar a queryFunction ao mesmo tempo, controlando, portanto, o tempo que ela fica pendente até ter seu carregamento iniciado. E o isLoading indicará assim o primeiro carregamento desse dado (sem cache + execução da função)
O useMutation já tem acesso aos dados do item incrementado através do primeiro parâmetro do método "onSuccess" então não precisa fazer uma nova chamada.
@@dieegosf digo, para caso precise buscar dados gerados pelo servidor. como o id. sem ele muitos processos de associação não funcionaria. por isso comentei, que podemos ao invés de buscar a lista toda, usar o retorno da api que geralmente devolve o item adicionado. pois no exemplo usou os dados do usuário.
Eu percebi que quando você deu F5, o produto que você inseriu, não se manteve no cache do React Query. Foi por você estar em desenvolvimento e ter atualizando o código pra adicionar um id? 12:42
O cache não é persistente entre as atualizações de página e, como eu não estava realmente salvando o produto em um banco de dados ou algo do tipo, ele vai se perder da listagem mesmo.
@@euyokan Quando você dá F5 na verdade tudo vai dar refetch, isso é padrão do browser. Até existem estratégias pra fazer storage do cache, mas não sei até que ponto vale a pena (tanstack.com/query/v4/docs/react/plugins/persistQueryClient).
Fala Diego blz? Pode explicar a fundo por que você nomeeia de HTTP state, esta biblioteca me parece seguir a arquitetura FLUX adicionando um JS global state e manipulando isto a cada requisição.
Eu achei essa abordagem meio esquisita. Supomos que dê algum problema no servidor ao criar o dado. Se não for bem tratado no lado do cliente, ele pode mostrar o dado como inserido para o usuário quando de fato não foi inserido, saca? Acho que oque seria melhor é realmente realizar uma nova requisição para carregar os dados atualizados do servidor.
Este metodo com filtros implementados nao funciona bem, se tiver usando por algum acaso um searchParams, e o query estive por volta de duas paginas que tem filtros utilizando o searchParams, os dados de ambas irao ser atualizados o que pode causar em algum momento um problema se estiver usando os dados para algo, como me ocorreu essa semana
Na verdade funciona, a questão é que o queryKey usado na query e mutation precisa também conter esses parâmetros, assim os updates também só vão atualizar as queries que tiverem esses parâmetros
nao falei sobre isso, se voce tiver na pagina X e fizer a listagem e nessa pagina tem ?search=maria, e voce mudar para pagina y e tiver search=jose ambos vamo mudar, no meu caso eu precisava da lista de maria na pagina jose, ela tambem ira mudar obviamente se estiver por volta das duas paginas, nao falei de mutation em momento nenhum, estou falando de persistencia@@gurmiguel
Interessante... mas existe um motivo de enviar essa info pro back, ele é quem vai validar e criar a entrada (por isso não tem id)... se minha aplicação compartilha a api com outras eu posso até criar problemas de dados seguindo esse padrão... Eu sinceramente não vejo como colocar isso pra rodar a não ser que eu não precise de back, ou que ele só sirva pra se comunicar com o Banco...
esse caso que ele mostrou ele usou dados de exemplo e chamadas dummy, no mundo real obviamente a requisição do servidor irá retornar o estado atual da entidade e você poderá salvar na lista, isso é um pattern basicão que só ficou "complicado" pelo uso de biblioteca externa pelo react ser uma bosta.
O problema do http state nao seria outras pessoas usando a mesma tabela ou a mesma tela no mesmo tempo? e com isso a gente acaba impedindo de ter os dados 100% atualizados?
acho que se vc invalidar a query depois de adicionar fazendo com que o sistema faça uma nova requisição e renderize os dados atualizados nao da esse problema
Opa Marcus, beleza? Na verdade, me corrija se eu estiver errado, Optimistic UI é quando mostramos o valor "atualizado" mesmo antes da requisição para o back-end ter sucesso e, caso tenha erro no futuro, a gente volta o valor original. A atualização de cache em si pode ser usada para interface otimista mas não necessariamente configura o uso da prática. Mas nesse projeto usamos interface otimista na atualização do perfil: github.com/rocketseat-education/pizzashop-web/blob/main/src/components/store-profile.tsx#L75
você tá usando a lib de table do @tanstack também? eles aparentemente tão construindo lib para tudo: table, form, router, etc. Só utilizei o react-query até agora, mas parece interessante o projeto deles
Ultimamente tenho usado o Jotai, para criar átomos globais, consigo usar ambos juntos? Ou nesse caso o React-query viria para substituir essa funcionalidade??
Claro! Não é porque temos a HABILIDADE de usar Server Components que devamos deixar de lado toda reatividade do React e nunca mais usar código client-side...
@@dieegosf pensando em um uso pra fetchs em server components e cache dos dados, o react query tem alguma vantagem em cima das actions nativas do nextjs? to analisando se devo utilizar uma lib pra isso ou se fico com as soluções nativas do framework
@@TutoDS2014 hmm. então cê usa o setQueryData, mas na hora de passar a queryKey, cê teria que alterar pra última página. normalmente em requests paginadas você tem a quantidade total de páginas, então da pra botar o ID da última query lá, acredito eu
Quando vc tem muitas telas e precisa de reatividade global para atualizar muitos componentes de uma só vez, como um aplicativo bancário por exemplo, onde um usuário faz uma transação bancária e esse saldo precisa ser atualizado em muitos lugares instantaneamente. nesse caso seria ideal usar um estado global, pois mantem uma instância única do estado e só consultá-lo em qualquer parte do sistema. além de ser mais seguro
Uma dúvida, se eu tenho um sistema que atualiza uma lista de produtos e uma outra que lista esses produtos tipo em um select, quando eu atualizo pelo cache, essa atualização pode ser vista na outra tela que tem o componente de produto?
São aplicações diferentes? Se sim, então você não conseguirá ver isso refletindo não. Só funciona se for a mesma aplicação com duas páginas diferentes, daí sim.
pensando que a api que vc ultilizou para criar a nova entrada retornar o id, você consegue pegar pra atualizar o cache, sem a necessidade de chamar o get novamente
Geralmente o back-end devolve isso na resposta da requisição, essa resposta vem no primeiro parâmetro do "onSuccess" que renomeamos ali no vídeo para "_" então basta usar essa resposta e você terá o ID e os demais dados provindos do back-end.
Geralmente o back-end devolve isso na resposta da requisição, essa resposta vem no primeiro parâmetro do "onSuccess" que renomeamos ali no vídeo para "_" então basta usar essa resposta e você terá o ID e os demais dados provindos do back-end.
Tenho muito problema com isso, de atualizar um dado e precisar de um refresh na página. Uso o redux para gerenciar minhas requisições. Como consigo fazer isso, ou algo proximo, sem o uso do react-query?
@@EsdrasCastroFerreira Essa sua resposta só mostra que você não tem o curso pago da Rocket, pois eles tem curso de Python, Java, arquitetura e várias outras tecnologia incluindo Flutter como cursos livre, então se eles adicionarem uma trilha só de Flutter no ignite que diferença faria no que eles já são hoje "UMA ESCOLA DE PROGRAMAÇÃO". Aí pessoas como você que só assiste eles aqui no TH-cam fica aí dando opinião nada a ver, aí faz o seguinte, quando você trabalhar lá na Rocket, responde minha pergunta aqui novamente, pois minha pergunta foi direcionada para eles blz 👍
Só um comentário adicional caso alguém tenha ficado na dúvida... Ele não faz requisição pra atualizar a listagem toda, isso é via cache, mas é feita a requisição pra enviar o post do novo produto pra API
Exato, obrigado Felipe!
Opa Felipe, Então posso deixar a chamada na Api somente na primeira renderização do component e ir controlando as mutations por cache, que depois quando o component for renderizado novamente, a listagem estará corrigida com as seguintes mutations adicionadas pelo useMutation?
@@GhostDev7 sim, quando ele renderizar novamente, em um reload de página, por exemplo, o que foi enviado no post retornará também. Caso queira forçar a chamada, dê uma olhada em "invalidate query" do React Query.
@@felipecouto9044 tmj, gratidão!
Bacana, eu geralmente usava a função refetch que vem de dentro do useQuery, e então refazia a requisição. Vou começar tentar essa nova abordagem
Conteúdo incrível !! 💜 Parabéns Diego, tava procurando sobre o assunto e esse video foi bem didático
Tava procurando conteúdo sobre isso e aparece isso no meu yt. Bom demais, mano. Vou começar a usar react-query nos meus projetos pra solidificar o conhecimento.
Muito interessante esse update do cache. Trabalhei numa fintech e usávamos React Query.
No caso de uma mutation, eu fazia um invalidateQuery no cache key (que eram armazenadas num outro arquivo) e rolava um refetch, atualizando em todos os lugares que usavam essa cache key.
Acho que por ser um app de investimentos, fazer um invalidate é mais interessante dado que outros usuários influenciam nos dados em tela
React Query é incrível pois nos possibilitou abandonar de vez o Redux (pessimamente configurado)
Parabéns Diego pelo ótimo conteúdo
Eu também não entendi bem o motivo dele ele não ter utilizado o invalidateQuery. Em outro vídeo eu vi ele fazendo a mesma coisa. Você acha que há alguma razão para utilizar a abordagem dele ao invés do invalidateQuery?
@@raphox a razão é que em alguns casos você não precisa fazer outra requisição http para manter o estado da sua aplicação atualizado, principalmente se for em um caso que apenas um usuário influencia nos dados da tela, como dito pelo joseph
Na documentação (na parte de 'Persist mutations') ele utiliza o resultado da request da mutation para definir os dados do novo elemento.
Sim, perfeito, em alguns tipos de apps um invalidate é muito melhor que atualizar o cache, tipo um saque no banco, você quer que o saldo sempre seja o mais fiél possível, não faz sentido ficar controlando cache no front-end.
Boa! Trabalho num produto admin utilizado por 1,5k operadores diariamente. Ele tem diversas listagens de recursos de mais de 1,5M de clientes. Então estão sempre sofrendo mutações. Por conta desse cenário utilizamos o invalidate. Mas utilizamos o RTK Query. A feature de invalidação e refetch automático dele é muito mais fácil de gerenciar do que o do React Query. Mas ambas são excelentes soluções pra data fetching e caching!
esse vídeo me convenceu a começar a usar react query pra todos os meus apps.
melhor. decisão. da minha vida.
Diego, tu é muuuito bom cara.
voce é insano!
Excelente conteudo!!
Normalmente, quando eu ainda utilizava um state normal do React para lidar com requisições à API, normalmente também não fazia uma nova requisição GET para atualizar todos os dados. Se fosse um create, por exemplo, faria a requisição create e com o retorno desta sendo o novo dado criado, eu acrescentaria isso ao state, o que já seria refletido em tela, sem necessidade do refetch.
Exato, mas daí sem o React Query precisamos ficar passando funções de dentro de um componente para o outro ou criar um contexto para atualizar esses dados.
É útil em alguns casos, mas o problema que sempre tenho com essa abordagem, é no caso de a lista ser paginada, ordenada e filtrada, esse novo item incluso precisa ser paginado, ordenado e filtrado de acordo com os dados que estão no banco para mostrar (ou não) em tela. E ai eu sempre sou obrigado a retornar da API.
Agora com revalidate do nextjs, nem precisa mais pois uma round trip já atualiza o componente atrás do modal, usando as server actions
Era esse comentário que eu estava procurando.
Vc acha q compensa fazer um app de dashboard igual esse q ele fez, direto no next por causa das server actions?
Sim, mas ainda é algo difícil de ter como "padrão" pra toda aplicação, ainda está muito embrionário e, dado experiências pessoais, com muitos bugzinhos misteriosos.
Beleza maneiro, mas se por acaso você vai editar esse item "novo", alterar o nome por exemplo do produto, quando for chamar o update, qual ID vai passar para o backend?
Muito bom, como vc faria em caso de listagem com paginação no servidor? Levando em conta que temos a quantidade total de registros la em baixo, a quantidade de itens em tela, ex:10, dessa forma se mutasse a lista acrescentando ficaria 11. Etc... melhor consultar a lista atualizada?
Mas digamos que mais de um usuário atualizou a lista. A lista iria ficar desatualizada justamente porque não foi feita a requisição. Sei que nesse caso iria abrir espaço para uma discussão de websocket e etc. Porém se a lista tiver muitas atualizações a conexão não for "socket" não vale a pena carregar de novo a lista, visto que os dados seriam mais confiáveis...meio q um trade-off
O Next.js com o app router trouxe essa funcionalidade com o uso de revalidate, server actions, server components e etc... mas eu pessoalmente prefiro muito mais essa solução utilizando o React Query no pages router. A sintaxe é infinitamente melhor, mais simples, intuitiva e ta bem mais estavel tambem. O site roda liso demais e sem sofrimento nenhum pra fazer.
Lembra muito tRPC
Achei a lib legal e facil de usar mas pra mim isso parece um global state d qlqr forma. Assim como no redux vc tinha store.estado.propriedade vc agora tem um cache[key].propriedade; Essa funcao de mutation é a msm coisa q um dispatch de uma action do redux; e essa funçao setQueryData é o reducer q atualiza a store. Em outras palavras, pra mim essa lib é um redux 2.0 com uma sintaxe melhor q criar aquelas funcoes de mapDispatchToProps e mapDispatchToProps. Sobre "HTTP state" acho q é uma limitacao da funcionalidade q essa lib entrega pois podemos armazenar esses caches de qlqr operacao executada e nao apenas as operacoes oriundas de requisicoes HTTP. Ex.: poderiamos ter um cliente q se conecta a um websocket e a cada evento ouvido atualizamos o cache atraves de uma mutation.
Sim, Douglas, e até nos exemplos do RQ (reacr-query) ele trabalha com requisições que nem usa o http, justamente para os iniciantes não se limitarem apenas a isso. E com RQ podemos definir a validade do cache, o tempo que ele ainda é valido (mesmo que vencido) e o período que queremos para ele ser revalidado. Ele é muito útil para rodar a aplicação mesmo sem conexão com a internet. Também possui funcionalidades para ativar a revalidação quando o usuário volta a página e/ou quando o componente é renderizado/montado em tela
Isso é exatamente o que eu estou precisando fazer na minha aplicação, porém não estou usando tanstack. Como estou usando NextJS 14 com server components, meus componentes são assíncronos e eu faço a requisição com Axios. No caso de alterar em tempo real o meu componente de carrinho ao adicionar um item, a requisição é feita com sucesso, mas o novo item só era mostrado como adicionado ao carrinho ao recarregar a página. Pra solucionar isso, somente no meu componente de carrinho não estou usando o Axios, estou usando o fetch nativo com um objeto de configuração { next: { tags: ['...'] } } pra fazer o revalidateTag('...'). Problema é que em produção minha aplicação quebra sempre ao abrir o carrinho (mesmo sem adicionar nenhum item), sendo que em development funciona perfeitamente. O que pode ser, alguém pra me ajudar?
Os vídeos certos nas horas certas
Lib show! So cuidar pra nao arrebentar com a memoria do client
Maneiro ! Optimistic Updates, certo ? Mas após adicionar utilizando o "variables"e preenchendo com dados "temporários" em que momento eu posso atualizar esses dados para os dados reais da api ?
Eu só fiquei confuso em relação as variáveis (isPending, isFetching, isLoading) qual a diferença entre elas? É uma diferença notória ou não?
isLoading é o resultado da junção da informação de que não há informação no cache ainda (isPending) + a informação de que a queryFunction foi chamada, ou seja, isLoading = isPending && isFetching
Essa diferença existe porque há a possibilidade de instanciar uma query sem invocar a queryFunction ao mesmo tempo, controlando, portanto, o tempo que ela fica pendente até ter seu carregamento iniciado.
E o isLoading indicará assim o primeiro carregamento desse dado (sem cache + execução da função)
E na documentação têm tudo bem explicado tbm
Diegão, num cenário Next, utilizar o SWR em vez do React Query seria uma alternativa "melhor"? Pois é desenvolvido pela própria Vercel...
Não
pode ser feita uma chamada para buscar somente o item incrementado e atualizar o estado com ele.
O useMutation já tem acesso aos dados do item incrementado através do primeiro parâmetro do método "onSuccess" então não precisa fazer uma nova chamada.
@@dieegosf digo, para caso precise buscar dados gerados pelo servidor. como o id. sem ele muitos processos de associação não funcionaria.
por isso comentei, que podemos ao invés de buscar a lista toda, usar o retorno da api que geralmente devolve o item adicionado.
pois no exemplo usou os dados do usuário.
tem como usar server actions no mutationFn?
Eu percebi que quando você deu F5, o produto que você inseriu, não se manteve no cache do React Query. Foi por você estar em desenvolvimento e ter atualizando o código pra adicionar um id? 12:42
O cache não é persistente entre as atualizações de página e, como eu não estava realmente salvando o produto em um banco de dados ou algo do tipo, ele vai se perder da listagem mesmo.
@@dieegosf Então no caso se eu quiser a lista atualizada mesmo dando F5 após inserir, eu precisaria fazer refetch?
@@euyokan Quando você dá F5 na verdade tudo vai dar refetch, isso é padrão do browser. Até existem estratégias pra fazer storage do cache, mas não sei até que ponto vale a pena (tanstack.com/query/v4/docs/react/plugins/persistQueryClient).
Fala Diego blz? Pode explicar a fundo por que você nomeeia de HTTP state, esta biblioteca me parece seguir a arquitetura FLUX adicionando um JS global state e manipulando isto a cada requisição.
Provavelmente por que deve estar usando e manipoulando Cache do Browser
Eu achei essa abordagem meio esquisita.
Supomos que dê algum problema no servidor ao criar o dado. Se não for bem tratado no lado do cliente, ele pode mostrar o dado como inserido para o usuário quando de fato não foi inserido, saca?
Acho que oque seria melhor é realmente realizar uma nova requisição para carregar os dados atualizados do servidor.
Este metodo com filtros implementados nao funciona bem, se tiver usando por algum acaso um searchParams, e o query estive por volta de duas paginas que tem filtros utilizando o searchParams, os dados de ambas irao ser atualizados o que pode causar em algum momento um problema se estiver usando os dados para algo, como me ocorreu essa semana
Na verdade funciona, a questão é que o queryKey usado na query e mutation precisa também conter esses parâmetros, assim os updates também só vão atualizar as queries que tiverem esses parâmetros
nao falei sobre isso, se voce tiver na pagina X e fizer a listagem e nessa pagina tem ?search=maria, e voce mudar para pagina y e tiver search=jose ambos vamo mudar, no meu caso eu precisava da lista de maria na pagina jose, ela tambem ira mudar obviamente se estiver por volta das duas paginas, nao falei de mutation em momento nenhum, estou falando de persistencia@@gurmiguel
Qual extensão é essa, que mostra o console-log ?
começando a estudar react me indicaram CRA, mas qual framework recomenda?
Interessante... mas existe um motivo de enviar essa info pro back, ele é quem vai validar e criar a entrada (por isso não tem id)... se minha aplicação compartilha a api com outras eu posso até criar problemas de dados seguindo esse padrão... Eu sinceramente não vejo como colocar isso pra rodar a não ser que eu não precise de back, ou que ele só sirva pra se comunicar com o Banco...
esse caso que ele mostrou ele usou dados de exemplo e chamadas dummy, no mundo real obviamente a requisição do servidor irá retornar o estado atual da entidade e você poderá salvar na lista, isso é um pattern basicão que só ficou "complicado" pelo uso de biblioteca externa pelo react ser uma bosta.
O problema do http state nao seria outras pessoas usando a mesma tabela ou a mesma tela no mesmo tempo? e com isso a gente acaba impedindo de ter os dados 100% atualizados?
acho que se vc invalidar a query depois de adicionar fazendo com que o sistema faça uma nova requisição e renderize os dados atualizados nao da esse problema
No remix isso e feito automático, isso se chama Optmistic Ui
Opa Marcus, beleza? Na verdade, me corrija se eu estiver errado, Optimistic UI é quando mostramos o valor "atualizado" mesmo antes da requisição para o back-end ter sucesso e, caso tenha erro no futuro, a gente volta o valor original. A atualização de cache em si pode ser usada para interface otimista mas não necessariamente configura o uso da prática. Mas nesse projeto usamos interface otimista na atualização do perfil: github.com/rocketseat-education/pizzashop-web/blob/main/src/components/store-profile.tsx#L75
podia explicar utilizando uma api real
Bastante interessante 😇
você tá usando a lib de table do @tanstack também?
eles aparentemente tão construindo lib para tudo: table, form, router, etc. Só utilizei o react-query até agora, mas parece interessante o projeto deles
ele usou o shadcn/ui pra faz a table e modal
@@mrerre2236 valeu pela info, amg. nunca dei uma olhada nessa lib ainda, mas parece legal
Qual é essa extensão que chama o gpt?
Diego, pretendes ainda fazer mais video ensinando o react com o projeto de upload com tauri?
Simmm, vou continuar.
Eu posso substituir o reducer por um http state ou o resultado ficaria o mesmo?
Ultimamente tenho usado o Jotai, para criar átomos globais, consigo usar ambos juntos? Ou nesse caso o React-query viria para substituir essa funcionalidade??
essa live tem completa ?
No caso do Next.js com as server-actions é viável ainda o uso do react-query?
Claro! Não é porque temos a HABILIDADE de usar Server Components que devamos deixar de lado toda reatividade do React e nunca mais usar código client-side...
@@dieegosf pensando em um uso pra fetchs em server components e cache dos dados, o react query tem alguma vantagem em cima das actions nativas do nextjs? to analisando se devo utilizar uma lib pra isso ou se fico com as soluções nativas do framework
@dieegosf acho que a pergunta dele deve ter sido pertinente em relação ao revalidatePath() , acha válido usar? Mesmo tendo o revalidatePath?
de qual video eh este corte?
Mas não era só fazer um push no array com o novo produto?
Não, o React não vai monitorar uma nova informação surgindo no array de forma automatizada.
Subatituiria o zustand também? Como seria para outros componentes que nao usaria necessariamente requisição, mas alteração de layout?
Depende com qual propósito, se você usa Zustand pra salvar os dados provindos de requisições HTTP então sim.
Como fazer no caso de resultados paginados? Remove um e adiciona o novo?
E como voce lidaria com acções tipo update se ainda não tem o `id` desse item?
em casos paginados, normalmente cê passa o ID pra queryKey. dessa forma a query afetada vai ser a query daquela página em específico
@@m4c1el ok, mas ainda assim se a paginação é de 50 resultados ao adicionar um novo irão ficar 51 resultados
@@TutoDS2014 hmm. então cê usa o setQueryData, mas na hora de passar a queryKey, cê teria que alterar pra última página. normalmente em requests paginadas você tem a quantidade total de páginas, então da pra botar o ID da última query lá, acredito eu
Agora fique com uma dúvida. Já que é muito mais performático utilizar HTTP State, quando utilizar outras abordagens como estados globais?
Quando vc tem muitas telas e precisa de reatividade global para atualizar muitos componentes de uma só vez, como um aplicativo bancário por exemplo, onde um usuário faz uma transação bancária e esse saldo precisa ser atualizado em muitos lugares instantaneamente. nesse caso seria ideal usar um estado global, pois mantem uma instância única do estado e só consultá-lo em qualquer parte do sistema. além de ser mais seguro
O que ele está usando no começo do vídeo para conseguir fazer pesquisa no gpt com search bar avulsa?
é o raycast, é um app pra macos!
@@lucas.fellipe.cvlww
Daora demais. Podemos dizer adeus ao Redux? Eu ouvi um amém, meus irmãos???
Hahaha, não necessariamente, só não precisamos mais usar o Redux pra guardar dados provindos das requests HTTP
Uma dúvida, se eu tenho um sistema que atualiza uma lista de produtos e uma outra que lista esses produtos tipo em um select, quando eu atualizo pelo cache, essa atualização pode ser vista na outra tela que tem o componente de produto?
São aplicações diferentes? Se sim, então você não conseguirá ver isso refletindo não. Só funciona se for a mesma aplicação com duas páginas diferentes, daí sim.
Isso não causaria uma inconsistência no id? Se fosse necessário deletar, o id informado estaria errado 🤔🤔
pensando que a api que vc ultilizou para criar a nova entrada retornar o id, você consegue pegar pra atualizar o cache, sem a necessidade de chamar o get novamente
Geralmente o back-end devolve isso na resposta da requisição, essa resposta vem no primeiro parâmetro do "onSuccess" que renomeamos ali no vídeo para "_" então basta usar essa resposta e você terá o ID e os demais dados provindos do back-end.
@@dieegosf entendii. Vlw diego 🙏🏼
Fica a dúvida agora de como resolver o ID, eu gero ele no front ou mando pro back e ele resolve?
Geralmente o back-end devolve isso na resposta da requisição, essa resposta vem no primeiro parâmetro do "onSuccess" que renomeamos ali no vídeo para "_" então basta usar essa resposta e você terá o ID e os demais dados provindos do back-end.
@@dieegosf então é simples, eu achei que era algo pra eliminar a requisição momentânea
Tenho muito problema com isso, de atualizar um dado e precisar de um refresh na página. Uso o redux para gerenciar minhas requisições. Como consigo fazer isso, ou algo proximo, sem o uso do react-query?
Se você usa Redux, o melhor é o RTK Query que tem o mesmo propósito mas com integração para Redux
Onde sao feiras essas lives?
Twitch (usuário dieegosf)
Como faz pra abrir essa AI Assist no mac? Alguma extensão?
Raycast, mas a parte de AI é paga
Quando a Rocket vai lançar a formação em Flutter?
Deixa de ser uma escola de programação, amigo! 😅
@@EsdrasCastroFerreira Essa sua resposta só mostra que você não tem o curso pago da Rocket, pois eles tem curso de Python, Java, arquitetura e várias outras tecnologia incluindo Flutter como cursos livre, então se eles adicionarem uma trilha só de Flutter no ignite que diferença faria no que eles já são hoje "UMA ESCOLA DE PROGRAMAÇÃO". Aí pessoas como você que só assiste eles aqui no TH-cam fica aí dando opinião nada a ver, aí faz o seguinte, quando você trabalhar lá na Rocket, responde minha pergunta aqui novamente, pois minha pergunta foi direcionada para eles blz 👍
Cara qual teclado o diego usa ?? queria saber muito pq faz um barulhasso kkkk
Keychron K2
Olá Diego, pararam de utilizar o chakra-ui?
Então, depois que o Chakra anuncionou a versão 2.0 com a quebra da lib em 4 projetos eu acabei dando um pause com ela sim.
hoje uso muito o Material UI, verifica se ele é útil para teus projetos
Para usar com next seria a meama estratégia?
Sim, exatamente. Se estiver usando o App Router (Next 13+) precisa dai só sinalizar que é um client component com "use client".
Obrigado!!
Aproveitando outra dúvida, com o next o SWR seria melhor compatibilidade ? Devi ser desenvolvido pela vercel também?
eu só queria saber a config do macbook dele
M1 Max 64gb
Qual é esse projeto?
Módulo 04 da formação React
da dor nos rins de ver esse cara codar, na moral
Nao tem nada de conteudo python e os cara na live tavam querendo enfiar curso guela abaixo.
Sempre inventando moda pra vender curso em piá 😂