Update all dependencies #446

kjuulh · 2025-02-24T03:12:46+01:00

kjuulh commented

2025-02-24 03:12:46 +01:00

This PR contains the following updates:

Package	Type	Update	Change
@reduxjs/toolkit (source)	dependencies	minor	`2.5.1` -> `2.6.0`
ts-jest (source)	devDependencies	patch	`29.2.5` -> `29.2.6`

Release Notes

reduxjs/redux-toolkit (@reduxjs/toolkit)

`v2.6.0`

Compare Source

This feature release adds infinite query support to RTK Query.

Changelog

RTK Query Infinite Query support

Since we first released RTK Query in 2021, we've had users asking us to add support for "infinite queries" - the ability to keep fetching additional pages of data for a given endpoint. It's been by far our most requested feature. Until recently, our answer was that we felt there were too many use cases to support with a single API design approach.

Last year, we revisited this concept and concluded that the best approach was to mimic the flexible infinite query API design from React Query. We had additional discussions with @tkdodo , who described the rationale and implementation approach and encouraged us to use their API design, and @riqts provided an initial implementation on top of RTKQ's existing internals.

We're excited to announce that this release officially adds full infinite query endpoint support to RTK Query!

Using Infinite Queries

As with React Query, the API design is based around "page param" values that act as the query arguments for fetching a specific page for the given cache entry.

Infinite queries are defined with a new build.infiniteQuery() endpoint type. It accepts all of the same options as normal query endpoints, but also needs an additional infiniteQueryOptions field that specifies the infinite query behaviors. With TypeScript, you must supply 3 generic arguments: build.infiniteQuery<ResultType, QueryArg, PageParam>, where ResultType is the contents of a single page, QueryArg is the type passed in as the cache key, and PageParam is the value used to request a specific page.

The endpoint must define an initialPageParam value that will be used as the default (and can be overridden if desired). It also needs a getNextPageParam callback that will calculate the params for each page based on the existing values, and optionally a getPreviousPageParam callback if reverse fetching is needed. Finally, a maxPages option can be provided to limit the entry cache size.

The query and queryFn methods now receive a {queryArg, pageParam} object, instead of just the queryArg.

For the cache entries and hooks, the data field is now an object like {pages: ResultType[], pageParams: PageParam[]>. This gives you flexibility in how you use the data for rendering.

const pokemonApi = createApi({
  baseQuery: fetchBaseQuery({ baseUrl: 'https://example.com/pokemon' }),
  endpoints: (build) => ({
    // 3 TS generics: page contents, query arg, page param
    getInfinitePokemonWithMax: build.infiniteQuery<Pokemon[], string, number>({
      infiniteQueryOptions: {
        // Must provide a default initial page param value
        initialPageParam: 1,
        // Optionally limit the number of cached pages
        maxPages: 3,
        // Must provide a `getNextPageParam` function
        getNextPageParam: (lastPage, allPages, lastPageParam, allPageParams) =>
          lastPageParam + 1,
        // Optionally provide a `getPreviousPageParam` function
        getPreviousPageParam: (
          firstPage,
          allPages,
          firstPageParam,
          allPageParams,
        ) => {
          return firstPageParam > 0 ? firstPageParam - 1 : undefined
        },
      },
      // The `query` function receives `{queryArg, pageParam}` as its argument
      query({ queryArg, pageParam }) {
        return `/type/${queryArg}?page=${pageParam}`
      },
    }),
  }),
})

As with all RTKQ functionality, the core logic is UI-agnostic and does not require React. However, using the RTKQ React entry point will also auto-generate useInfiniteQuery hooks for these endpoints. Infinite query hooks fetch the initial page, then provide fetchNext/PreviousPage functions to let you trigger requests for more pages.

function PokemonList({
    pokemonType = 'fire',
  }: {
    pokemonType?: string
   ) {
  const {
    data,
    isFetching,
    isSuccess,
    fetchNextPage,
    fetchPreviousPage,
    refetch,
  } = api.useGetInfinitePokemonInfiniteQuery(pokemonType)

  const handlePreviousPage = async () => {
    const res = await fetchPreviousPage()
  }

  const handleNextPage = async () => {
    const res = await fetchNextPage()
  }
  
  // `data` is a `{pages, pageParams}` object.
  // You can use those to render whatever UI you need.
  // In this case, flatten per-page arrays of results for this endpoint
  // into a single array to render a list.
  const allPokemon = data?.pages.flat() ?? [];

  // render UI with pages, show loading state, fetch as needed
}

Docs and Examples

The RTK Query docs have been updated with new content and explanations for infinite queries:

Usage Guides: Infinite Queries covers the new concepts, explains how to define infinite query endpoints and use the hooks, documents fetching behaviors, and describes common API interaction patterns
API Reference: createApi documents the new infinite query endpoint options
Generated API Slices: React Hooks has been updated to better organize the hook descriptions, and covers the infinite query hook arguments and behaviors

We've also added a new infinite query example app in the repo that shows several usage patterns like pagination, cursors, infinite scrolling, and limit+offset queries.

Notes

As with all new features and functionality, more code does mean an increase in bundle size.

We did extensive work to byte-shave and optimize the final bundle size for this feature. Final estimates indicate that this adds about 4.2Kmin to production bundles. That's comparable to React Query's infinite query support size.

However, given RTKQ's current architecture, that bundle size increase is included even if you aren't using any infinite query endpoints in your application. Given the significant additional functionality, that seems like an acceptable tradeoff. (And as always, having this kind of functionality built into RTKQ means that your app benefits when it uses this feature without having to add a lot of additional code to your own app, which would likely be much larger.)

Longer-term, we hope to investigate reworking some of RTKQ's internal architecture to potentially make some of the features opt-in for better bundle size optimizations, but don't have a timeline for that work.

Thanks

This new feature wouldn't have been possible without huge amounts of assistance from several people. We'd like to thank:

@tkdodo of TanStack Query, for happily letting us reuse the API design and implementation approach that they worked hard to figure out, and offering us his advice and knowledge on why they made specific design choices
@riqts , for building the first initial POC draft PR long before we were even ready to begin thinking about this ourselves
@remus-selea and @agusterodin , for trying out various stages of the draft PRs and offering significant detailed feedback and bug reports as I iterated on the implementation

What's Changed

[API Concept] - Infinite Query API by @riqts in https://github.com/reduxjs/redux-toolkit/pull/4393
RTKQ Infinite Query integration by @markerikson in https://github.com/reduxjs/redux-toolkit/pull/4738

and numerous specific sub-PRs that went into that integration PR as I worked through the implementation over the last few months.

Full Changelog: https://github.com/reduxjs/redux-toolkit/compare/v2.5.1...v2.6.0

kulshekhar/ts-jest (ts-jest)

`v29.2.6`

Compare Source

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [@reduxjs/toolkit](https://redux-toolkit.js.org) ([source](https://github.com/reduxjs/redux-toolkit)) | dependencies | minor | [`2.5.1` -> `2.6.0`](https://renovatebot.com/diffs/npm/@reduxjs%2ftoolkit/2.5.1/2.6.0) | | [ts-jest](https://kulshekhar.github.io/ts-jest) ([source](https://github.com/kulshekhar/ts-jest)) | devDependencies | patch | [`29.2.5` -> `29.2.6`](https://renovatebot.com/diffs/npm/ts-jest/29.2.5/29.2.6) | --- ### Release Notes <details> <summary>reduxjs/redux-toolkit (@reduxjs/toolkit)</summary> ### [`v2.6.0`](https://github.com/reduxjs/redux-toolkit/releases/tag/v2.6.0) [Compare Source](https://github.com/reduxjs/redux-toolkit/compare/v2.5.1...v2.6.0) This **feature release** adds infinite query support to RTK Query. #### Changelog ##### RTK Query Infinite Query support Since we [first released RTK Query in 2021](https://github.com/reduxjs/redux-toolkit/releases/v1.6.0), we've had users asking us to add support for "infinite queries" - the ability to keep fetching additional pages of data for a given endpoint. It's been [by far our most requested feature](https://github.com/reduxjs/redux-toolkit/discussions/1163). Until recently, our answer was that [we felt there were too many use cases to support with a single API design approach](https://github.com/reduxjs/redux-toolkit/discussions/1163#discussioncomment-849158). Last year, we revisited this concept and concluded that the best approach was to mimic [the flexible infinite query API design from React Query](https://tanstack.com/query/latest/docs/framework/react/guides/infinite-queries). We had additional discussions with [@tkdodo](https://github.com/tkdodo) , who described the rationale and implementation approach and encouraged us to use their API design, and [@riqts](https://github.com/riqts) provided an initial implementation on top of RTKQ's existing internals. We're excited to announce that **this release officially adds full infinite query endpoint support to RTK Query!** ##### Using Infinite Queries As with React Query, the API design is based around "page param" values that act as the query arguments for fetching a specific page for the given cache entry. Infinite queries are defined with a new `build.infiniteQuery()` endpoint type. It accepts all of the same options as normal query endpoints, but also needs an additional `infiniteQueryOptions` field that specifies the infinite query behaviors. With TypeScript, you must supply 3 generic arguments: `build.infiniteQuery<ResultType, QueryArg, PageParam>`, where `ResultType` is the contents of a single page, `QueryArg` is the type passed in as the cache key, and `PageParam` is the value used to request a specific page. The endpoint must define an `initialPageParam` value that will be used as the default (and can be overridden if desired). It also needs a `getNextPageParam` callback that will calculate the params for each page based on the existing values, and optionally a `getPreviousPageParam` callback if reverse fetching is needed. Finally, a `maxPages` option can be provided to limit the entry cache size. The `query` and `queryFn` methods now receive a `{queryArg, pageParam}` object, instead of just the `queryArg`. For the cache entries and hooks, the `data` field is now an object like `{pages: ResultType[], pageParams: PageParam[]>`. This gives you flexibility in how you use the data for rendering. ```ts const pokemonApi = createApi({ baseQuery: fetchBaseQuery({ baseUrl: 'https://example.com/pokemon' }), endpoints: (build) => ({ // 3 TS generics: page contents, query arg, page param getInfinitePokemonWithMax: build.infiniteQuery<Pokemon[], string, number>({ infiniteQueryOptions: { // Must provide a default initial page param value initialPageParam: 1, // Optionally limit the number of cached pages maxPages: 3, // Must provide a `getNextPageParam` function getNextPageParam: (lastPage, allPages, lastPageParam, allPageParams) => lastPageParam + 1, // Optionally provide a `getPreviousPageParam` function getPreviousPageParam: ( firstPage, allPages, firstPageParam, allPageParams, ) => { return firstPageParam > 0 ? firstPageParam - 1 : undefined }, }, // The `query` function receives `{queryArg, pageParam}` as its argument query({ queryArg, pageParam }) { return `/type/${queryArg}?page=${pageParam}` }, }), }), }) ``` As with all RTKQ functionality, the core logic is UI-agnostic and does not require React. However, using the RTKQ React entry point will also auto-generate `useInfiniteQuery` hooks for these endpoints. Infinite query hooks fetch the initial page, then provide `fetchNext/PreviousPage` functions to let you trigger requests for more pages. ```ts function PokemonList({ pokemonType = 'fire', }: { pokemonType?: string ) { const { data, isFetching, isSuccess, fetchNextPage, fetchPreviousPage, refetch, } = api.useGetInfinitePokemonInfiniteQuery(pokemonType) const handlePreviousPage = async () => { const res = await fetchPreviousPage() } const handleNextPage = async () => { const res = await fetchNextPage() } // `data` is a `{pages, pageParams}` object. // You can use those to render whatever UI you need. // In this case, flatten per-page arrays of results for this endpoint // into a single array to render a list. const allPokemon = data?.pages.flat() ?? []; // render UI with pages, show loading state, fetch as needed } ``` ##### Docs and Examples The RTK Query docs have been updated with new content and explanations for infinite queries: - [Usage Guides: Infinite Queries](https://redux-toolkit.js.org/rtk-query/usage/infinite-queries) covers the new concepts, explains how to define infinite query endpoints and use the hooks, documents fetching behaviors, and describes common API interaction patterns - [API Reference: `createApi`](https://redux-toolkit.js.org/rtk-query/api/createApi) documents the new infinite query endpoint options - [Generated API Slices: React Hooks](https://redux-toolkit.js.org/rtk-query/api/created-api/hooks) has been updated to better organize the hook descriptions, and covers the infinite query hook arguments and behaviors We've also added a new [infinite query example app](https://github.com/reduxjs/redux-toolkit/tree/master/examples/query/react/infinite-queries) in the repo that shows several usage patterns like pagination, cursors, infinite scrolling, and limit+offset queries. ##### Notes As with all new features and functionality, more code does mean an increase in bundle size. We did [extensive work to byte-shave and optimize the final bundle size for this feature](https://github.com/reduxjs/redux-toolkit/pull/4804). Final estimates indicate that this adds about 4.2Kmin to production bundles. That's comparable to React Query's infinite query support size. However, given RTKQ's current architecture, that bundle size increase is included even if you aren't using any infinite query endpoints in your application. Given the significant additional functionality, that seems like an acceptable tradeoff. (And as always, having this kind of functionality built into RTKQ means that your app benefits when it uses this feature without having to add a lot of additional code to your own app, which would likely be much larger.) Longer-term, we hope to investigate reworking some of RTKQ's internal architecture to potentially make some of the features opt-in for better bundle size optimizations, but don't have a timeline for that work. ##### Thanks This new feature wouldn't have been possible without huge amounts of assistance from several people. We'd like to thank: - [@tkdodo](https://github.com/tkdodo) of TanStack Query, for happily letting us reuse the API design and implementation approach that they worked hard to figure out, and offering us his advice and knowledge on why they made specific design choices - [@riqts](https://github.com/riqts) , for [building the first initial POC draft PR](https://github.com/reduxjs/redux-toolkit/pull/4393) long before we were even ready to begin thinking about this ourselves - [@remus-selea](https://github.com/remus-selea) and [@agusterodin](https://github.com/agusterodin) , for trying out various stages of the draft PRs and offering significant detailed feedback and bug reports as I iterated on the implementation #### What's Changed - \[API Concept] - Infinite Query API by [@riqts](https://github.com/riqts) in https://github.com/reduxjs/redux-toolkit/pull/4393 - RTKQ Infinite Query integration by [@markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/4738 and numerous specific sub-PRs that went into that integration PR as I worked through the implementation over the last few months. **Full Changelog**: https://github.com/reduxjs/redux-toolkit/compare/v2.5.1...v2.6.0 </details> <details> <summary>kulshekhar/ts-jest (ts-jest)</summary> ### [`v29.2.6`](https://github.com/kulshekhar/ts-jest/blob/HEAD/CHANGELOG.md#2926-2025-02-22) [Compare Source](https://github.com/kulshekhar/ts-jest/compare/v29.2.5...v29.2.6) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

kjuulh added 1 commit 2025-02-24 03:12:47 +01:00

Update all dependencies

continuous-integration/drone/pr Build is passing

Details

continuous-integration/drone/push Build is passing

Details

eaf09e4f2a

kjuulh merged commit eaf09e4f2a into main

2025-02-24 07:07:51 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kjuulh/vidow#446