Define more clear way to track properties to notify

[faradaytrs]

Now we have "tracked" to automatically select options for addNotifyOnChangeProps. It helps to reduce the amount of rerenders
For example, i have such situation:

const getData = () => ({,
   mysticHash: "sdfksdhflj43rh9427hrn3yfhsk4fs", //this is something you need to check
   content: [
       // a lot of content that you are going to display
   ]
})

If you don't think too much about the details of this example and why I need it, the idea is mysticHash is something you need to track changes on, and content is something you need to display.

const ExampleComponentOne = () => {
    const {data} = useQuery('key', getData, {
       notifyOnChangeProps: 'tracked',
       select: (data) => data.mysticCache // if i write it like that i will lose content but i get desired behavior of rerenders, it will rerender only if mysticHash changed.
       select: (data) => data.content // but in my mind i would like to use select to define data i will use in my component but this way i lose rerender optimizations. 
    })
    return <Content data={data} /> //do something with data....
}

I don't have API in my mind yet, but maybe it's good idea to separate this behavior.

[TkDodo]

Thanks for the example, I have the following question:

• if the hash doesn't change, I assume the data also doesn't change. But if the hash changes, the content will also be different somewhere down the line (maybe the 99th of 100 items).

if that is the case, I think you would render optimize fine by selecting data.content only. As long as all 100 items (doesn't matter how many, just a random number) are "the same", react-query will give you the same "reference" to data, and thus opt out of rendering. you can see this in the tests of replaceEqualDeep: here: https://github.com/tannerlinsley/react-query/blob/813d70f659db73cc484fc0f465ed5a760f470853/src/core/tests/utils.test.tsx#L97

so if you return the same json structure from the backend (aka "nothing changed"), you will not re-render. If something changed (maybe just one item), it will re-render. but if something changed, it is good that we re-render, right? we want to see that on the screen, and likely the hash would also change.

[faradaytrs]

Yeah, in this case, you are right because I called this "hash", you guess that that hash is related to the content, I just think the example is not good, let's say instead of hash we have contentUpdateDate with some date and if the content is older than the user wants then it doesn't make sense to rerender, yeah you can say again that we can rely on the content and ignore the date, but I believe there are situations where it might become a problem.
Also, there is the opposite situation where we need both hash and content, so we don't want to use select (we will lose data), but if the hash (or you may imagine it as mysticValueXXX) changed then we believe that content is the same.
Why not let the user define a function that will determine data has updated or not? I think it's very "react" way.

[TkDodo]

Personally, I think its very error prone, like componentDidUpdate and the second argument to React.memo are, too. It is almost never a good idea to exclude props from those because it will lead to "stale" situations.

I haven't yet seen an example where this could be beneficial. All the given examples assume something like: I have data X, I am displaying data X, but then the data changes to Y in the cache, but for some reason, I still want to display X. I believe this goes against a "subscription" model, where our component puts on the screen what we have in the cache. What would be the reason for that? Maybe there is one I'm not seeing, but we haven't really come up with any scenario together that can't be handled with the current options.

Also, there is the opposite situation where we need both hash and content, so we don't want to use select (we will lose data), but if the hash (or you may imagine it as mysticValueXXX) changed then we believe that content is the same.

if the content is really the same, your component will not re-render. I don't see the problem with that.