Keep subscription `.data` after stopping (Tanstack Query)
It looks like
mySubscription.data is undefined after the subscription stops from the server side (returning from generator function).
Can I keep this data without introducing my own useState and leverage Tanstack Query instead?
I'm using the old React Query integration because there's no documentation for the new integration for subscriptions (i.e. useSubscription(trpc.mySub.useOptions()) ).
4 Replies
Just on the docs point, what's missing from here that you would want? https://trpc.io/docs/client/tanstack-react-query/usage#subscriptionOptions
TanStack React Query | tRPC
TanStack React Query usage
It's a good idea to retain the data, though to avoid a breaking change I would think that needs to be a config setting retainDataOnStop or something
In general the API is designed for you to use your own useState because that gives you total flexibility, but we did play with the idea of having a reducer style API on useSubscription to cover various use cases before settling on a simpler API
my bad, i just didn't find that section when searching for "trpc useSubscription" and similar.
edit: maybe searching
useSubscription should rank that section high in the results because by default it will only show if the search results are expanded, even though it's (imo) much more relevant than the different subsections of the classic react query integration or the migration details.
to find this section you either need to go through more of the documentation and discover the section, or you need to know beforehand that you must search for "subscriptionoption".
It's a good idea to retain the data, though to avoid a breaking change I would think that needs to be a config setting retainDataOnStop or somethingi think that would be a win for this API to save some manual state management. it's also a nice complement to the state management that the tanstack query integration already does, just like you can easily use the last yielded data to render e.g. progress info until the subscription procedure returns.
In general the API is designed for you to use your own useState because that gives you total flexibility, but we did play with the idea of having a reducer style API on useSubscription to cover various use cases before settling on a simpler APIi also thought that could be cool but it's probably not worth the complexity and it's easy enough for users like me that want to keep data beyond a given
yield to simply add the previous data to the following yield statements, like through an object. that way users have more control and the system stays simple.
tl;dr i see value in a retainDataOnStop setting and i agree that more sophisticated mechanics are not necessary.can't edit to add an attachment screenshot so here it is
