feat: add precise type to predicate in invalidate

[SrBrahma]

Re #3496 (comment)
Closes #3545

🎯 Changes

Adds the corresponding input type to predicate in invalidate on trpc.useContext().router.procedure.

Before

After

Notice that the queryKey has the right type in [0] and [1]. type can be query or infinite, depending on the procedure.

• For reference, this is how the procedure is defined:

✅ Checklist

• I have followed the steps listed in the Contributing guide.
• If necessary, I have added documentation related to the changes made.
• I have added or updated the tests related to the changes made.

[vercel]

@SrBrahma is attempting to deploy a commit to the trpc Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
www	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Feb 26, 2023 at 1:11PM (UTC)

[SrBrahma]

I had to add this as QueryKey is not generic and I wasn't able to make it generic as it considers the second array item to be optional. Changes to it (including a different name) are welcome!

[nicolassanmar]

As the creator of #3545 this should implement a solution to the issue!

[KATT]

@juliusmarminge can you review this please? you're the master on this :D

[juliusmarminge]

Looks good but I think we can clean it up a bit on next where queryKeys aren't this messy...

[SrBrahma]

@juliusmarminge before / if you are going to merge it, I suggest you read this discussion I participated in react-query after I made this PR:

TanStack/query#4762 (comment)

Tl;dr: I don't know if this PR is good as if a query is enabled=false, the query params may have invalid values types.

Maybe we could have the type to be something like ~ { enabled: false, queryKey: [x, unknown] } | { enabled?: true, queryKey: [x, theRightType] }, so the user will need to check for enabled === undefined || enabled === true to then use the data with the right type?

While this PR works, it may be dangerous if enabled is false as it may potentially lead to invalid data access.

Edit: Also, I am aware that in 10.10.0 we now can use partial invalidate. I can't say at the moment if I still have a use for this typed predicate, will check it and update this tomorrow.

Let me know your thoughts!

[juliusmarminge]

Edit: Also, I am aware that in 10.10.0 we now can use partial invalidate. I can't say at the moment if I still have a use for this typed predicate, will check it and update this tomorrow.

yea i realised that just after i approved. fixed now - also handles infinite queries where cursor should not be part of the input type

[juliusmarminge]

Maybe we could have the type to be something like ~ { enabled: false, queryKey: [x, unknown] } | { enabled?: true, queryKey: [x, theRightType] }, so the user will need to check for enabled === undefined || enabled === true to then use the data with the right type?

This wont matter since the input type will be a DeepPartial so you have to check for every prop you try to access no matter what

[nicolassanmar]

@juliusmarminge @SrBrahma

While this PR works, it may be dangerous if enabled is false as it may potentially lead to invalid data access.

I think that typing the predicate still makes sense, as it will be right in regular use cases. People can only find data in the cache with unexpected typings if:

1. If they tell TS to ignore a typing error (for example, a non null assertion, even when enabled: false).
2. If they tampered with the react-query cache in some way

Somewhere in the documentation should state that the typing is only true if they did not do any of the above.

[juliusmarminge]

I think this is fine. Since the type is a deep partial, users will still need to check for nested property accesses so that shouldn't be an issue, no matter if enabled: false is used or not(?).

Maybe @TkDodo has some insights too?

[TkDodo]

I think this is fine. Since the type is a deep partial, users will still need to check for nested property accesses so that shouldn't be an issue, no matter if enabled: false is used or not(?).

Maybe @TkDodo has some insights too?

I re-checked the linked react-query discussion, and I think I understand the issue now better. Note that queries where all observers are disabled are explicitly exempt from being refetched, but the predicate filtering is still applied first:

• https://github.com/TanStack/query/blob/765f6196e900c1dd826b040773fcf97839ca60d0/packages/query-core/src/queryClient.ts#L253-L256

If the type will be deep-partial in the future, I think this will side-step the issue 👍