Generate tanstack query factory functions

[nadavhames]

Code of Conduct

• I agree to follow this project's Code of Conduct

AI Policy

• I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

Is your feature request related to a problem? Please describe.

For anyone using tanstack react query and are exposing procedures via ash_typescript to the frontend, only direct async functions are provided, so for every query the dev has to manually write and wire up their query hooks which takes time and is prone to mistakes.
Another frustration that can be mitigated is migrating an existing trpc app over to ash_typescript. It is currently more involved because the user needs to refactor a potentially large number of preexisting hooks.

Describe the solution you'd like

TRPC's latest redesigned tanstack query integration is simple and looks like this:

import { useQuery } from '@tanstack/react-query';
import { useTRPC } from './trpc';
export function Greeting() {
    const trpc = useTRPC();
    const myQuery = useQuery(trpc.path.to.query.queryOptions({ /** inputs */ }))
  }
}

See usage docs here.
For each RPC, it provides either a queryOptions({...}) or mutationOptions({...}) function that returns sensible args to useQuery or useMutation, including queryFn and cache key, while letting the user override whichever properties they need.

I think that ash_typescript should, for each rpc:

1. Derive from the dsl if the rpc is a query or mutation
2. Generate a queryOptions or mutationOptions function. This could be optional if for example the user does not care about react query and wants to reduce generated code size if size difference is significant.
   • To do this, examine how trpc provides the default queryFn and derives cache keys and if applicable, use a similar strategy here

Describe alternatives you've considered

No response

Additional context

No response

[Torkan]

First of all, sorry for taking so long to respond!

It is a bit beyond the scope of ash_typescript itself to have first-class support for a lot of various libs and their patterns, no matter how popular they are at the moment.

However, what it being actively worked on at the moment, is extracting a lot of the introspection logic that is currently built directly into ash_typescript, into reusable functionality so that it can also be leveraged by either other libs or homegrown functionality in a given ash project.

This functionality combined with some mechanisms to check what artifacts ash_typescript is generating in a given project, will provide the tooling that is needed for others to create additional functionality layered on top of what is provided by ash_typescript itself, meaning all the rpc actions, typed controllers & channels, validation schemas and typescript types.

Once these things are in place, then creating functionality that wraps all (or some, whatever is needed) generated rpc actions will become a very straightforward matter, and this could both take the shape of a reusable lib or just something you build into your project in order to generate the code exactly the way you want 😄

Leaving this issue open now anyway, so I'll be reminded to post an update here once the mentioned efforts are done and ready to be used.