-
Notifications
You must be signed in to change notification settings - Fork 9
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
WIP for release/0.3.0 #36
Conversation
@martinmckenna Hey! It would be helpful if you could have a look at this. I'm still brewing the error handling, but it will be ready for 0.3.0 release. I touch a bunch of things that may break your code:
|
@eta-orionis Hey there! I'm probably gonna close your PR #35 in favor of this one. Sorry about that. But I'd love to hear your opinion on the way I implemented automatic error handling in here. I'm gonna release this after the weekend, when I test it in a real-life project of my own. |
@dkzlv awesome can't wait to try it out! can we add better TS for the error handler. I'd like to be able to type it properly, rather than it being |
Yeah, you're absolutely right. Swapped those for |
@dkzlv yep agreed. i guess what i was getting at though is i'm on my phone but line 331 in main.ts is where i'm talking about |
also looking at this diff, it is still intentional that we're going to have to check for the existence of an error, before going down our success rotue? Something like const { mutate } = useStore($postThing({ onError: () => showToastNotification("something went wrong") }))
const handleClick = () => {
await mutate();
const hasError = !!$postThing?.value?.error
if(!hasError) {
// success path
}
} |
@martinmckenna Yeah, we briefly discussed it in #27. Specifically, I outlined the motivation in this message. I'm not sure what could be done differently here from the perspective of the library. Open to suggestions though! If that's something you're willing to simplify, keep in mind you can always solve this in userland by writing a custom hook, something along the lines of: const useMutation = ($store) => {
const { mutate } = useStore($store);
return useCallback(
async (...args) => {
const res = await mutate(...args);
if ($store.value?.error) throw $store.value.error;
return res;
},
[mutate]
);
}; This would allow you to treat |
|
Features/fixes:
mutate
function until it resolves.onError
to a single Mutation Store instance.cacheLifetime
. Make it so thatdedupeTime
is responsible for calls of the fetcher function, whereascacheLifetime
is responsible for the… lifetime of the cache. Meaning, it will be put indata
even if it's stale, up tocacheLifetime
time.cache
variable set on the context. Fixes Is there a way to persist the cache in the browser? #15 and probably makes Next.js is supported correclty? #19 possible.Docs:
Breaking changes:
refetchOn*
settings are all renamed torevalidateOn*