Different behavior in using observable vs promise in queryClient

[donbabbeo]

I'm reading TkDodo's blog and stumble upon this post about ReactRouter and prefetching and decided to give it a shot in Angular.
The concept it's pretty simple: use the resolver function to fetch early to prevent loading the component at all in case of error and leveraging the cache of Tanstack Query to get the data in the component. This involve calling ensureQueryData on the queryClient to guarantee that the data exist on cache.

I create a simplistic approach in this StackBlitz.
As you can see the "problem" is that queryClient is built to reason with promises and when you pass a promise as queryFn to ensureQueryData or similar methods it got resolved internally. This does not play well with queryFn when is an Observable: queryClient doesn't treat it and thus the return type of ensureQueryData is Promise<Observable< T >> instead of Promise< T >.

Clearly the simple solution is avoid queryFn with observable and if we need to manipulate the observable stream we need to use result$ from the query result. But i don't like the idea, i prefer dealing only with observable.

Any idea if this could be adressed somehow?

[NetanelBasal]

Currently not all the methods supports promise or observable. We wanted to add it based on usage. I guess we can add support for ensureQueryData. Do you want to create a PR?

[donbabbeo]

Sure, i can give it a shot in next few days. I'm not the best typescript developer but it shouldn't be too complex

[luii]

@donbabbeo unless you're doing something like Streaming, SSE or Websockets i would just convert the get/post/put/etc request to a promise since they'll be resolved once the request is done, you still can do error handling and all that stuff in there - the only difference being that you have to convert it to a promise (with lastValueFrom or firstValueFrom, for reportProgress = true however lastValueFrom should be used for catching the error or the response) afterwards, you wouldn't gain or lose anything when doing it like this IMHO.

[NetanelBasal]

I also not recommend to use resolvers as it's not good UX IMO. Your users will see an empty screen until the data is resolved.

[luii]

@NetanelBasal i dont see a problem with using a resolver if you first try to get a cached result and then if this result is not available just return a sync result (with placeholder data for example) and also start the process of querying the data without dependending on it, it would work nonetheless without having a blank page.

[luii]

The same is done in the articale @donbabbeo posted, they're using initialData which was replaced by placeholderData for v5 iirc. So using a resolver would be a good choice in this case IMHO.

[netanel-utila]

But resolvers expect for single emission so I don't understand what u mean. Would love to see a stackblitz example.

[donbabbeo]

i would just convert the get/post/put/etc request to a promise ... (with lastValueFrom or firstValueFrom)...

We are on the same page here, i used fetch on the stackblitz only to make a pure promise for testing purpose.

I also not recommend to use resolvers as it's not good UX IMO. Your users will see an empty screen until the data is resolved.

I'm playing devil's advocate here considering i create the discussion, but i can't argue with that.
I never use resolver because the tradeoff aren't wort it IMO. We trade UX for few ms early fetch. Dealing with loader indicator while resolving usually involve a lot more code than necessary and it always seems hacky. The only possibile advantage that i can think of is if the routed component is resource heavy: if the query fails we will avoid to load the component altogether.

But reading how TkDodo speaks so enthusiastically about ReactRouter and noticing how similar it was with built-in Angular router maybe i was missing something. I'm not a react developer so probably a lot of that stuff is flying over my head but i'm still wondering what the fuss is about. It seems exactly the same as Angular router and require the same workaround. At this point using directly Tanstack Query in the component seems to grant better UX, both in Angular and React. 🤷‍♂️