fix(types): improve useDataQuery types

[Birkbjo]

Key features

1. Add types for the QueryResult based on the Query. So the query-keys are typed on the data object when not passing in a generic type to useDataQuery.
2. Changes QueryResult to be any instead of JsonMap, due to problems with JsonMap. Please refer to this comment for more context.
3. Adds improved type to engine.query, so it follows the same types as useDataQuery.
4. Added an alias for the return type of useDataQuery, because when I first worked with this I was very confused by the QueryRenderInput-name of the result of useDataQuery.
5. Adds Pager type and some related utility types to make it easy to create a Result-type that is paged.

---

Description

Builds on @eirikhaugstulen improvement of adding a generic type for useDataQuery.

---

Checklist

• Have written Documentation
  • If not needed, explain why, otherwise remove this bullet point
• Has tests coverage
  • Only types are changed, so no runtime changes. But I did change some tests to be typed, so it's easier to check that the types work as they should

---

Screenshots

Type-completion on query-keys when not passing in a generic type

[Birkbjo]

Would prefer to rename this to QueryResultData

[Mohammer5]

Could you add some docs with examples?
Although possible, it's takes some time to wrap your head around what a type argument would/should look like.

[Birkbjo]

We could potentially use unknown here instead, but then we are enforcing consumers to type their data. Which could be a breaking change. But because JsonMap-type don't really work anyway (and you had to do the same thing as in screenshot below), I'm all for using unknown if we want to enforce typing the result. any could be "easier" to use, but of course then you lose the types...

If we used unknown you would have to do something like this (which you have to do now anyway with JsonMap:

[Birkbjo]

Wasn't really sure if I should include this in the example. I do think we should either add an option to useQuery for react-query's keepPreviousData. Or preferably just have an reactQueryOptions that we can pass directly... But I do understand the argument if we want to keep the APIs separate, to not rely on react-query if we were to replace it...

However I do think an example like this would be bad without the functionality of "keeping" old data when using pagination - especially since all lists would flicker/be hidden regardless of what "pager" updated, because data will be undefined when fetching... And since it's out of scope for this PR to have an option like that, I opted to include this pretty simple workaround in the example. And we can remove it/update it we decide to implement an option for this.

[nnkogift]

Hello @Birkbjo

I have improvement suggestions if you're still working on this pull request. I think the generic type passed on the useDataQuery hook can be passed down to its refetch function so that its return value can also be typed.