TypeScript shows `hasNextPage` is always false from an infiniteQuery hook

[colinsullivan]

Should this type be a boolean instead of false ? Or am I missing something about how to set this up properly ?

redux-toolkit/packages/toolkit/src/query/react/buildHooks.ts

Line 1241 in af3e75b

hasNextPage: false

Looks like at runtime it is a boolean

redux-toolkit/packages/toolkit/src/query/core/buildSelectors.ts

Line 291 in af3e75b

hasNextPage: getHasNextPage(

[markerikson]

That's the baseline "values when uninitialized" definition, so hasNextPage: false is accurate there.

We may be missing grabbing those fields in some of the TS overrides later, though.

[colinsullivan]

That's the baseline "values when uninitialized" definition, so hasNextPage: false is accurate there.

We may be missing grabbing those fields in some of the TS overrides later, though.

I understand the TS override strategy helps TS have accurate types during the request lifecycle.

e.g.

if ( result.isError ) {
  // do stuff with nice type benefits
}

Since hasNextPage doesn't depend on the request lifecycle, it depends on the contents of the response, I think it is safe to make it a boolean always. Consumers of this API will obviously understand that hasNextPage is a boolean, depending on the response structure , it is not expected to change until the response is parsed and thus there is no benefit to type ever changing.

In other words, there is no reason to fork code based on the type being false. The code will always be:

if ( result.hasNextPage ) {
   // do stuff
}

Currently this raises a type error, which is weird ^^

In theory there is no corresponding pattern in useQuery because none of those properties depend on the contents of the response.

redux-toolkit/packages/toolkit/src/query/react/buildHooks.ts

Line 714 in af3e75b

isFetching: false

Just my 2c: It can be a boolean from the start and case closed...