Feature Request: Enhance `injectQuery` to Accept an Options Object
Which @ngneat/query-* package(s) are relevant/releated to the feature request?
query
Description
Description
Currently, the injectQuery function does not accept an options object directly. This feature would enhance the usability and flexibility of the function, making it more intuitive and powerful for developers.
Current Implementation
class MyComponent {
#query = injectQuery();
getTodos() {
return this.#query({
queryKey: ['todos'] as const,
queryFn: () => {
return this.#http.get<Todo[]>('https://jsonplaceholder.typicode.com/todos');
},
});
}
}
Proposed Change
Modify the injectQuery function to accept an options object, allowing for more streamlined and readable code. The new usage would be similar to this:
import { injectQuery } from '@tanstack/angular-query-experimental';
...
class MyComponent {
#query = injectQuery({
queryKey: ['todos'] as const,
queryFn: () => {
return this.#http.get<Todo[]>('https://jsonplaceholder.typicode.com/todos');
},
});
}
}
Benefits
- Consistency: Aligns with other common practices of passing an options object in similar libraries.
- Readability: Enhances code readability and maintainability.
- Flexibility: Allows for easier configuration and extension of queries.
Thank you for considering this enhancement!
I love this feature idea!
@NetanelBasal, @luii, would you like me to submit a PR?
Hi @wizardnet972, @NetanelBasal, @luii — just following up on this feature request. Is there any update on whether this enhancement can be considered or if a PR would be welcome? Let me know if there's anything I can assist with. Thanks!
Everyone is welcome to provide a PR for this Issue, it's already open for a long time now and if there would be things to reconsider, i believe Netanel would have said something, i would say we can safely implement this.
I would suggest to keep the backwards-compatibility and make injectQuery() accept a optional factory that returns the options object. The current implementation requires us to inject the base query first and then create a new query from it, so as long as the proposal from above is backwards-compatible i dont see a problem here.