Merge branch 'master' into feature/v1.6-integration

Author: markerikson

.github/FUNDING.yml

@@ -0,0 +1 @@
+github: [phryneas]

README.md

@@ -18,6 +18,13 @@ The recommended way to start new apps with React and Redux Toolkit is by using t
 npx create-react-app my-app --template redux
 ```
 
+Or if you are a TypeScript user, use [cra-template-redux-typescript](https://github.com/reduxjs/cra-template-redux-typescript), which is based on that template
+
+```sh
+npx create-react-app my-app --template redux-typescript
+```
+
+
 ### An Existing App
 
 Redux Toolkit is available as a package on NPM for use with a module bundler or in a Node application:

docs/api/createEntityAdapter.mdx

@@ -208,6 +208,7 @@ The primary content of an entity adapter is a set of generated reducer functions
 - `setAll`: accepts an array of entities or an object in the shape of `Record<EntityId, T>`, and replaces the existing entity contents with the values in the array.
 - `removeOne`: accepts a single entity ID value, and removes the entity with that ID if it exists.
 - `removeMany`: accepts an array of entity ID values, and removes each entity with those IDs if they exist.
+- `removeAll`: removes all entities from the entity state object.
 - `updateOne`: accepts an "update object" containing an entity ID and an object containing one or more new field values to update inside a `changes` field, and performs a shallow update on the corresponding entity.
 - `updateMany`: accepts an array of update objects, and performs shallow updates on all corresponding entities.
 - `upsertOne`: accepts a single entity. If an entity with that ID exists, it will perform a shallow update and the specified fields will be merged into the existing entity, with any matching fields overwriting the existing values. If the entity does not exist, it will be added.

docs/api/serializabilityMiddleware.mdx

@@ -55,6 +55,11 @@ interface SerializableStateInvariantMiddlewareOptions {
    * Defaults to 32ms.
    */
   warnAfter?: number
+
+  /**
+   * Opt out of checking state, but continue checking actions
+   */
+  ignoreState?: boolean
 }
 ```
 

docs/introduction/getting-started.md

@@ -49,7 +49,11 @@ Redux Toolkit is available as a package on NPM for use with a module bundler or
 ```bash
 # NPM
 npm install @reduxjs/toolkit
+```
+
+or
 
+```bash
 # Yarn
 yarn add @reduxjs/toolkit
 ```

docs/tutorials/quick-start.md

@@ -143,10 +143,9 @@ export default configureStore({
 Now we can use the React-Redux hooks to let React components interact with the Redux store. We can read data from the store with `useSelector`, and dispatch actions using `useDispatch`. Create a `src/features/counter/Counter.js` file with a `<Counter>` component inside, then import that component into `App.js` and render it inside of `<App>`.
 
 ```jsx title="features/counter/Counter.js"
-import React, { useState } from 'react'
+import React from 'react'
 import { useSelector, useDispatch } from 'react-redux'
 import { decrement, increment } from './counterSlice'
-import styles from './Counter.module.css'
 
 export function Counter() {
   const count = useSelector((state) => state.counter.value)

docs/tutorials/typescript.md

@@ -49,7 +49,7 @@ Since those are types, it's safe to export them directly from your store setup f
 import { configureStore } from '@reduxjs/toolkit'
 // ...
 
-const store = configureStore({
+export const store = configureStore({
   reducer: {
     posts: postsReducer,
     comments: commentsReducer,
@@ -67,7 +67,7 @@ export type AppDispatch = typeof store.dispatch
 
 ### Define Typed Hooks
 
-While it's possible to import the `RootState` and `AppDispatch` types into each component, it's **better to create typed versions of the `useDispatch` and `useSelector` hooks for usage in your application**. . This is important for a couple reasons:
+While it's possible to import the `RootState` and `AppDispatch` types into each component, it's **better to create typed versions of the `useDispatch` and `useSelector` hooks for usage in your application**. This is important for a couple reasons:
 
 - For `useSelector`, it saves you the need to type `(state: RootState)` every time
 - For `useDispatch`, the default `Dispatch` type does not know about thunks. In order to correctly dispatch thunks, you need to use the specific customized `AppDispatch` type from the store that includes the thunk middleware types, and use that with `useDispatch`. Adding a pre-typed `useDispatch` hook keeps you from forgetting to import `AppDispatch` where it's needed.

docs/usage/usage-guide.md

@@ -26,7 +26,7 @@ Every Redux app needs to configure and create a Redux store. This usually involv
 - Importing or creating the root reducer function
 - Setting up middleware, likely including at least one middleware to handle asynchronous logic
 - Configuring the [Redux DevTools Extension](https://github.com/zalmoxisus/redux-devtools-extension)
-- Possibly altering some of the logic based on whether the application is being built for development or production.
+- Possibly altering some of the logic based on whether the application is being built for development or production
 
 ### Manual Store Setup
 
@@ -68,7 +68,7 @@ This example is readable, but the process isn't always straightforward:
 
 `configureStore` helps with those issues by:
 
-- Having an options object with "named" parameters, which can be easier to read.
+- Having an options object with "named" parameters, which can be easier to read
 - Letting you provide arrays of middleware and enhancers you want to add to the store, and calling `applyMiddleware` and `compose` for you automatically
 - Enabling the Redux DevTools Extension automatically
 
@@ -95,6 +95,8 @@ export default store
 You can also pass an object full of ["slice reducers"](https://redux.js.org/recipes/structuring-reducers/splitting-reducer-logic), and `configureStore` will call [`combineReducers`](https://redux.js.org/api/combinereducers) for you:
 
 ```js
+import { configureStore } from '@reduxjs/toolkit'
+// highlight-start
 import usersReducer from './usersReducer'
 import postsReducer from './postsReducer'
 
@@ -104,6 +106,9 @@ const store = configureStore({
     posts: postsReducer,
   },
 })
+// highlight-end
+
+export default store
 ```
 
 Note that this only works for one level of reducers. If you want to nest reducers, you'll need to call `combineReducers` yourself to handle the nesting.
@@ -141,7 +146,7 @@ If you provide the `middleware` argument, `configureStore` will only use whateve
 [Reducers](https://redux.js.org/basics/reducers) are the most important Redux concept. A typical reducer function needs to:
 
 - Look at the `type` field of the action object to see how it should respond
-- Update its state immutably, by making copies of the parts of the state that need to change and only modifying those copies.
+- Update its state immutably, by making copies of the parts of the state that need to change and only modifying those copies
 
 While you can [use any conditional logic you want](https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/#switch-statements) in a reducer, the most common approach is a `switch` statement, because it's a straightforward way to handle multiple possible values for a single field. However, many people don't like switch statements. The Redux docs show an example of [writing a function that acts as a lookup table based on action types](https://redux.js.org/recipes/reducing-boilerplate#generating-reducers), but leave it up to users to customize that function themselves.
 
@@ -382,8 +387,8 @@ export default function postsReducer(state = initialState, action) {
 
 The only truly necessary part here is the reducer itself. Consider the other parts:
 
-- We could have written the action types as inline strings in both places.
-- The action creators are good, but they're not _required_ to use Redux - a component could skip supplying a `mapDispatch` argument to `connect`, and just call `this.props.dispatch({type : "CREATE_POST", payload : {id : 123, title : "Hello World"}})` itself.
+- We could have written the action types as inline strings in both places
+- The action creators are good, but they're not _required_ to use Redux - a component could skip supplying a `mapDispatch` argument to `connect`, and just call `this.props.dispatch({type : "CREATE_POST", payload : {id : 123, title : "Hello World"}})` itself
 - The only reason we're even writing multiple files is because it's common to separate code by what it does
 
 The ["ducks" file structure](https://github.com/erikras/ducks-modular-redux) proposes putting all of your Redux-related logic for a given slice into a single file, like this:
@@ -479,23 +484,6 @@ console.log(createPost({ id: 123, title: 'Hello World' }))
 
 `createSlice` looked at all of the functions that were defined in the `reducers` field, and for every "case reducer" function provided, generates an action creator that uses the name of the reducer as the action type itself. So, the `createPost` reducer became an action type of `"posts/createPost"`, and the `createPost()` action creator will return an action with that type.
 
-```js
-const postsSlice = createSlice({
-  name: 'posts',
-  initialState: [],
-  reducers: {
-    createPost(state, action) {},
-    updatePost(state, action) {},
-    deletePost(state, action) {},
-  },
-})
-
-const { createPost } = postsSlice.actions
-
-console.log(createPost({ id: 123, title: 'Hello World' }))
-// {type : "posts/createPost", payload : {id : 123, title : "Hello World"}}
-```
-
 ### Exporting and Using Slices
 
 Most of the time, you'll want to define a slice, and export its action creators and reducers. The recommended way to do this is using ES6 destructuring and export syntax:
@@ -613,7 +601,7 @@ const fetchUsers = () => async (dispatch) => {
 
 Data fetching logic for Redux typically follows a predictable pattern:
 
-- A "start" action is dispatched before the request, to indicate that the request is in progress. This may be used to track loading state to allow skipping duplicate requests or show loading indicators in the UI.
+- A "start" action is dispatched before the request to indicate that the request is in progress. This may be used to track loading state, to allow skipping duplicate requests, or show loading indicators in the UI.
 - The async request is made
 - Depending on the request result, the async logic dispatches either a "success" action containing the result data, or a "failure" action containing error details. The reducer logic clears the loading state in both cases, and either processes the result data from the success case, or stores the error value for potential display.
 
@@ -1034,7 +1022,7 @@ One of the core usage principles for Redux is that [you should not put non-seria
 
 However, like most rules, there are exceptions. There may be occasions when you have to deal with actions that need to accept non-serializable data. This should be done very rarely and only if necessary, and these non-serializable payloads shouldn't ever make it into your application state through a reducer.
 
-The [serializability dev check middleware](../api/getDefaultMiddleware.mdx) will automatically warn anytime it detects non-serializable values in your actions or state. We encourage you to leave this middleware active to help avoid accidentally making mistakes. However, if you _do_ need to turnoff those warnings, you can customize the middleware by configuring it to ignore specific action types, or fields in actions and state:
+The [serializability dev check middleware](../api/serializabilityMiddleware.mdx) will automatically warn anytime it detects non-serializable values in your actions or state. We encourage you to leave this middleware active to help avoid accidentally making mistakes. However, if you _do_ need to turnoff those warnings, you can customize the middleware by configuring it to ignore specific action types, or fields in actions and state:
 
 ```js
 configureStore({

docs/usage/usage-with-typescript.md

@@ -38,10 +38,12 @@ The basics of using `configureStore` are shown in [TypeScript Quick Start tutori
 The easiest way of getting the `State` type is to define the root reducer in advance and extract its `ReturnType`.  
 It is recommend to give the type a different name like `RootState` to prevent confusion, as the type name `State` is usually overused.
 
-```typescript {3}
+```typescript
 import { combineReducers } from '@reduxjs/toolkit'
 const rootReducer = combineReducers({})
+// highlight-start
 export type RootState = ReturnType<typeof rootReducer>
+// highlight-end
 ```
 
 Alternatively, if you choose to not create a `rootReducer` yourself and instead pass the slice reducers directly to `configureStore()`, you need to slightly modify the typing to correctly infer the root reducer:
@@ -56,13 +58,15 @@ const store = configureStore({
   },
 })
 export type RootState = ReturnType<typeof store.getState>
+
+export default store
 ```
 
 ### Getting the `Dispatch` type
 
 If you want to get the `Dispatch` type from your store, you can extract it after creating the store. It is recommended to give the type a different name like `AppDispatch` to prevent confusion, as the type name `Dispatch` is usually overused. You may also find it to be more convenient to export a hook like `useAppDispatch` shown below, then using it wherever you'd call `useDispatch`.
 
-```typescript {6}
+```typescript
 import { configureStore } from '@reduxjs/toolkit'
 import { useDispatch } from 'react-redux'
 import rootReducer from './rootReducer'
@@ -71,8 +75,12 @@ const store = configureStore({
   reducer: rootReducer,
 })
 
+// highlight-start
 export type AppDispatch = typeof store.dispatch
 export const useAppDispatch = () => useDispatch<AppDispatch>() // Export a hook that can be reused to resolve types
+// highlight-end
+
+export default store
 ```
 
 ### Correct typings for the `Dispatch` type
@@ -83,17 +91,18 @@ As TypeScript often widens array types when combining arrays using the spread op
 
 Also, we suggest using the callback notation for the `middleware` option to get a correctly pre-typed version of `getDefaultMiddleware` that does not require you to specify any generics by hand.
 
-```ts {10-20}
+```ts
 import { configureStore } from '@reduxjs/toolkit'
 import additionalMiddleware from 'additional-middleware'
 import logger from 'redux-logger'
 // @ts-ignore
 import untypedMiddleware from 'untyped-middleware'
 import rootReducer from './rootReducer'
 
-type RootState = ReturnType<typeof rootReducer>
+export type RootState = ReturnType<typeof rootReducer>
 const store = configureStore({
   reducer: rootReducer,
+  // highlight-start
   middleware: (getDefaultMiddleware) =>
     getDefaultMiddleware()
       .prepend(
@@ -107,9 +116,12 @@ const store = configureStore({
       )
       // prepend and concat calls can be chained
       .concat(logger),
+  // highlight-end
 })
 
-type AppDispatch = typeof store.dispatch
+export type AppDispatch = typeof store.dispatch
+
+export default store
 ```
 
 #### Using `MiddlewareArray` without `getDefaultMiddleware`

etc/redux-toolkit.api.md

@@ -398,6 +398,9 @@ export class MiddlewareArray<Middlewares extends Middleware<any, any>> extends A
     prepend<AdditionalMiddlewares extends ReadonlyArray<Middleware<any, any>>>(...items: AdditionalMiddlewares): MiddlewareArray<AdditionalMiddlewares[number] | Middlewares>;
 }
 
+// @public
+export const miniSerializeError: (value: any) => SerializedError;
+
 // @public (undocumented)
 export let nanoid: (size?: number) => string;