Is it normal for RTK-Query to have this cycle?

[fera765]

I am testing the library on my API, and I would like to know if it is normal for the library to have this cycle within a registry update, below I leave the order in order...

1: GET: http://localhost:3030/post/view/29288383 GET ONE POST 2: PATCH: http://localhost:3030/post/29288383 UPDATE ONE POST 3: GET: http://localhost:3030/posts GET ALL POSTS 4: GET: http://localhost:3030/post/view/29288383 GET ONE POST

Isn't it bad for updating 1 record to have 4 requests? Mainly for the consumption of the API inside the server ...

[fera765]

If this is the behavior of the library, in an application where it would have 1 million users, and if all users made an operation at the same time to update the registration, this would transform into 4 million requests per second. is a huge expense within the backend

[markerikson]

Can you provide a CodeSandbox that reproduces the issue?

[fera765]

Can you provide a CodeSandbox that reproduces the issue?

https://codesandbox.io/s/muddy-sound-knstl

Within the application log you will notice 3 log PUT, GET, GET ..

in the interval of 1 to 2 seconds, we had 3 requests to make 1 update of data, imagine if there were 1 million users, and each user will do 1 update of registration, in the interval of 1 to 2 seconds we would have more than 3 million requests for a registry update.

The basis of this project was taken from within this repository.

Now if this is the behavior of the library, and when using it in a very large project, where there will be several requests per second, it would be very bad for the system ...

Instead of the 2 GET calls after the PUT, it could update the data from within the state, in case the PUT of any problem, then it would revert data.

[msutkowski]

@fera765 This is specifically described in the documentation: https://rtk-query-docs.netlify.app/concepts/mutations#scenarios-and-behaviors. I'd really recommend reading that page, as well as about Optimistic Updates.

What to expect

When addPost is triggered, it would cause each PostDetail component to go back into a isFetching state because addPost invalidates the root entity, which causes every query that provides 'Posts' to be re-run. In most cases, this may not be what you want to do. Imagine if you had 100 posts on the screen that all subscribed to a getPost query – in this case, you'd create 100 requests and send a ton of unnecessary traffic to your server, which we're trying to avoid in the first place! Even though the user would still see the last good cached result and potentially not notice anything other than their browser hiccuping, you still want to avoid this.

[fera765]

@fera765 This is specifically described in the documentation: https://rtk-query-docs.netlify.app/concepts/mutations#scenarios-and-behaviors. I'd really recommend reading that page, as well as about Optimistic Updates.

What to expect When addPost is triggered, it would cause each PostDetail component to go back into a isFetching state because addPost invalidates the root entity, which causes every query that provides 'Posts' to be re-run. In most cases, this may not be what you want to do. Imagine if you had 100 posts on the screen that all subscribed to a getPost query – in this case, you'd create 100 requests and send a ton of unnecessary traffic to your server, which we're trying to avoid in the first place! Even though the user would still see the last good cached result and potentially not notice anything other than their browser hiccuping, you still want to avoid this.

I looked at use case examples

Maybe my question wasn’t clear, why don’t I speak English and use the translator.

I don't know if I built the structure wrong, or if I couldn't understand the logic .. More in all the cases that I did based on my application I had this problem of having 3 calls to the api "PUT", "GET", "GET".

I expected the following behavior, 1 "PUT" request with the update applied to the cache, in case of an error it would revert to the previous state..

Eliminate these 2 GET requests to the database unless it is really necessary

I'm sorry if I can't describe my problem 100% 😔

[msutkowski]

There is no code in the codesandbox that would do what you want. What you're looking for is an 'Optimistic Update' - what you currently have works exactly as the comment says it will:

updatePost: build.mutation<Post, Partial<Post>>({
      query(data) {
        const { id, ...body } = data;
        return {
          url: `posts/${id}`,
          method: 'PUT',
          body,
        };
      },
      // Invalidates all queries that subscribe to this Post `id` only.
      // In this case, `getPost` will be re-run. `getPosts` *might*  rerun, if this id was under it's results.
      invalidates: (_, { id }) => [{ type: 'Posts', id }],
    }),

If you do not want to cause two additional queries to be triggered, you can remove the invalidates property, and instead manipulate the cache manually as described in the Optimistic Updates documentation. I slightly modified your CSB to show that behavior.

The point of the provides and invalidates is to do a better job of guaranteeing that your UI data is up to date with the server. You can opt-in and out of this behavior as you please, but you should have all of the utilities you need to optimize for whatever makes sense for your usage.

[fera765]

Não há código na caixa de códigos que faria o que você quiser. O que você está procurando é uma 'Atualização Otimista' - o que você tem atualmente funciona exatamente como o comentário diz:

updatePost: build.mutation<Post, Partial<Post>>({
      query(data) {
        const { id, ...body } = data;
        return {
          url: `posts/${id}`,
          method: 'PUT',
          body,
        };
      },
      // Invalidates all queries that subscribe to this Post `id` only.
      // In this case, `getPost` will be re-run. `getPosts` *might*  rerun, if this id was under it's results.
      invalidates: (_, { id }) => [{ type: 'Posts', id }],
    }),

Se você não quiser fazer com que duas consultas adicionais sejam acionadas, você pode remover a propriedade e, em vez disso, manipular o cache manualmente, conforme descrito na documenação de Atualizações Otimistas. Modifiquei ligeiramente seu CSB para mostrar esse comportamento.invalidates

O objetivo do e é fazer um trabalho melhor para garantir que seus dados de interface do usuário estão atualizados com o servidor. Você pode optar por entrar e sair desse comportamento como quiser, mas você deve ter todos os utilitários que você precisa para otimizar para o que faz sentido para o seu uso.provides``invalidates

Fantastic wow

I have been focusing on this library for over a week, and now I am sure it is very good

What a brilliant job thank you very much, I'll be back here rs