Conflict Resolved

Author: sriram-palanisamy-hat

.github/workflows/tests.yml

@@ -114,14 +114,21 @@ jobs:
       - name: Erase path aliases
         run: sed -i -e /@remap-prod-remove-line/d ./tsconfig.base.json
 
-      - name: Run tests, against dist
-        env:
-          TEST_DIST: true
-        run: yarn test
-
       - name: Run type tests with `moduleResolution Bundler`
         run: rm -rf dist && yarn tsc -p . --moduleResolution Bundler --module ESNext --noEmit false --declaration --emitDeclarationOnly --outDir dist --target ESNext && rm -rf dist
 
+      - name: Ensure there's no dist folder
+        run: rm -rf dist
+
+      - name: Change RTK package name to ensure node_modules is used
+        run: sed -i -e 's|@reduxjs/toolkit|@reduxjs/toolkit-test|' ./package.json
+
+      - name: Run tests, against installed artifact
+        env:
+          TEST_DIST: true
+        working-directory: ./packages/toolkit
+        run: ../../node_modules/.bin/vitest --run --typecheck
+
   test-types:
     name: 'Test Types: TS ${{ matrix.ts }} and React ${{ matrix.react.version }}'
 
@@ -241,12 +248,13 @@ jobs:
       - name: Show installed RTK versions
         run: yarn info @reduxjs/toolkit && yarn why @reduxjs/toolkit
 
-      - name: Set up JDK 17 for React Native build
+      - name: Set up JDK 21 for React Native build
         if: matrix.example == 'react-native' || matrix.example == 'expo'
         uses: actions/setup-java@v4
         with:
-          java-version: '17.x'
+          java-version: '21.x'
           distribution: 'temurin'
+          cache: 'gradle'
 
       - name: Build example
         env:

docs/api/createEntityAdapter.mdx

@@ -377,6 +377,8 @@ If `updateMany()` is called with multiple updates targeted to the same ID, they
 
 For both `updateOne()` and `updateMany()`, changing the ID of one existing entity to match the ID of a second existing entity will cause the first to replace the second completely.
 
+Additionally, if there is no item for that ID, the update will be silently ignored.
+
 ## Examples
 
 Exercising several of the CRUD methods and selectors:

docs/rtk-query/api/createApi.mdx

@@ -153,6 +153,32 @@ Query endpoints (defined with `build.query()`) are used to cache data fetched fr
 You must specify either a `query` field (which will use the API's `baseQuery` to make a request), or a `queryFn` function with your own async logic. All other fields are optional.
 
 ```ts title="Query endpoint definition" no-transpile
+export type FullTagDescription<TagType> = {
+  type: TagType
+  id?: number | string
+}
+export type TagDescription<TagType> = TagType | FullTagDescription<TagType>
+
+type TagDescriptionArray<TagTypes extends string> = ReadonlyArray<
+  TagDescription<TagTypes> | undefined | null
+>
+
+export type ResultDescription<
+  TagTypes extends string,
+  ResultType,
+  QueryArg,
+  ErrorType,
+  MetaType,
+> =
+  | TagDescriptionArray<TagTypes>
+  | (
+  result: ResultType | undefined,
+  error: ErrorType | undefined,
+  arg: QueryArg,
+  meta: MetaType,
+) => TagDescriptionArray<TagTypes>
+
+
 export type QueryDefinition<
   QueryArg,
   BaseQuery extends BaseQueryFn,
@@ -245,11 +271,12 @@ Infinite query endpoints (defined with `build.infiniteQuery()`) are used to cach
 For infinite query endpoints, there is a separation between the "query arg" used for the cache key, and the "page param" used to fetch a specific page. For example, a Pokemon API endpoint might have a string query arg like `"fire"` , but use a page number as the param to determine which page to fetch out of the results. The `query` and `queryFn` methods will receive a combined `{queryArg, pageParam}` object as the argument, rather than just the `queryArg` by itself.
 
 ```ts title="Infinite Query endpoint definition" no-transpile
-export type PageParamFunction<DataType, PageParam> = (
+export type PageParamFunction<DataType, PageParam, QueryArg> = (
   firstPage: DataType,
   allPages: Array<DataType>,
   firstPageParam: PageParam,
   allPageParams: Array<PageParam>,
+  queryArg: QueryArg,
 ) => PageParam | undefined | null
 
 type InfiniteQueryCombinedArg<QueryArg, PageParam> = {
@@ -290,12 +317,12 @@ export type InfiniteQueryDefinition<
        * This function is required to automatically get the next cursor for infinite queries.
        * The result will also be used to determine the value of `hasNextPage`.
        */
-      getNextPageParam: PageParamFunction<DataType, PageParam>
+      getNextPageParam: PageParamFunction<DataType, PageParam, QueryArg>
       /**
        * This function can be set to automatically get the previous cursor for infinite queries.
        * The result will also be used to determine the value of `hasPreviousPage`.
        */
-      getPreviousPageParam?: PageParamFunction<DataType, PageParam>
+      getPreviousPageParam?: PageParamFunction<DataType, PageParam, QueryArg>
       /**
        * If specified, only keep this many pages in cache at once.
        * If additional pages are fetched, older pages in the other

docs/rtk-query/usage/code-splitting.mdx

@@ -10,11 +10,17 @@ description: 'RTK Query > Usage > Code Splitting: dynamic injection of endpoints
 
 # Code Splitting
 
-RTK Query makes it possible to trim down your initial bundle size by allowing you to inject additional endpoints after you've set up your initial service definition. This can be very beneficial for larger applications that may have _many_ endpoints.
+## Overview
 
-`injectEndpoints` accepts a collection of endpoints, as well as an optional `overrideExisting` parameter.
+By default, an RTK Query API definition normally has all of the endpoint definitions in a single file. However, in larger applications this can result in very large files that may be harder to maintain. It also means that all of the relevant code is being imported right away.
 
-Calling `injectEndpoints` will inject the endpoints into the original API, but also give you that same API with correct types for these endpoints back. (Unfortunately, it cannot modify the types for the original definition.)
+RTK Query allows dynamically injecting endpoint definitions into an existing API service object. This enables splitting up endpoints into multiple files for maintainability, as well as lazy-loading endpoint definitions and associated code to trim down initial bundle sizes. This can be very beneficial for larger applications that may have _many_ endpoints.
+
+## Injecting Endpoints
+
+`api.injectEndpoints` accepts a collection of endpoint definitions (same as `createApi`), as well as an optional `overrideExisting` parameter.
+
+Calling `api.injectEndpoints` will inject the endpoints into the original API service object, modifying it immediately. It returns **the _same_ API service object reference**. If you're using TypeScript, the return value has the TS types for the new endpoints included. (Unfortunately, it cannot modify the types for the original API reference.)
 
 A typical approach would be to have one empty central API slice definition:
 
@@ -43,6 +49,7 @@ export const emptySplitApi = createApi({
 // file: extendedApi.ts
 import { emptySplitApi } from './emptySplitApi'
 
+// NOTE: these are the _SAME_ API reference!
 const extendedApi = emptySplitApi.injectEndpoints({
   endpoints: (build) => ({
     example: build.query({
@@ -60,3 +67,59 @@ If you inject an endpoint that already exists and don't explicitly specify `over
 will not be overridden. In development mode, you will get a warning about this if `overrideExisting` is set to `false`,
 and an error will be throw if set to `'throw'`.
 :::
+
+## Enhancing Endpoints
+
+Sometimes you may also need to modify an existing API definition, such as adding additional tag types, or providing additional configuration options to a given endpoint.
+
+`api.enhanceEndpoints` returns an updated and enhanced version of the API slice object, containing the combined endpoint definitions.
+
+This is primarily useful for taking an API slice object that was code-generated from an API schema file like OpenAPI, and adding additional specific hand-written configuration for cache invalidation management on top of the generated endpoint definitions.
+
+For example, `enhanceEndpoints` can be used to modify caching behavior by changing the values of `providesTags`, `invalidatesTags`, and `keepUnusedDataFor`:
+
+```ts
+// file: api.ts noEmit
+import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react'
+
+export const api = createApi({
+  baseQuery: fetchBaseQuery({ baseUrl: '/' }),
+  endpoints: (build) => ({
+    getUserByUserId: build.query({
+      query() {
+        return ''
+      },
+    }),
+    patchUserByUserId: build.mutation({
+      query() {
+        return ''
+      },
+    }),
+    getUsers: build.query({
+      query() {
+        return ''
+      },
+    }),
+  }),
+})
+
+// file: enhanceEndpoints.ts
+import { api } from './api'
+
+const enhancedApi = api.enhanceEndpoints({
+  addTagTypes: ['User'],
+  endpoints: {
+    getUserByUserId: {
+      providesTags: ['User'],
+    },
+    patchUserByUserId: {
+      invalidatesTags: ['User'],
+    },
+    // alternatively, define a function which is called with the endpoint definition as an argument
+    getUsers(endpoint) {
+      endpoint.providesTags = ['User']
+      endpoint.keepUnusedDataFor = 120
+    },
+  },
+})
+```

docs/rtk-query/usage/infinite-queries.mdx

@@ -82,11 +82,12 @@ ensure the infinite query can properly fetch the next page of data. Also, `initi
 `getNextPageParam` and `getPreviousPageParam` are user-defined, giving you flexibility to determine how those values are calculated:
 
 ```ts
-export type PageParamFunction<DataType, PageParam> = (
+export type PageParamFunction<DataType, PageParam, QueryArg> = (
   currentPage: DataType,
   allPages: DataType[],
   currentPageParam: PageParam,
   allPageParams: PageParam[],
+  queryArg: QueryArg,
 ) => PageParam | undefined | null
 ```
 
@@ -96,6 +97,8 @@ Since both actual page contents and page params are passed in, you can calculate
 
 The "current" arguments will be either the last page for `getNextPageParam`, or the first page for `getPreviousPageParam`.
 
+The list of arguments is the same as with React Query, but with the addition of `queryArg` at the end. (This is because React Query always has access to the query arg when you pass the options to its `useQuery` hook, but with RTK Query the endpoints are defined separately, so this makes the query arg accessible if you need it to calculate the page params.)
+
 If there is no possible page to fetch in that direction, the callback should return `undefined`.
 
 ### Infinite Query Definition Example
@@ -119,14 +122,20 @@ const pokemonApi = createApi({
         // Optionally limit the number of cached pages
         maxPages: 3,
         // Must provide a `getNextPageParam` function
-        getNextPageParam: (lastPage, allPages, lastPageParam, allPageParams) =>
-          lastPageParam + 1,
+        getNextPageParam: (
+          lastPage,
+          allPages,
+          lastPageParam,
+          allPageParams,
+          queryArg,
+        ) => lastPageParam + 1,
         // Optionally provide a `getPreviousPageParam` function
         getPreviousPageParam: (
           firstPage,
           allPages,
           firstPageParam,
           allPageParams,
+          queryArg,
         ) => {
           return firstPageParam > 0 ? firstPageParam - 1 : undefined
         },

docs/usage/nextjs.mdx

@@ -280,7 +280,7 @@ export default function StoreProvider({
 
 If you use Next.js's support for client side SPA-style navigation by using `next/navigation`, then when customers navigate from page to page only the route component will be re-rendered. This means that if you have a Redux store created and provided in the layout component it will be preserved across route changes. This is not a problem if you are only using the store for global, mutable data. However, if you are using the store for per-route data then you will need to reset the route-specific data in the store when the route changes.
 
-Shown below is a `ProductName` example component that uses the Redux store to manage the mutable name of a product. The `ProductName` component part of a product detail route. In order to ensure that we have the correct name in the store we need to set the value in the store any time the `ProductName` component is initially rendered, which happens on any route change to the product detail route.
+Shown below is a `ProductName` example component that uses the Redux store to manage the mutable name of a product. The `ProductName` component is part of a product detail route. In order to ensure that we have the correct name in the store we need to set the value in the store any time the `ProductName` component is initially rendered, which happens on any route change to the product detail route.
 
 ```ts title="app/ProductName.tsx"
 // file: lib/features/product/productSlice.ts noEmit

examples/publish-ci/expo/.eslintrc.json

@@ -2,12 +2,13 @@
 
 # dependencies
 node_modules/
-.yarn/
 
 # Expo
 .expo/
 dist/
 web-build/
+expo-env.d.ts
+build/
 
 # Native
 *.orig.*
@@ -16,8 +17,8 @@ web-build/
 *.p12
 *.key
 *.mobileprovision
-android
-ios
+android/
+ios/
 
 # Metro
 .metro-health-check*
@@ -36,3 +37,20 @@ yarn-error.*
 
 # typescript
 *.tsbuildinfo
+
+# testing
+/coverage
+
+# Yarn
+.yarn/*
+!.yarn/patches
+!.yarn/plugins
+!.yarn/releases
+!.yarn/sdks
+!.yarn/versions
+
+# IDE
+.vscode
+
+.yalc/
+yalc.lock

examples/publish-ci/expo/.gitignore

@@ -1,6 +1,5 @@
 {
   "arrowParens": "avoid",
-  "bracketSameLine": true,
-  "singleQuote": true,
-  "trailingComma": "all"
+  "semi": false,
+  "singleQuote": true
 }