New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Automatic query invalidations #5264
Comments
This seems like it wouldn't be possible without breaking the server/client code separation, since the router is defined on the server, and only the ttpes are available to the client. |
I don't think this would not require a breaking considering our RPC-spec can return more data {
result: {
data: TOutput; // output from procedure
}
} A mutation could return e.g. {
result: {
data: TOutput; // output from procedure
},
invalidates: [
['post', 'list'], // invalidate post.list
['post', 'byId', 1], // invalidate post id 1
]
} |
It will be tricky in the Would a mutation stay "loading" until everything has been invalidated? Timing matters here if you do e.g. a redirect as a result of a mutation - you'd likely want the invalidation happen after a route change - think in the case of deleting a post you're viewing as an example. Would likely need to be configurable. |
My recommendation is to Invalidate full cache on every mutation until you actually have a need for anything else |
This would be a really great addition to TRPC. @KATT perhaps zenstacks implementation could be a useful source of inspiration |
Describe the feature you'd like to request
I would love the ability to define invalidations in my query/mutation definitions, so that queries can be automatically invalidated without having to call it manually on the client.
Describe the solution you'd like to see
Example
Given a mutation called
updateUser
and a query calledgetUser
. In the client right now, everywhere you callupdateUser
, you need to remember to invalidategetUser
to prevent staleness.Instead, it'd be great if this could be done automatically for you if your definition looks like so:
Describe alternate solutions
n/a
Additional information
No response
👨👧👦 Contributing
Funding
The text was updated successfully, but these errors were encountered: