Export useQuery

[jackmellis]

Hi!

We're really keen to get integrating with wagmi.

A lot (okay all) of our contract calls are standalone react-free methods which we then wrap with React Query's useQuery. We prefer this over using something like useContractRead or useDapp's useContractCall as it gives us direct control over the contract, helps with separation of concerns, testing, etc. etc.

It'd be really great if your internal useQuery hook was exported so we could use it directly. This would save us from having to manually integrate with the notification manager etc.

[jxom]

Yeah, definitely makes sense since our implementation of useQuery has a slightly different API. 👍

[tmm]

@jackmellis if you are down, would love to learn more about how you like to tune things, etc. Feel free to DM me or drop me an email.

[gpxl-dev]

@jackmellis wondering what your final approach was here?

Also you mentioned the 'notification manager' that you didn't want to manually integrate with - was this a reference to something in wagmi or your own code? I can't see any reference to notifications in the wagmi docs...

[jackmellis]

We're still using react-query's useQuery hook. We noticed wagmi recently started exporting its own useQuery hook but we haven't got around to trying it out yet (it's on the list).

Re notification manager: I don't think you actually implemented this in the end, it was a discussion you were having with rainbow. In then end we implemented our own notifications context that we push.to whenever there's a write operation, and a subscriber then informs rainbowkit among other things.

We also rolled our own variant of useMutation that handles things like signing/mining (rather than 2 separate steps, we just have an additional status i.e. 'idle' | 'signing' | 'mining' | 'success' | 'error'). RQ's useMutation actually doesn't do a whole lot tbh and this meant we had an easy way to push to our notifications context.

[jmrossy]

It would be great some documentation about wagmi's internal useQuery client and when it should be used over an external useQueryClient. Does it make sense for DApps to set up their own client or just Wagmi's?

[tmm]

Good point! We'll likely re-align our usage to follow the same APIs as React Query for wagmi@1.

[gpxl-dev]

Would really like this. I frequently find myself making my own hooks so I can have control over the querykey etc.

[adiled]

+1 for this and a case I'm imagining that can be built atop wagmi, please suggest if it's relevant to this:

More pronounced and well documented access to queryKeys, and concept of scopeKey can enable an advanced contract writer that accepts expected mutations (side effects of contract writes) as a well-defined param in addition to ABI. It could then clear cache / refetch all those read queries upon a desired event (submission or finality or any custom outcome).

I'm assuming by digging into the passed client, this is achievable, but only from a higher level.

[0x33dm]

More pronounced and well documented access to queryKeys, and concept of scopeKey can enable an advanced contract writer that accepts expected mutations (side effects of contract writes)

Indeed the "scopeKey" property is only a string on WAGMI and on RQuery it's an Array that allows setting up additional properties which is very helpful when having complex situations where you need to be more or less granular when revalidating cache.