Solid JS Adapter For TanStack Query

[ardeora]

Hello Everyone!
Hope everyone is having a great week. I have been working on the Solid JS Adapter for TanStack Query. I wanted a place to discuss my motivations for the patterns I have adapted as of now. I also want this discussion to serve as a place for folks to offer feedback/contribute so that we can make solid-query helpful for all use cases.

Query Keys in solid-query? 🤔

One challenge that needed to be addressed as I started out was making the queryKey reactive.

If you're familiar with react-query. The query key is an array used to keep track of the query in the QueryClient cache. Whenever any of the items in the query key change, React Query treats it as a new query and will fetch new data.

const [page, setPage] = useState(1);

const query = useQuery(['users', page], async () => {
  return fetch(`https://api.io/v1?page=${page}`).then(d => d.json())
})

// Suppose `page` is incremented to `2`. The update re-renders the component, 
// and the useQuery function is ran again with queryKey as ['users', 2]

Unlike react, Solid Component functions are usually executed once. and component states are responsible for making themselves reactive using Signals/Stores. In order to implement the same behaviour with solid-query, we can do something like:

const [page, setPage] = createSignal(1);

const query = createQuery(['users', page], async () => {
  return fetch(`https://api.io/v1?page=${page()}`).then(d => d.json())
})

NOTE: We are passing the signal Accessor function page instead of the signal's value page() in the query. Why? Let's assume we define the queryKey as ['users', page()]. This query key will work for the initial query. But when we update the page signal, the query object will still show page 1's data. This happens because the query key was instantiated as ['users', 1] and the queryKey array is not reactive. Therefore, providing the Accessor function tells solid-query which signals it needs to track for changes.

Wait, but what if my queryKey is derived from a calculation on a signal? 😱

With the previous approach, For example, you wont be able to do something like this:

const [page, setPage] = createSignal(1);
const [offset, setOffset] = createSignal(10);

const query = createQuery(['users',  {
   cursor: page * offset // NaN. Cannot Multiply Functions
// cursor: page() * offset(), <-  Alternatively, this value will not be reactive
}], async ({queryKey}) => {
  const [id, params] = queryKey
  return fetch(`https://api.io/v1?cursor=${params.cursor}`).then(d => d.json())
})

So what's the solution here? This is where solid-query differs from react-query a little bit. Solid Query allows users to also pass a function that returns an array as a queryKey. This will allow users to also be able to use derived values in their createQuery calls

const [page, setPage] = createSignal(1);
const [offset, setOffset] = createSignal(10);

const query = createQuery(() => ['users',  { cursor: page() * offset() }], async ({queryKey}) => {
  const [id, params] = queryKey
  return fetch(`https://api.io/v1?cursor=${params.cursor}`).then(d => d.json())
})

This above example works fine and is fully reactive!

I wanted to bring these two approaches to attention in this discussion here. I would love some feedback on whether this approach makes sense for people as well as offers them flexibility to use createQuery however they like. I would be more than happy to make changes if there are flaws that I missed. I would love your contributions on the GitHub repo linked here: ardeora/solid-query

Example 1: createQuery

I was able to implement the createQuery function for solid-query and have a working example for it working here. This is a simple table that gets users from an API and offers buttons to paginate through the table. Give it a spin and let me know if you have questions

https://stackblitz.com/edit/vitejs-vite-nvkeub?file=src%2FTable.tsx

Next Steps:

I will be working on creating the createMutation function next. Again, would love to collaborate with folks in the SolidJS Community.

[sebholstein]

@ardeora thanks for bringing up this discussion about the API surface.

It think it feels intuitive for SolidJS devs that the query key is a function. It was my first thought how a Solid API could look like.
I read a lot about that you shouldn't pass signals directly to components or third party apis, so the function based design would follow that.

Implementation

Regarding the implementation about the query state in createBaseQuery.ts, I think it's a good idea to use a store here, as this leads to fine graned updates.

I think it's useful to discuss other details about the implementation in your repository. We should also create a feature list that is needed to be feature complete and track the state in separate issues. What do you think?

[ardeora]

Hi Sebastian I apologise for the late reply but I agree. These suggestions are really helpful. Yeah I agree passing the query keys as a function would make things easier to develop and help us track reactive keys easily.

I read a lot about that you shouldn't pass signals directly to components or third party apis <- Regarding this. I would appreciate it if you could link resources for this :D I am very interested in learning more about this.

I love the idea of maintaining a feature list and project roadmap. So I have added a issue tracking this milestone over here ardeora/solid-query#2

Thanks,
I'll post my future concerns on that issue

[sebholstein]

I read a lot about that you shouldn't pass signals directly to components or third party apis <- Regarding this. I would appreciate it if you could link resources for this :D I am very interested in learning more about this.

Here's an example/answer from Ryan in a related thread: solidjs/solid#749 (comment)

He also said it a few times in his streams about SolidJS