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

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?

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.