Why is there less need to normalize state with RTK Query?

Question

According to the redux docs: "While there is less need to store the response in a normalized lookup table with RTK Query managing caching data, transformResponse can be leveraged to do so if desired."

1. Why there is "less need" with RTK Query managing caching data?
2. What are the trade-offs of normalizing state with RTK Query?

Grube

Answer 1

We cover the answers to both those questions in more detail in both the RTK Query docs, and the "Redux Essentials" tutorial:

• https://redux-toolkit.js.org/rtk-query/usage/cache-behavior#no-normalized-or-de-duplicated-cache
• https://redux.js.org/tutorials/essentials/part-8-rtk-query-advanced#normalized-vs-document-caches

Summarizing for here:

One of the main reasons to normalize data is to make it easy to update a specific item by its ID. With RTK Query, you're generally not "updating items" in the state any more. Instead, the server is the source of truth. In that scenario, you use an RTK Query mutation to send an update to the server, invalidate any corresponding queries, and re-fetch all of that data from the server. So, different use case, different usage pattern.

Charity

Amazing. This question has 7 views and I think 4 were from me. You really are an answerer of questions. Thank you :) – Grube

So, if I have a long list of items loaded with infinite scrolling on my screen and I update one of them, does RTK Query officially recommend throwing all the items away and "simply" re-fetching them (even if it requires multiple HTTP requests due to pagination)? Or is RTK Query not suitable for this use case? – Ingeringersoll

Right now RTKQ doesn't have specific official support for infinite pagination queries. There's partial support, but it's kind of complicated, per discussion in github.com/reduxjs/redux-toolkit/discussions/1163 and github.com/reduxjs/redux-toolkit/discussions/3174 . We do hope to add specific official infinite pagination support in the near future, but no specific ETA. Beyond that, you may be able to invalidate just the one "page", not everything you've fetched. – Charity

Answer 2

In my opinion normalization can be always useful, it just depends on type of application. The more mutations and data updates you have, the more normalization and automatic updates becomes handy. Especially for mutations which should update/invalidate multiple queries. Invalidation is expensive, and often redundant, if you already know the data. Alternatively, manual updates take time, complicate the code and you need to know which queries should be actually updated.

This is why I created normy plugin to rtk-query - https://github.com/klis87/normy/tree/master/packages/normy-rtk-query#normyrtk-query

This gives you automatic normalization and data updates for rtk-query. You use rtk-query like usually, but you can forget about data update most of the time. It provides similar experience known from apollo graphql, you need to just care that updated data are present in mutation responses, and you forget about the actual queries updates.

Backus

Answer 3

Normalization is a very good practise, and RTK Query doesn't have it just because they could not implement it in a good way, same as other cool things like infinite scrolling pagination.

But there is a better lib for working with fetching and caching that supports both of that - react-redux-cache, and is not over engineered - its API is very simple.

Bramwell