Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix(deps): update dependency @reduxjs/toolkit to v2 #1503

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(deps): update dependency @reduxjs/toolkit to v2 #1503

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Dec 4, 2023 •
edited
Loading

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@reduxjs/toolkit (source) 1.9.7 -> 2.3.0 age adoption passing confidence

Release Notes

reduxjs/redux-toolkit (@​reduxjs/toolkit)

v2.3.0

Compare Source

This feature release adds a new RTK Query upsertQueryEntries util to batch-upsert cache entries more efficiently, passes through additional values for use in prepareHeaders, and exports additional TS types around query options and selectors.

Changelog

upsertQueryEntries

RTK Query already had an upsertQueryData thunk that would upsert a single cache entry. However, some users wanted to upsert many cache entries (potentially hundreds or thousands), and found that upsertQueryData had poor performance in those cases. This is because upsertQueryData runs the full async request handling sequence, including dispatching both pending and fulfilled actions, each of which run the main reducer and update store subscribers. That means there's 2N store / UI updates per item, so upserting hundreds of items becomes extremely perf-intensive.

RTK Query now includes an api.util.upsertQueryEntries action that is meant to handle the batched upsert use case more efficiently. It's a single synchronous action that accepts an array of many {endpointName, arg, value} entries to upsert. This results in a single store update, making this vastly better for performance vs many individual upsertQueryData calls.

We see this as having two main use cases. The first is prefilling the cache with data retrieved from storage on app startup (and it's worth noting that upsertQueryEntries can accept entries for many different endpoints as part of the same array).

The second is to act as a "pseudo-normalization" tool. RTK Query is not a "normalized" cache. However, there are times when you may want to prefill other cache entries with the contents of another endpoint, such as taking the results of a getPosts list endpoint response and prefilling the individual getPost(id) endpoint cache entries, so that components that reference an individual item endpoint already have that data available.

Currently, you can implement the "pseudo-normalization" approach by dispatching upsertQueryEntries in an endpoint lifecycle, like this:

const api = createApi({
  endpoints: (build) => ({
    getPosts: build.query<Post[], void>({
      query: () => '/posts',
      async onQueryStarted(_, { dispatch, queryFulfilled }) {
        const res = await queryFulfilled
        const posts = res.data

        // Pre-fill the individual post entries with the results
        // from the list endpoint query
        dispatch(
          api.util.upsertQueryEntries(
            posts.map((post) => ({
              endpointName: 'getPost',
              arg: { id: post.id },
              value: post,
            })),
          ),
        )
      },
    }),
    getPost: build.query<Post, Pick<Post, 'id'>>({
      query: (post) => `post/${post.id}`,
    }),
  }),
})

Down the road we may add a new option to query endpoints that would let you provide the mapping function and have it automatically update the corresponding entries.

For additional comparisons between upsertQueryData and upsertQueryEntries, see the upsertQueryEntries API reference.

prepareHeaders Options

The prepareHeaders callback for fetchBaseQuery now receives two additional values in the api argument:

  • arg: the URL string or FetchArgs object that was passed in to fetchBaseQuery for this endpoint
  • extraOptions: any extra options that were provided to the base query
Additional TS Types

We've added a TypedQueryStateSelector type that can be used to pre-type selectors for use with selectFromResult:

const typedSelectFromResult: TypedQueryStateSelector<
  PostsApiResponse,
  QueryArgument,
  BaseQueryFunction,
  SelectedResult
> = (state) => ({ posts: state.data?.posts ?? EMPTY_ARRAY })

function PostsList() {
  const { posts } = useGetPostsQuery(undefined, {
    selectFromResult: typedSelectFromResult,
  })
}

We've also exported several additional TS types around base queries and tag definitions.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.2.8...v2.3.0

v2.2.8

Compare Source

This bugfix release fixes a long-standing issue with RTK Query lazy query triggers returning stale data in some cases, fixes an error handling issue in RTK Query, and exports additional TS types.

Changelog

Lazy Query Trigger Handling

We'd had a couple long-standing issues reporting that const result = await someLazyQueryTrigger() sometimes returned stale data, especially if a mutation had just invalidated that query's tag.

We finally got a good repro of this issue and identified it as a mis-written call inside of the middleware that skipped past the necessary handling to activate the correct query status tracking in that scenario. This should now be fixed.

Other Changes

Timeout handling in RTKQ endpoints should now correctly throw a timeout-related error instead of an AbortError.

Base queries now have access to the current queryCacheKey value so it can be used in deciding query logic.

We've exported several more TS types related to query options, as some users have been depending on those even though they previously weren't part of the public API.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.2.7...v2.2.8

v2.2.7

Compare Source

This bugfix release fixes issues with "TS type portability" errors, improves build artifact tree shaking behavior, and exports some additional TS types.

Changelog

TS Type Portability

We've had a slew of issues reported around "TS type portability" errors, such as:

The error messages are typically along the lines of:

Type error: The inferred type of 'configureStore' cannot be named without a reference to '@&#8203;reduxjs/toolkit/node_modules/redux'. This is likely not portable. A type annotation is necessary.

@​aryaemami59 did some deep investigation and concluded these were due to a mixture of using interface instead of type in most places, not pre-bundling our TS typedefs, and not exporting some of the unique symbols we use internally.

Arya put together a highly detailed writeup and set of fixes in #​4467: Fix: TypeScript Type Portability Issues, and that appears to resolve all of those issues we've seen. Thank you!

Other Changes

Arya also did significant work to improve RTK's treeshaking, tweaking internal definitions to let bundlers better separate out unused code.

We've exported additional types like UpdateDefinitions and RetryOptions, per request.

listenerMiddleware.withTypes() methods now allow passing in an ExtraArgument generic.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.2.6...v2.2.7

v2.2.6

Compare Source

v2.2.5

Compare Source

This bugfix release fixes an issue in the recent createEntityAdapter sorting perf improvements that could (in specific cases) cause Immer to throw an error when trying to read a plain JS value instead of a proxy-wrapped value.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.2.4...v2.2.5

v2.2.4

Compare Source

v2.2.3

Compare Source

This minor release fixes the types for functions that accept a React Context instance to match the changes in React Redux v9.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.2.2...v2.2.3

v2.2.2

Compare Source

This patch release fixes an incorrect build setting for the legacy-esm artifacts, and fixes an issue with RTKQ query hooks didn't always remove the cache entries if arguments were changed rapidly.

Changes

legacy-esm Artifact Transpilation

The legacy-esm build artifacts are intended for use by Webpack 4. Those were supposed to be transpiled to target "es2017", but were in fact still set to target "esnext" - an oversight during the 2.0 development cycle. This release fixes that setting, so those artifacts are now correctly transpiled.

Other Fixes

RTKQ query hooks now handle additional actions around argument changes that should result in cache entries being removed.

Additionally, 2.2.1 contained a fix to an incorrectly named type: TypedUseMutationTrigger is now TypedMutationTrigger.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v2.2.0...v2.2.2

v2.2.1

Compare Source

v2.2.0

Compare Source

This minor release:

  • Adds a second parameter to entityAdapter.getInitialState(additionalProps, entities) to allow prefilling state
    • Equivalent to entityAdapter.setAll(entityAdapter.getInitialState(additionalProps), entities)
    • First parameter can be undefined if no additional properties are desired
  • Allows initialising combineSlices with no static reducers
    • Previously const combinedReducer = combineSlices().withLazyLoadedSlices<LazyLoadedSlices>() would have thrown an error
    • Now returns a "no-op" reducer that just returns an empty object until first reducer injected
  • Allows a new 'throw' value for overrideExisting in injectEndpoints, which throws an error if a definition is injected with a name which is already used
  • Exports more type helpers for RTKQ hook and trigger types
  • Exports types related to overriding result types in enhanceEndpoints
  • Fixes state inference for injected slices when undeclared (i.e. not in LazyLoadedSlices)
  • Adds a action.meta.arg.isPrefetch value to query thunk actions when prefetched

What's Changed

New Contributors

Full Changelog: reduxjs/redux-toolkit@v2.1.0...v2.2.0

v2.1.0

Compare Source

This minor release:

  • adds withTypes methods to listenerMiddleware and createDraftSafeSelector
  • adds a skipPollingIfUnfocused option to RTK Query
  • adds the ability to customise the createSelector instance used by RTK Query
  • reworks slice selector logic to avoid depending on this value
  • fixes the order and inference of create.asyncThunk type parameters
  • fixes requirements for meta fields returned from queryFns
  • marks promises that will never reject as safe, in preparation for https://github.com/typescript-eslint/typescript-eslint/issues/7008

What's Changed

New Contributors

Full Changelog: reduxjs/redux-toolkit@v2.0.1...v2.1.0

v2.0.1

Compare Source

v2.0.0

Compare Source

This major release :

  • Removes the deprecated object syntax from createSlice and createReducer
  • Removes other deprecated options
  • Updates the middleware and enhancers options of configureStore to require callbacks
  • Updates the packaging for better ESM/CJS compatibility and modernizes the build output
  • Includes all changes to Redux core 5.0, Reselect 5.0, and Redux Thunk 3.0
  • Updates RTKQ default subscription behavior
  • Adds a new combineSlices method with support for lazy-loading slice reducers
  • Adds a new "dynamic middleware" middleware with support for adding middleware at runtime
  • Adds a new callback syntax to createSlice.reducers, with optional support for defining thunks inside of createSlice
  • Adds the autoBatchEnhancer to configureStore by default
  • Has many additional TS tweaks and improvements

This release has breaking changes. (Note: v2.0.1 was released with a couple hotfixes for Reselect and Redux Thunk right as this was being finalized.)

This release is part of a wave of major versions of all the Redux packages: Redux Toolkit 2.0, Redux core 5.0, React-Redux 9.0, Reselect 5.0, and Redux Thunk 3.0.

For full details on all of the breaking changes and other significant changes to all of those packages, see the "Migrating to RTK 2.0 and Redux 5.0" migration guide in the Redux docs.

[!NOTE]
The Redux core, Reselect, and Redux Thunk packages are included as part of Redux Toolkit, and RTK users do not need to manually upgrade them - you'll get them as part of the upgrade to RTK 2.0. (If you're not using Redux Toolkit yet, please start migrating your existing legacy Redux code to use Redux Toolkit today!)

##### RTK
npm install @&#8203;reduxjs/toolkit
yarn add @&#8203;reduxjs/toolkit
Changelog
Object syntax for createSlice.extraReducers and createReducer removed

RTK's createReducer API was originally designed to accept a lookup table of action type strings to case reducers, like { "ADD_TODO": (state, action) => {} }. We later added the "builder callback" form to allow more flexibility in adding "matchers" and a default handler, and did the same for createSlice.extraReducers.

We have removed the "object" form for both createReducer and createSlice.extraReducers in RTK 2.0, as the builder callback form is effectively the same number of lines of code, and works much better with TypeScript.

As an example, this:

const todoAdded = createAction('todos/todoAdded')

createReducer(initialState, {
  [todoAdded]: (state, action) => {},
})

createSlice({
  name,
  initialState,
  reducers: {
    /* case reducers here */
  },
  extraReducers: {
    [todoAdded]: (state, action) => {},
  },
})

should be migrated to:

createReducer(initialState, (builder) => {
  builder.addCase(todoAdded, (state, action) => {})
})

createSlice({
  name,
  initialState,
  reducers: {
    /* case reducers here */
  },
  extraReducers: (builder) => {
    builder.addCase(todoAdded, (state, action) => {})
  },
})
Codemods

To simplify upgrading codebases, we've published a set of codemods that will automatically transform the deprecated "object" syntax into the equivalent "builder" syntax.

The codemods package is available on NPM as @reduxjs/rtk-codemods. More details are available here.

To run the codemods against your codebase, run npx @&#8203;reduxjs/rtk-codemods <TRANSFORM NAME> path/of/files/ or/some**/*glob.js.

Examples:

npx @&#8203;reduxjs/rtk-codemods createReducerBuilder ./src

npx @&#8203;reduxjs/rtk-codemods createSliceBuilder ./packages/my-app/**/*.ts

We also recommend re-running Prettier on the codebase before committing the changes.

These codemods should work, but we would greatly appreciate feedback from more real-world codebases!

configureStore Options Changes
configureStore.middleware must be a callback

Since the beginning, configureStore has accepted a direct array value as the middleware option. However, providing an array directly prevents configureStore from calling getDefaultMiddleware(). So, middleware: [myMiddleware] means there is no thunk middleware added (or any of the dev-mode checks).

This is a footgun, and we've had numerous users accidentally do this and cause their apps to fail because the default middleware never got configured.

As a result, we've now made the middleware only accept the callback form. If for some reason you still want to replace all of the built-in middleware, do so by returning an array from the callback:

const store = configureStore({
  reducer,
  middleware: (getDefaultMiddleware) => {
    // WARNING: this means that _none_ of the default middleware are added!
    return [myMiddleware]
    // or for TS users, use:
    // return new Tuple(myMiddleware)
  },
})

But note that we consistently recommend not replacing the default middleware entirely, and that you should use return getDefaultMiddleware().concat(myMiddleware).

configureStore.enhancers must be a callback

Similarly to configureStore.middleware, the enhancers field must also be a callback, for the same reasons.

The callback will receive a getDefaultEnhancers function that can be used to customise the batching enhancer that's now included by default.

For example:

const store = configureStore({
  reducer,
  enhancers: (getDefaultEnhancers) => {
    return getDefaultEnhancers({
      autoBatch: { type: 'tick' },
    }).concat(myEnhancer)
  },
})

It's important to note that the result of getDefaultEnhancers will also contain the middleware enhancer created with any configured/default middleware. To help prevent mistakes, configureStore will log an error to console if middleware was provided and the middleware enhancer wasn't included in the callback result.

const store = configureStore({
  reducer,
  enhancers: (getDefaultEnhancers) => {
    return [myEnhancer] // we've lost the  middleware here
    // instead:
    return getDefaultEnhancers().concat(myEnhancer)
  },
})

Also, note that if you supply the enhancers field, it must come after the middleware field in order for TS inference to work properly.

Standalone getDefaultMiddleware and getType removed

The standalone version of getDefaultMiddleware has been deprecated since v1.6.1, and has now been removed. Use the function passed to the middleware callback instead, which has the correct types.

We have also removed the getType export, which was used to extract a type string from action creators made with createAction. Instead, use the static property actionCreator.type.

RTK Query behaviour changes

We've had a number of reports where RTK Query had issues around usage of dispatch(endpoint.initiate(arg, {subscription: false})). There were also reports that multiple triggered lazy queries were resolving the promises at the wrong time. Both of these had the same underlying issue, which was that RTKQ wasn't tracking cache entries in these cases (intentionally). We've reworked the logic to always track cache entries (and remove them as needed), which should resolve those behavior issues.

We also have had issues raised about trying to run multiple mutations in a row and how tag invalidation behaves. RTKQ now has internal logic to delay tag invalidation briefly, to allow multiple invalidations to get handled together. This is controlled by a new invalidationBehavior: 'immediate' | 'delayed' flag on createApi. The new default behavior is 'delayed'. Set it to 'immediate' to revert to the behavior in RTK 1.9.

In RTK 1.9, we reworked RTK Query's internals to keep most of the subscription status inside the RTKQ middleware. The values are still synced to the Redux store state, but this is primarily for display by the Redux DevTools "RTK Query" panel. Related to the cache entry changes above, we've optimized how often those values get synced to the Redux state for perf.

ESM/CJS Package Compatibility

The biggest theme of the Redux v5 and RTK 2.0 releases is trying to get "true" ESM package publishing compatibility in place, while still supporting CJS in the published package.

The primary build artifact is now an ESM file, dist/redux-toolkit.modern.mjs. Most build tools should pick this up. There's also a CJS artifact, and a second copy of the ESM file named redux-toolkit.legacy-esm.js to support Webpack 4 (which does not recognize the exports field in package.json). Additionally, all of the build artifacts now live under ./dist/ in the published package.

Modernized Build Output

We now publish modern JS syntax targeting ES2020, including optional chaining, object spread, and other modern syntax. If you need to

Build Tooling

We're now building the package using https://github.com/egoist/tsup. We also now include sourcemaps for the ESM and CJS artifacts.

Dropping UMD Builds

Redux has always shipped with UMD build artifacts. These are primarily meant for direct import as script tags, such as in a CodePen or a no-bundler build environment.

We've dropped those build artifacts from the published package, on the grounds that the use cases seem pretty rare today.

There's now a redux-toolkit.browser.mjs file in the package that can be loaded from a CDN like Unpkg.

If you have strong use cases for us continuing to include UMD build artifacts, please let us know!

Dependency Updates
Redux Libraries

RTK now depends on Redux core 5.0, Reselect 5.0, and Redux Thunk 3.0. See the linked release notes for those libraries, as each of them has additional breaking changes. The "Migrating to RTK 2.0 and Redux 5.0" docs page also covers the combined changes in one page

Immer 10

RTK now also depends on Immer 10.0, which has several major improvements and updates:

  • Much faster update perf
  • Much smaller bundle size
  • Better ESM/CJS package formatting
  • No default export
  • No ES5 fallback

We've also removed the prior call to automatically enable the Immer ES5 fallback mode any time RTK was loaded.

Other Changes
Bundle Size Optimizations

Redux 4.1.0 optimized its bundle size by extracting error message strings out of production builds, based on React's approach. We've applied the same technique to RTK. This saves about 1000 bytes from prod bundles (actual benefits will depend on which imports are being used).

We also noted that ESBuild does not deduplicate imports when it bundles source files, and this was causing RTK Query's bundle to contain a dozen references to import { } from "@&#8203;reduxjs/toolkit", including some of the same methods. Manually deduplicating those saves about 600 bytes off the production RTKQ artifact.

reactHooksModule custom hook configuration

Previously, custom versions of React Redux's hooks (useSelector, useDispatch, and useStore) could be passed separately to reactHooksModule, usually to enable using a different context to the default ReactReduxContext.

In practicality, the react hooks module needs all three of these hooks to be provided, and it became an easy mistake to only pass useSelector and useDispatch, without useStore.

The module has now moved all three of these under the same configuration key, and will check that all three are provided if the key is present.

// previously
const customCreateApi = buildCreateApi(
  coreModule(),
  reactHooksModule({
    useDispatch: createDispatchHook(MyContext),
    useSelector: createSelectorHook(MyContext),
    useStore: createStoreHook(MyContext),
  })
)

// now
const customCreateApi = buildCreateApi(
  coreModule(),
  reactHooksModule({
    hooks: {
      useDispatch: createDispatchHook(MyContext),
      useSelector: createSelectorHook(MyContext),
      useStore: createStoreHook(MyContext),
    },
  })
)
Deprecated Options Removed

Several other options were previously marked as deprecated, and have been removed. We've also removed polyfills like the AbortController polyfill.

TypeScript Changes
configureStore field order for middleware matters

If you are passing both the middleware and enhancers fields to configureStore, the middleware field must come first in order for internal TS inference to work properly.

Non-default middleware/enhancers must use Tuple

We've seen many cases where users passing the middleware parameter to configureStore have tried spreading the array returned by getDefaultMiddleware(), or passed an alternate plain array. This unfortunately loses the exact TS types from the individual middleware, and often causes TS problems down the road (such as dispatch being typed as Dispatch<AnyAction> and not knowing about thunks).

getDefaultMiddleware() already used an internal MiddlewareArray class, an Array subclass that had strongly typed .concat/prepend() methods to correctly capture and retain the middleware types.

We've renamed that type to Tuple, and configureStore's TS types now require that you must use Tuple if you want to pass your own array of middleware:

import { configureStore, Tuple } from '@&#8203;reduxjs/toolkit'

configureStore({
  reducer: rootReducer,
  middleware: (getDefaultMiddleware) => new Tuple(additionalMiddleware, logger),
})

(Note that this has no effect if you're using RTK with plain JS, and you could still pass a plain array here.)

This same restriction applies to the enhancers field.

Entity adapter type updates

createEntityAdapter now has an Id generic argument, which will be used to strongly type the item IDs anywhere those are exposed. Previously, the ID field type was always string | number. TS will now try to infer the exact type from either the .id field of your entity type, or the selectId return type. You could also fall back to passing that generic type directly. If you use the EntityState<Data, Id> type directly, you must supply both generic arguments!

The .entities lookup table is now defined to use a standard TS Record<Id, MyEntityType>, which assumes that each item lookup exists by default. Previously, it used a Dictionary<MyEntityType> type, which assumed the result was MyEntityType | undefined. The Dictionary type has been removed.

If you prefer to assume that the lookups might be undefined, use TypeScript's noUncheckedIndexedAccess configuration option to control that.

New Features

These features are new in Redux Toolkit 2.0, and help cover additional use cases that we've seen users ask for in the ecosystem.

combineSlices API with slice reducer injection for code-splitting

The Redux core has always included combineReducers, which takes an object full of "slice reducer" functions and generates a reducer that calls those slice reducers. RTK's createSlice generates slice reducers + associated action creators, and we've taught the pattern of exporting individual action creators as named exports and the slice reducer as a default export. Meanwhile, we've never had official support for lazy-loading reducers, although we've had sample code for some "reducer injection" patterns in our docs.

This release includes a new combineSlices API that is designed to enable lazy-loading of reducers at runtime. It accepts individual slices or an object full of slices as arguments, and automatically calls combineReducers using the sliceObject.name field as the key for each state field. The generated reducer function has an additional .inject() method attached that can be used to dynamically inject additional slices at runtime. It also includes a .withLazyLoadedSlices() method that can be used to generate TS types for reducers that will be added later. See #​2776 for the original discussion around this idea.

For now, we are not building this into configureStore, so you'll need to call const rootReducer = combineSlices(.....) yourself and pass that to configureStore({reducer: rootReducer}).

Basic usage: a mixture of slices and standalone reducers passed to combineSlices

const stringSlice = createSlice({
  name: 'string',
  initialState: '',
  reducers: {},
})

const numberSlice = createSlice({
  name: 'number',
  initialState: 0,
  reducers: {},
})

const booleanReducer = createReducer(false, () => {})

const api = createApi(/*  */)

const combinedReducer = combineSlices(
  stringSlice,
  {
    num: numberSlice.reducer,
    boolean: booleanReducer,
  },
  api
)
expect(combinedReducer(undefined, dummyAction())).toEqual({
  string: stringSlice.getInitialState(),
  num: numberSlice.getInitialState(),
  boolean: booleanReducer.getInitialState(),
  api: api.reducer.getInitialState(),
})

Basic slice reducer injection

// Create a reducer with a TS type that knows `numberSlice` will be injected
const combinedReducer =
  combineSlices(stringSlice).withLazyLoadedSlices<
    WithSlice<typeof numberSlice>
  >()

// `state.number` doesn't exist initially
expect(combinedReducer(undefined, dummyAction()).number).toBe(undefined)

// Create a version of the reducer with `numberSlice` injected (mainly useful for types)
const injectedReducer = combinedReducer.inject(numberSlice)

// `state.number` now exists, and injectedReducer's type no longer marks it as optional
expect(injectedReducer(undefined, dummyAction()).number).toBe(
  numberSlice.getInitialState()
)

// original reducer has also been changed (type is still optional)
expect(combinedReducer(undefined, dummyAction()).number).toBe(
  numberSlice.getInitialState()
)
selectors field in createSlice

The existing createSlice API now has support for defining selectors directly as part of the slice. By default, these will be generated with the assumption that the slice is mounted in the root state using slice.name as the field, such as name: "todos" -> rootState.todos. Additionally, there's now a slice.selectSlice method that does that default root state lookup.

You can call sliceObject.getSelectors(selectSliceState) to generate the selectors with an alternate location, similar to how entityAdapter.getSelectors() works.

const slice = createSlice({
  name: 'counter',
  initialState: 42,
  reducers: {},
  selectors: {
    selectSlice: (state) => state,
    selectMultiple: (state, multiplier: number) => state * multiplier,
  },
})

// Basic usage
const testState = {
  [slice.name]: slice.getInitialState(),
}
const { selectSlice, selectMultiple } = slice.selectors
expect(selectSlice(testState)).toBe(slice.getInitialState())
expect(selectMultiple(testState, 2)).toBe(slice.getInitialState() * 2)

// Usage with the slice reducer mounted under a different key
const customState = {
  number: slice.getInitialState(),
}
const { selectSlice, selectMultiple } = slice.getSelectors(
  (state: typeof customState) => state.number
)
expect(selectSlice(customState)).toBe(slice.getInitialState())
expect(selectMultiple(customState, 2)).toBe(slice.getInitialState() * 2)
createSlice.reducers callback syntax and thunk support

One of the oldest feature requests we've had is the ability to declare thunks directly inside of createSlice. Until now, you've always had to declare them separately, give the thunk a string action prefix, and handle the actions via createSlice.extraReducers:

// Declare the thunk separately
const fetchUserById = createAsyncThunk(
  'users/fetchByIdStatus',
  async (userId: number, thunkAPI) => {
    const response = await userAPI.fetchById(userId)
    return response.data
  }
)

const usersSlice = createSlice({
  name: 'users',
  initialState,
  reducers: {
    // standard reducer logic, with auto-generated action types per reducer
  },
  extraReducers: (builder) => {
    // Add reducers for additional action types here, and handle loading state as needed
    builder.addCase(fetchUserById.fulfilled, (state, action) => {
      state.entities.push(action.payload)
    })
  },
})

Many users have told us that this separation feels awkward.

We

Configuration

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

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

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

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 15 times, most recently from 00ddefe to 723ec23 Compare December 11, 2023 03:30
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 7 times, most recently from 30523e4 to e9fb1a0 Compare December 18, 2023 07:45
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 5 times, most recently from ccfa077 to 64d6526 Compare December 25, 2023 19:17
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 3 times, most recently from 5519c46 to 31ee3ff Compare December 28, 2023 01:54
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 8 times, most recently from db6d741 to 8dac0c3 Compare October 17, 2024 20:23
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 10 times, most recently from e552af4 to eca5dc1 Compare October 25, 2024 19:19
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch 10 times, most recently from 75a3402 to b1908ca Compare November 4, 2024 03:13
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-2.x branch from b1908ca to 37f271e Compare November 5, 2024 03:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0 participants