feat(query): use provideQuery to provide custom Query

[Dji75]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/ngneat/query/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Issue Number: #212

What is the new behavior?

A dedicated InjectionToken has been created in order to provide Query class instead using @Injectable({ providedIn: 'root' }) at class level.
Then, the function provideQuery have been also created in order to be able to override it.

Does this PR introduce a breaking change?

• Yes
• No

Other information

N/A

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[luii]

LGTM

@NetanelBasal at that point wouldn't it be wise to also include a provider for Mutation, IsMutating, IsFetching and InfiniteQuery? Maybe we could also bundle them under a umbrella provide function with the mentioned fields marked as optional.

[luii]

@Dji75 Would you please add some documentation for that in the README.md

[NetanelBasal]

@luii makes sense

[Dji75]

@NetanelBasal @luii Query and some interfaces are not exported yet but I think it make sense in order to extend it:

import { DefinedInitialDataOptions, provideQuery, Query, Result } from '@ngneat/query';
import { DefaultError, DefinedQueryObserverResult, QueryKey, QueryObserverResult } from '@tanstack/query-core';


export class CustomQuery extends Query {
  override use<TQueryFnData = unknown, TError = DefaultError, TData = TQueryFnData, TQueryKey extends QueryKey = QueryKey>(
    options: DefinedInitialDataOptions<TQueryFnData, TError, TData, TQueryKey>
  ): Result<DefinedQueryObserverResult<TData, TError>> {
    // do your own specific stuff
    return super.use(options);
  }
}


provideQuery(() =>  new CustomQuery()) // or provideQuery(new CustomQuery())

What do you think ?

[luii]

What is the purpose of this class @Dji75 ?

If you have the time could you also implement, what you initially committed here, also for Mutation, IsMutating, IsFetching and InfiniteQuery ? Maybe we can implement that under just one provider function, something like that

provideQueryConfig({
  query: queryMock,
  mutation: mutationMock,
  isMutating: isMutatingMock,
  isFetching: isFetchingMock,
  infiniteQuery: infiniteQueryMock
});

@Dji75 All of these properties would be optional of course and use a default factory, like you already did in you commit
@NetanelBasal any suggestions about these implementation details?

[NetanelBasal]

LGTM

[Dji75]

I would purpose to merge all provideXXX functions into single one provideQueryConfig.

If you don't want to a a breaking change, I can keep the other ones and mark them as deprecated (or do not merge them at all)

provideQueryConfig({
  client: clientMock,
  clientOptions: clientOptionsMock,
  query: queryMock,
  queryOptions: queryOptionsMock,
  mutation: mutationMock,
  isMutating: isMutatingMock,
  isFetching: isFetchingMock,
  infiniteQuery: infiniteQueryMock
});

I guess I have to create dedicated interfaces for Query class (containing use function) and Query Options (alias for DefinedInitialDataOptions | UndefinedInitialDataOptions)

I didn't checked if it will be easy at all, but let me know if you think it is a good idea :)

P.S : I will probably do it next week.

[Dji75]

@luii after your question on this, I think you're right, there is no real interest, so I rolled back that point ;)

Now, regarding query config, I'll proceed for all properties except probably query options: it looks too tricky for me to refactor the whole library :)

[Dji75]

I did it for Query, Mutation, IsMutating, IsFetching and InfiniteQuery objects for the moment.

I updated documentation accordingly, let me know if you find it clear

[Dji75]

I don't think I'll go any further on this.

@luii any feedback ? :)

[luii]

Why do you use any here? Is there a reason for it?

[luii]

Otherwise it looks good, if the test are working and if @netbasal has no objections we can merge it

[NetanelBasal]

Why any?

[Dji75]

any because of createBaseQuery return type

[NetanelBasal]

the types are still works as expected?

[Dji75]

types are stricly identical as previously, I've just exported them in dedicated interfaces

[Dji75]

I introduced an incorrect import in query.spec.ts which introduced a lint issus (from @ngneat/query) instead of local file), I had to push force the fix :)