Completed subscription not reflected in hook data

[zenios]

There are two cases where a subscription query completed. Either it unmounts or the server completes the source. i was expecting that on source completion the "fetching" value of useSubscription would turn to false but it still stays the same.

I went through the code of the subscription exchange and found out that the complete event from forwardSubscription is sent to the wonka stream via the complete function but for an unknown reason it does not propagate up to the parent.

[kitten]

Hiya 👋 this is a known limitation since we weren't sure whether it was worth forwarding completed subscriptions through to the hook and exchanges.

It's possible to customise the data coming back to add this for now with a slightly customised exchange.

If you're interested the line in question is here: https://github.com/FormidableLabs/urql/blob/master/src/exchanges/subscription.ts#L78

We basically have no result that corresponds to the completed subscription. The useSubscription hook still has a fetching flag which wasn't on purpose actually, but do you know of any use case where this would be useful? Happy to reconsider and come up with a solution 👍

[zenios]

Actually i am not interested on the data of completed.what would be nice is since we have the fetching flag to actually turn to false when the subscription completes. I see that on the line you specified, the complete is passed down to the wanka source and i was expecting that adding an onEnd at the useSubscription pipe before subscribe i would be able to catch it and set the fetching to false. Unfortunately onEnd is called only when the component unmounts. As for the usefulness, i assume someone could use the flag to trigger side effects when the subscription has completed For example in a multiroom chat system navigate the user away when the room has closed In the end if you decide not to handle complete on the hook then its better to remove the fetching flag since it confuses users of the library. Thanks

…

On Sat, 24 Aug 2019, 13:01 Phil Plückthun, ***@***.***> wrote: Hiya 👋 this is a known limitation since we weren't sure whether it was worth forwarding completed subscriptions through to the hook and exchanges. It's possible to customise the data coming back to add this for now with a slightly customised exchange. If you're interested the line in question is here: https://github.com/FormidableLabs/urql/blob/master/src/exchanges/subscription.ts#L78 We basically have no result that corresponds to the completed subscription. The useSubscription hook still has a fetching flag which wasn't on purpose actually, but do you know of any use case where this would be useful? Happy to reconsider and come up with a solution 👍 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#407>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAV3YPIB6XWGFWI2YEWXXTQGEBF3ANCNFSM4IPEYXZA> .

[JoviDeCroock]

I've been considering this, I'm not entirely sure if the completion addition will be worth it, that aside I agree that fetching on the hook can be quite confusing since it can be considered an indicator that the subscription is running.

I don't think leaving fetching out is a breaking change (please correct me if I'm wrong) since most people at this moment rely on the callback to add the event somewhere or to trigger something. I can't see a use case to rely on the current state of the fetching variable.

[kitten]

I think we could also add it by sending a teardown as a reexecuted operation on completion. Thst being said that would also need some minor hook changes

[JoviDeCroock]

Then we need to make a distinction between a "completed" teardown and a connection interrupted right?

[kitten]

This will be shipped in the next release, which will probably be a quick patch release 🎉

We've accomplished this—as was planned above—by reusing the teardown signal. The teardown signal is used to cancel ongoing operations in the exchange chain. It is sent automatically when all components/hooks that are interested in one operation have unsubscribed/unmounted and aren't listening to results anymore.

The change is to make teardown an active operation signal as well. When it's now sent by an exchange (or manually of course) it actively cancels ongoing result streams, which the hooks can use to set fetching to false.

[zenios]

Great news.thanks a lot.

…

On Tue, 27 Aug 2019, 02:55 Phil Plückthun, ***@***.***> wrote: This will be shipped in the next release, which will probably be a quick patch release 🎉 We've accomplished this—as was planned above—by reusing the teardown signal. The teardown signal is used to cancel ongoing operations in the exchange chain. It is sent automatically when all components/hooks that are interested in one operation have unsubscribed/unmounted and aren't listening to results anymore. The change is to make teardown an active operation signal as well. When it's now sent by an exchange (or manually of course) it actively cancels ongoing result streams, which the hooks can use to set fetching to false. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#407>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAV3YM233YD36FV33TZ7A3QGRUNLANCNFSM4IPEYXZA> .