per design, we can pass queryOptions to invalidation, so:

queryClient.invalidateQueries(utils.myProc.queryOptions())

Did not realise that! Albeit inputs would be mandatory when creating queryOptions and are not mandatory during invalidation

So I think there's merit to having all 3 methods (queryKey, queryFilter, queryOptions) we've added since they give users options and represent interfaces which do exist in RQ

yeah I actually like that 👍

queryFilter could also take strongly typed options such as predicate functions etc

Good point, I don't believe I played with that initially but we can definitely enhance it a bit more

There are some limitations in Next that makes the streamed provider not viable (mostly around accessing headers in the SSR phase) that the prefetching along with streaming promises solves

Can you give some examples of what these snippets may look like? Not sure I understand

Just to clarify you'd prefer if we keep the wrappers and have this as an extra thing?

No, I'd be okay with ditching the Tanstack Query wrapper all together. I much prefer flexibility and composability, even when it comes with a bit of verbosity.

alright good :)

I'm on your side with this. I was in discussion with my teams to entirely remove it because of these limitations. Even if it is really fun to use when it work, centralised hooks, while still verbose, have a really good dx and still goes really well with trpc

Yeah I loved what you did there.

The main difference between convex and trpc seems to be the queryClient on the trpc proxy, whereas Convex just adds a default queryFn and queryKeyHashFn, and then has the convexQuery factory do the special sauce with making sure query and the convex sync stuff plays well together.

We probably wont have the queryClient on the proxy, both from feedback here but also from our own exploration. You can grab it from useQueryClient instead

I don't know how convex works, but trpc client lives in state which is why you need the hook call to get the proxy

I took a quick look at https://github.com/get-convex/convex-react-query/blob/main/src/index.ts to get an idea.

The magic is mostly in the convexQueryClient.connect(tanstackQueryClient) path, which take the convex api query key hashes, and set up a whole bunch of subscriptions to the normal WebSocket based convexClient that calls setQueryData on updates. tRPC probably won't need that opinionated of a sync implementation I think.

In theory yes! We don't have a ton of experience with other frontend frameworks but since we're just interacting with interfaces native to TQ it would be much simpler than before.

Maybe we could release a framework agnostic "core" package which can be used to implement framework specific packages, similar to how Tanstack does things

One problem here is that queryOptions doesn’t live in the query core, but in the respective adapters, because the options are slightly different for vue/solid/react

Yes but given how much simpler this new package is compared to the old one we could potentially make those "copies" and still have a "maintainable amount"

Or a community member could take it on - the main thing is the reduced complexity make it much "friendlier" to tackle

Got to be a little careful with these overrides because we may occasionally hook into something internally, by passing the options in we can assign both without any undesired behaviour

I'd say having the choice is a good thing though

True. How about infiniteQueryOptions? From your tests I got this. Having two args is fine but not ideal IMO, especially for the "empty input" case.

const queryOptions = trpc.post.list.infiniteQueryOptions(
  {},
  {
    getNextPageParam(lastPage) {
      return lastPage.next;
    },
  },
);
const query1 = useInfiniteQuery(queryOptions);

Would this also work?

const queryOptions = trpc.post.list.infiniteQueryOptions();
const query1 = useInfiniteQuery({
  ...queryOptions,
  getNextPageParam(lastPage) {
    return lastPage.next;
  },
});

It should work, but you'd miss the added trpc options to the result which can be used eg for permission systems