Using Sockets

[benjasHu]

Hi! I'm trying to use socket.io as fetcher client, but I could not find any info about this.

The only related information I could find is at a SWR issue but I think is not exactly the way it has to be accomplished with React Query.

In comparition with SWR's code, this code mutate('/api/data', data, false) has to be replaced using setQueryData?

I'm a little confused about this. Any help?

Thanks!

[tannerlinsley]

Since socket.io is not promise based and instead stream based, you cannot use the normal useQuery-like hooks with it. However, if you merely just set up your stream as normal, then use queryCache.setQueryData, you can synchronously update the cache as data comes in. Also, if you want to simply use sockets as a signaler for your queries to refetch, you could do that too and use queryCache.refetchQueries to trigger a refetch.

Also, yes, setQueryData is the mutate of React Query.

[benjasHu]

Ok I understand. I have been doing some advances in this direction that you are telling (stream based socket & queryCache) and it works perfectly.

But, in this direction, does it mean that I would not use useQuery and useMutation and manage all directly with queryCache? Won't I lose the use of some functionalities like refetchAllOnWindowFocus or useMutation callbacks?

I mean, I know that the use of useQuery and useMutation works returning a promised value and, in that direction, is difficult to accomplish in a stream based sockets. What do you think would be the best approach?

Thanks so much for your support and congrats for this great library.

[tannerlinsley]

Yes, you would, but sockets are not transaction based, so there would be nothing to "refetch" if you will. Unless you are using your socket to both request and recieve data, then I guess you could theoretically set up a system where you could:

• create a promise in a query function
• send a message to your server through socket, asking for data with a unique identifier (eg. an idempotency key)
• wait for the response that has the same unique identifier
• match the response to the pending promise and resolve the promise

IMO that's a tone of work for little benefits. If you are considering this, then I would suggest you introspect on your architecture and ask yourself what your true technical requirements are for your data. If you are working with transactional data, then you're going to want a transactional interface, like promises. If you are working with streaming data, then you won't really be able to rely on any transactional features of it any way.

[benjasHu]

That is exactly what I have coded but I agree with you, I think that in this situation we are going to switch to a single state manager to simple update our collection listening to the sockets. We are developing a chatbot fully done with sockets.

By the way, if we need transactional data functionalities we will use the library without a doubt.

Again, thank you so much for your support.

[tannerlinsley]

You bet. I would recommend watching this for some inspiration on patterns: https://www.youtube.com/watch?v=J-g9ZJha8FE&t=795s