-
-
Notifications
You must be signed in to change notification settings - Fork 29
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(mutation): add an optional key
option to mutations
#19
feat(mutation): add an optional key
option to mutations
#19
Conversation
✅ Deploy Preview for funny-banoffee-0afb46 canceled.
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #19 +/- ##
=======================================
Coverage 86.66% 86.67%
=======================================
Files 10 10
Lines 1642 1643 +1
Branches 80 80
=======================================
+ Hits 1423 1424 +1
Misses 218 218
Partials 1 1 ☔ View full report in Codecov by Sentry. |
src/use-mutation.ts
Outdated
@@ -55,6 +55,8 @@ export interface UseMutationOptions< | |||
*/ | |||
mutation: (vars: TVars, context: NoInfer<TContext>) => Promise<TResult> | |||
|
|||
key?: MaybeRefOrGetter<UseEntryKey> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In mutations, it should be able to access the variables passed to the mutation, similar to the invalidate keys
I'm realizing that allowing a computed property or a ref is actually problematic as it could create the issues highlighted in #11. It's something we will have to look into later on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering, for the ref or computed properties, is it then really worth handling them? I am just realising that users would probably rather trigger a mutation imperatively than declaratively relying on reactivity, and therefore I am wondering if passing reactivity through the key
(and the issue associated) is enough profitable. Maybe I could just type the key
the same way as you did for the keys
property (without reactivity).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right; passing a ref or a computer seems like a foot-gun. It should only be static or computed from the arguments
4321706
to
dab952b
Compare
src/use-mutation.ts
Outdated
@@ -69,6 +73,8 @@ export interface UseMutationOptions< | |||
*/ | |||
mutation: (vars: TVars, context: NoInfer<TContext>) => Promise<TResult> | |||
|
|||
key?: _MutationKey<TVars, TResult> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this key should happen before onMutate so it will only have access to vars
.
dab952b
to
cd0d00c
Compare
BREAKING CHANGE: the exported type 'UseQueryKey' is replaced by the more generic type 'UseEntryKey', which will be also used to type mutations
cd0d00c
to
d16cf2d
Compare
No description provided.