Support for a more destructable query keys

[Jazzmanpw]

Hello!

This article from TkDodo's blog proposes a very convenient structure for query keys: they are arrays, they have only a single element and all the data, including some high-level strings for scope and entity, are stored in it. The huge profit is that you don't have to write these commas when you desctructure the key.

// this is your key
const queryKey = ['todos', 'list', {sort: 'name'}];
const [, , {sort: 'name'}] = queryKey;
// this is TkDodo's key
const queryKey = [{scope: 'todos', entity: 'list', sort: 'name'}];
const [{sort: 'name'}] = queryKey;

On the one hand, it may be more restricting. On the other hand, it may enforce the users to follow the good practice. If you don't want to make it a must, there could be an option or alternative factories that use the second structure. It will require a lot of different types, I guess, so I don't know what's the best way to go. I'm interested in your opinion on that, thanks!

[lukemorales]

Hey, @Jazzmanpw thanks for the suggestion!

While I understand where the request comes from, I'm not sure if I want the lib to go that path because it would make it strongly opinionated on how users should define their query keys (in this case, always an object). Also, the benefits of typescript make it very clear about the index the information lives on, and honestly, the following isn't that bad:

const {sort: 'name'} = queryKey[2];

I'm currently working on the v1.0 of this lib, mainly focusing on adding support for nested keys (ex: you can add keys for a specific user account), how would scope be translated when you have multiple nested scopes? scope2? subScope, subScope2? On one side, it's easier to destruct the query key right on the first index, on the other, scaling and adding new features to the lib might become more painful. I'm just dropping some thoughts here though, don't take any of this as an official decision for your request.

Also for v1.0, I'm trying to implement an API that supports this pattern that TkDodo introduces in his recent posts for React Router:

And honestly, the convenience of this API would make it pretty unnecessary to have to destruct the query key anywhere.

I'll keep the issue open and consider it for the future, but it's not a priority right now

[TommySorensen]

@lukemorales Sounds great with v1. FYI: it seems like that with v5 of query you might always will need to use the queryKey and queryFn. See more here https://github.com/TanStack/query/discussions/4252

[lukemorales]

@lukemorales Sounds great with v1. FYI: it seems like that with v5 of query you might always will need to use the queryKey and queryFn. See more here TanStack/query#4252

Thanks for bringing more context on v5 for this thread @TommySorensen! I'm up to date with that proposal, and actually, that roadmap delayed the release of v1 a bit. The pattern I presented in my last comment was being introduced as a bonus in the package, but now that there will be no overloads anymore and the object syntax is going to be the default, I'm changing it to be a first-class citizen so I'm rethinking the API a little bit in order to provide a great DX

[aulneau]

just coming in to say love the library and would love for the queryKey passed to the queryFn via the context be strongly typed

[lukemorales]

just coming in to say love the library and would love for the queryKey passed to the queryFn via the context be strongly typed

Thanks for the feedback @aulneau! I also with that queryKey would be typed in the queryFn context declaration but still need to figure out how do that without breaking the current inference.