Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Resolve QueryKeyManager type errors by allowing nested key trees #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

@kr4chinin
Copy link

@kr4chinin kr4chinin commented Aug 26, 2025

I was hyped about this package but when I first installed it and copy-pasted example from the README.md I've got a lot of type errors, I was not able to find a workaround and decided to research the code.

All issues were looking approximately like this:

Type '(userId: string) => string[]' is not assignable to type 'QueryKeyBuilder<[]>'. Target signature provides too few arguments. Expected 1 or more, but got 0.

Example issues

I was encountering them even when I've installed this initial repo.

So what I've decided to change and why with a small help of Cursor:

  • Allow nested maps

    • Before: create expected a flat Record<string, QueryKeyBuilder>, so { users: { list: ... } } made TS think users must be a function, causing "'list' does not exist in type 'QueryKeyBuilder<[]>'".
    • Now: create accepts a QueryKeyTree (object tree). I added a recursive register that descends into objects and registers any functions it finds. This enables nested namespaces like admin.users.list.
  • Unify stored builder type

    • Before: Registry stored builders with their exact generic types, which made assignability brittle.
    • Now: The registry stores a StoredQueryKeyBuilder of type (...args: unknown[]) => QueryKey. This erases arg specifics for storage, keeping runtime behavior intact while avoiding type incompatibilities.
  • Support any builder arity

    • Before: QueryKeyBuilder defaulted to [] (no args), so single-arg builders failed with "Target signature provides too few arguments."
    • Now: QueryKeyBuilder defaults to unknown[], so builders with any number/types of args are assignable without casts.

We can now define flat or nested key maps with builders of any arity, and TS no longer complains about unknown properties or argument count mismatches.

Also I've change all any to unknown for more semantic typisation.

piotr-m-jurek and techwithmanuel reacted with heart emoji
Copy link
Owner

Thanks so much for raising this and opening the pull request, @kr4chinin! I had already resolved the issue by the time I saw it, and some new features have been added since

I really appreciate the effort you put in and would love to see more of your contributions in the future

kr4chinin reacted with rocket emoji

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AltStyle によって変換されたページ (->オリジナル) /