Is it correct to re-create a query subscription when the arguments change?

[velidan]

Hi everyone. I have a very interesting and non-trivial situation regarding subscriptions to queries to be able to get an optimistic response. I'm using client.query API for it

Basically, I have a react app and I don't use hooks so I must use the standard uqrl client API.
The structure is:
A) a data transport service that fetches the data from server. It creates a subscription to a query and triggers an callback to the executor service on every query update event
B) a store service that receives args for the query and triggers data transport service / gets results and publlish them for the whole app

I used the standard client.query.toPromise() before and it was working like a charm hovewer when I started to implement an optimistic response I found that toPromise doesn't populate the optimistic data. Only the subscription helps in this way so that's why I must use it

The most trickiest part in this setup it's the next problems I faced:

1. prevent duplicated subscriptions if the first one is already exists but the service tries to create the new one
2. what to do if we have some pagination query. I created a subscription for this query with some arguments like: first: 1, limit: 10 but later the arguments change: first: 2, limit: 20. So what to do with that?

While the 1 problem could be easy solving by using some cache/registry with unique keys the second one was a real challenge for me.
I didn't find nothing better than just destroy the previous subscription and create a new one with the new pagination arguments. Looks like it works, but it provides a lot of complexity to track the previous subscriber execution and to eliminate them if they belong to the previous/old subscription. I even created a dedicated query subscription service to handle it.

But, I have some feelings that it's too complicated and could potentially bring some issues in future.

so my question: Is this solution correct or did I just made some unnecessary mess? Could someone help me, please, with that?

I don't know if the code will be helpful because there is a lot of it and I just don't know if someone interested in it so I don't want to annoy nobody.
If someone are interested in it, please, let me know and I'll show it with pleasure.

[kitten]

prevent duplicated subscriptions if the first one is already exists but the service tries to create the new one

I'm not sure if you'll necessarily have to handle this for queries. If you check the Client, it basically already does a lot of deduplication and you only have to make sure you unsubscribe when you don't need results anymore.

The deduplication should be handled for you however 🤔

what to do if we have some pagination query. I created a subscription for this query with some arguments like: first: 1, limit: 10 but later the arguments change: first: 2, limit: 20. So what to do with that?

This is not a trivial question.
In theory, you'll have to combine and keep multiple sources around when you add a new page, e.g. with combine from wonka, combining multiple pages into one manually.

Alternatively, you can use Graphcache's pagination resolver, which is basically a "lazy" solution to allow one pagination query to map to all of them, so you don't have to handle this in the UI/binding code.

Looks like it works, but it provides a lot of complexity to track the previous subscirber execution and to eliminate them if they belong to the previous/old subscription

I don't know your code, but unfortunately, part of subscriptions/streams is that you always have to clean up after yourself. The same goes for any urql bindings, or any UI library effects. If you start an effect, you also need to define when it ends 😅 I have no suggestion for this and that's just how it is.

At the very worst, you could just not care about pagination unsubscriptions and just bite the bullet and always keep them active indefinitely. Not efficient, but also, if you know something will never become inactive it's ok to skip unsubscriptions in some cases.

I think the problem here is that you may have to think of coding patterns that remove some of the pressure and constraints you're dealing with.

For example, if you unsubscribe from a page that becomes inactive to replace it with two pages, is it possible for you to unsubscribe, then replace the source with a combined one, and then subsequently resubscribe?

[velidan]

Thank you for your answer Phil. It's really helpful!

My problem that I don't clearly understand what do you mean by saying: unsubscribe from a page that becomes inactive to replace it with two pages, is it possible for you to unsubscribe, then replace the source with a combined one, and then subsequently resubscribe
I just can't imagine it. Do you mean the first page something like like a dataset that had been reached by passing arguments first: 1, limit: 10 ? Or the physical page in the app?

because I simply have an infinite list of items that have a pagination. So for now things work in this way:

1. fetch the data chunk with first: 1, limit: 10. I'm subscribing to the query and getting the result. Them I'm storing it in the store service
2. fetch the next data chunk: first: 2, limit: 20. I'm unsubscribing from the old query and creating the new subscription to get the result

So does the urql removes the old data chunks if the relative query subsciprion will be terminated?

Also, could you, please, help me to understand what did you mean when you was taling about:

In theory, you'll have to combine and keep multiple sources around when you add a new page, e.g. with combine from wonka, combining multiple pages into one manually.

If I won't combine all the subscriptions with different arguments so the previous data will be lost? Because I don't clearly understand why should I keep multiple sources around

Alternatively, you can use Graphcache's pagination resolver, which is basically a "lazy" solution to allow one pagination query to map to all of them, so you don't have to handle this in the UI/binding code.

Do you mean that if I don't have it so some UI components that depends on the old pages (for ex: first: 1, limit: 10 ) will lost their data if I'll delete their subscription and will create a new one for the arguments: first: 2, limit: 20 ?

Sorry if my clarifications are a bit dumbass-like

[kitten]

I just can't imagine it. Do you mean the first page something like like a dataset that had been reached by passing arguments first: 1, limit: 10 ? Or the physical page in the app?

That statement is limited to streams, so data. When you use client.query(...).subscribe (or other forms of subscribing to udpates), you'll need to unsubscribe when you're done with the data.

However, what I mean is, if you're combining two streams, say combine(pageOneResult, pageTwoResult) into one Source, then you could subscribe to this while unsubscribing from pageOneResult. — just as an example of what this could look like.

[...] Then I'm storing it in the store service.
[...] I'm unsubscribing from the old query and creating the new subscription to get the result

What I mean here is, if any data in the first page updates, and you don't have a subscription to the first page's query around, you won't receive updates.

So does the urql removes the old data chunks if the relative query subsciprion will be terminated?

No, the data is still around. If you're using Graphcache, it'll still be cached by it. If you refer to the “Architecture” page of the documentation, exchanges are limited to processing operations and deliver operation results in return.

The Client hence has no knowledge of the data — only of “consumers” of that data. If you call client.query(...).subscribe(...) you're basically registering a callback, to put it simply. When you unsubscribe, the Client releases all “handles” it has on that data and issues a teardown signal.

The only thing that the teardown signal does for the cache is that it tells the cache to stop reacting to changes of the corresponding query.

To put it simpler, as soon as you unsubscribe, the Client guarantees that it'll not deliver results for this operation and caches / other exchanges also guarantee that no results will be delivered for this operation. That's because if no one is subscribed to an operation, no one can see their results anyway.

In UI bindings this corresponds to things like the useQuery API, or simply components. If a component was to unmount, then there's no component to render a query result, in short. That's what the source model is for.

If I won't combine all the subscriptions with different arguments so the previous data will be lost? Because I don't clearly understand why should I keep multiple sources around

So, no, the data is not lost, but you will only receive updates for the exact query operation you're subscribed to of course.

Graphcache's pagination helpers actually are a "break" of that of some sorts. Because they deliver more items than your query asks for from the API, and it assumes you want infinite pagination, it will deliver old items too and will deliver the combined list in any pagination query on the field the helper is used on

[velidan]

@kitten thank you so much for your detailed answer!