[RED-10] `prefetch` creates a suscription that can not be unsubscribed

[phryneas]

Currently, prefetch creates a subscription that cannot be unsubscribed.

Ideally, prefetch should either

• subscribe and directly unsubscribe, to just keep the cache data around until cache collection
• subscribe and return a means to unsubscribe

It could also just take an option to switch between those two behaviours.

_RED-10

[bever1337]

Are there ideas for how usePrefetch could return unsubscribe without a breaking change? Technically you can assign a function as a property of another function, but I don't think that's a good solution for a public API.

Running unsubscribe on the thunk's finally inside prefetch seems pretty simple by comparison.

Edit: I've reviewed the source more and now understand this isn't a relevant question. Nothing is returned now, so the change would not be breaking

[bever1337]

In PR #1938 I toyed around with prefetch resolving void OR the query result, exposing unwrap, unsubscribe, etc. That was pretty cool I thought. 5 seconds later, I realized this is a convoluted path to get the same behavior as manually initiating a query. I don't know why anyone would want the current behavior, but this does represent a change.

[bever1337]

The next approach will be to provide a config option like cleanup, where false is the default (and current) behavior. Unsubscribing by default is a breaking change, so the last commit needs to be stepped back. There's still no need to expose unsubscribe in my opinion. Long-term, I think the default behavior should be to cleanup and a dangling subscription should be opt-in. I imagine use-cases like an endpoint that provides context for an entire application.

[vladamx]

@phryneas Bumping this since it can really lead to unpredictable behavior in the app. In general, subscription management is not straightforward.