const { mutate } = useMutate("patch", "/api/test");

const handleUpdateClick = () => {
    mutate({ params: { query: { message: "Message updated by mutate!" } } }, {
     onSuccess: () => queryClient.invalidateQueries({ queryKey: ["get", "/api/test"] })
   });
 };

This should work for your example but a typed invalidateQueries function would definitely be a nice enhancement

Thanks for the reply @araphiel, I will definitely use this over my current approach. With that being said, is there a reason this is not the default behavior?

The reason that it isn't the default behavior is more for @tanstack/react-query than for this library, but there is a good reason that refetches don't happen by default. If you get what data would be changed in the cache back from the mutation, the you can get that cached object by it's key, modify it, then set it in the cache by its key (causes a rerender). That removes the need for refetch. While a quick invalidation to cause a refetch is simple, you may already have all the data that you need, and you won't need to spend the extra money on your server's CPU cycles and network load. Also, although the query keys are pretty regular in shape in this library, in raw @tanstack/react-query they are not so regular, so you'd need a list of what you want refetched anyway, and calling the function to invalidate them doesn't save much on syntax from a list representation.

@Type1J That makes sense. Even still would it make sense to to bake into the useMutate a flag to either 1) use the value returned by the mutation call as the new value, 2) invalidate the query as suggested by @araphiel , 3) do something custom, or 4) do nothing (the default). The reason for this is most operations are just CRUD and doing so would save developers from writing a bunch of duplicate boilerplate code.

Personally, I have always done optimistic cache updates, and patched in mutations (I either removed the update on an error, or replaced it with something in the mutation's response), but, even if I completely agreed that auto refetching should happen, I'm not sure that the library has enough information to know what queries would be bound to which mutation, since no such declarations are made. The library needs to know what to refetch somehow, and I believe that calls to invalidateQueries() may be no more verbose than another solution.