Possibility of accessing mutation's observers (MutationCache onError)

[janowskipio]

Hello!
First of all, thanks for your hard work maintaining a high level of this library 🙇

I wanted to ask if you would consider making it possible to access (currently private property) mutation.observers in MutationCache's onError callback? (to be able to access mutateOptions.onError for the observer)

The case I'm pursuing is to make global error handling as simple as possible, so developers don't have to think about the error handling most of the time:
"use the default/global (MutationCache) error handler (showing some generic error modal) if no onError is specified for either useMutation or mutate"

Currently, in v5, we are just using meta on useMutation and passing the suppressGlobalOnError variable to disable default error handler, in case we want to pass custom onError while using mutate - but this causes:

1. additional code which would be great if we could avoid
2. logic separated in 2 places that are not connected anyhow (1 - passing suppressGlobalOnError to useMutation, 2 - passing onError to the mutate. Both can be placed in different places/files in the code).

Or maybe you have some other idea to achieve the above?

Thanks!

[TkDodo]

if no onError is specified for either useMutation or mutate"

the callbacks on mutate have a different purpose. You can achieve "if no onError is specified for useMutation" by using defaultOptions. I would treat onError on mutate totally separately (and only for component specific side-effects, like described here: https://tkdodo.eu/blog/mastering-mutations-in-react-query#some-callbacks-might-not-fire

[janowskipio]

thanks for the fast reply 😉
We are already using mutation.options.onError in the MutationCache onError callback, as goes for handling "if no onError is specified for useMutation" there 👍
However, we would still like to not fire global/default onError specified in MutationCache when someone defines onError on the mutate - e.g. scenario is handling 409/400 errors as inline input errors instead of showing some generic error modal - as mentioned above right now we need to pass a custom variable (suppressGlobalOnError) to the meta in useMutation which is not ideal.

If you have any other ideas on how we could make global error handling simpler please share them 🙇
Ideally, we could either just access mutates options (onError) in MutationCache or pass the additional property in mutate (like meta for useMutation) that we could consume in the MutationCache - although I understand that mutate is on a different abstraction layer than useMutation in regards to the MutationCache onError handling.

We were able to have very simple/comfy code with the v4 making it possible to access mutation.observers so maybe it's somehow possible to connect these 3 layers together (MutationCache onError/useMutation onError/mutate onError)

I already read your articles / issues regarding onError and I understand there is a valid reasoning behind all of the changes in v5 (and that we were just using some workaround accessing private properties in v4) - I just feel there is some space to make it easier for the react query users to handle the global error topic 🖖 🤝

[TkDodo]

However, we would still like to not fire global/default onError specified in MutationCache when someone defines onError on the mutate

The problem here is that even if mutate defines onError, there's no guarantee that it will actually run because the callbacks are scoped to the observer, which can unmount before the mutation finishes. That's why I'd see these two layers as "additional" rather than "we don't need the global one because mutate already defines it"...

[janowskipio]

I feel as well that the proposed API change is not the "correct" way to handle this topic (rather some workaround), just wanted to try and check with you what are your thoughts, thanks a lot for the discussion🙇

[sKopheK]

@janowskipio hi, did you end up doing // @ts-expect-error and accessing the private observers property anyway? :) i do also understand all the concerns and thought behind useMutation vs mutation itself, but can't think of a better solution than what you suggested when i don't wanna have this hidden dependency (meta prop in useMutation and then onError in actual mutation)

[janowskipio]

as far as I know, accessing observers property in v5 is no longer a possibility 🤝