-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
typeDefinition of updater function in setQueryData #506
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
Comments
@TkDodo I had a similar issue occurring with
Broken
Fixed
Hope this helps |
Hi @sekhavati Yeah, it works like this with Arrays, but note that you could also provide the call-side generic:
The reason this works is exactly because you have an
However, if you are trying to do the same thing with a single user, it still won't work, as you cannot just say
will still result in:
which is still the exact same issue |
@TkDodo I see the same error as you now after enabling strict mode regardless of whether it's a single or array based example. I'm in the middle of migrating a JS project to TS and didn't have it on before. I also agree that |
Status on this? |
Hi Tanner, The main question remains: Can the if yes, that means that the types are correct, but that the example can fail here when accessing if no, then all we would need to do is "fix" the type definitions of Thanks for you help :) |
It could be |
Okay, I didn't think of that. I don't think there is an easy way to make that type-safe (as in: it will be The question is if that is a use-case we want to cover, and if it is worth to do Let me re-phrase the question: Given a valid |
This should be possible as well. If you don't set the initial value the default one will be |
ah right, so instead of:
we should have:
? |
yes, it makes more sense I think |
🎉 This issue has been resolved in version 1.5.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
@tannerlinsley I think I have to resurrect this issue for the v2 version: The type of updater seems to have been reverted to:
still, I think it should be:
because I cannot produce I can create a new issue if you want, or also just make another PR? |
Currently the |
Well I would like it to stay undefined then? The issue is that you cannot, on type level, produce to re-iterate from my example above:
this just doesn't work because So what I am doing at the moment is bypassing the functional updater
that works, but then what is the functional updater for? The optimistic update example is written in js, but this would actually not work with the current typings in TS. if the functional updater allows undefined to be returned, we can do:
which means if we get |
If queryCache.setQueryData<User | undefined>('key', oldUser => oldUser && {
...oldUser,
lastName: 'Smith',
}) |
right, I can include Looking at the code, updater is defined as: but when we actually call the functional updater, the result is coerced to but looking at the type definition of so why can't I return |
It all depends on what you consider as a valid result for that query. If you expect |
I do generally not consider I think I'll just stick to the manual Thanks for the clarifications 👍 |
@TkDodo this worked for me:
|
1.5 years later and we've finally managed to do that in v4 🙌.. You can now return here is the PR for reference: #3271 |
Hi,
First of all: thanks for this 😎 library. I'm having a quick typescript question:
setQueryData
takes anupdater
in the form of:The question is: if
oldData
is possibly undefined, how would be we able to constructT
?suppose we have a simple type:
and we mutate that persons firstName, which we want to optimistically update (I've taken the optimistic update example as a base):
but if
oldData
is possiblyundefined
, the resulting object can never be of typePerson
- it might miss thelastName
.We are currently working around this by doing:
The question is: can
old
really beundefined
? If so, wouldn't this be a runtime error in the example here when accessingold.items
? Or is this maybe just an issue with the type definitions andold
can actually never be undefined?Thanks for clarifying
The text was updated successfully, but these errors were encountered: