Skip to content

Releases: reduxjs/redux-toolkit

v2.0.0-beta.4

28 Oct 23:34
@markerikson markerikson
v2.0.0-beta.4
2b6d65e
Compare
Choose a tag to compare
v2.0.0-beta.4 Pre-release
Pre-release

This beta release updates RTK Query to fix issues around cache entry behavior when subscription: false is used or with multiple lazy queries in progress, alters RTK Query's tag invalidation behavior to better handle cases where multiple invalidations may happen in sequence, rewrites RTK Query's internals to improve performance around subscription data syncing, and updates Reselect to the latest 5.0.0-beta.0.

npm i @reduxjs/toolkit@beta

yarn add @reduxjs/toolkit@beta

The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:

Changelog

RTK Query Behavior 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.

Other Changes

We've updated the Reselect dependency to Reselect 5.0.0-beta.0, which adds the ability to pass memoizer functions and options directly to createSelector.

The new create.asyncThunk() builder inside of createSlice can now be given a settled reducer, which will run when the thunk promise either fulfills or rejects.

What's Changed

Full Changelog: v2.0.0-beta.3...v2.0.0-beta.4

Contributors

markerikson, phryneas, and 2 other contributors
Assets 2

v2.0.0-beta.3

12 Oct 00:09
@markerikson markerikson
v2.0.0-beta.3
ca15ec2
Compare
Choose a tag to compare
v2.0.0-beta.3 Pre-release
Pre-release

This beta release updates configureStore to remove the deprecated option of passing an array for middleware, improves the createEntityAdapter types to improve compatibility, updates deps to use the latest React-Redux beta, and optimizes the TS compile perf for RTKQ hooks.

npm i @reduxjs/toolkit@beta

yarn add @reduxjs/toolkit@beta

The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:

Changelog

configureStore.middleware Option 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.

We already had made the enhancers option only accept the callback form, so we've done the same thing for middleware.

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 correct TS inference, 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).

TS Updates

The types for createEntityAdapter have been reworked for better compat with Immer drafts.

The RTK Query types for generating React hooks have been optimized for much faster TS compilation perf (~60% improvement in one synthetic example app).

Other Changes

RTK Query's custom React hooks option now checks at runtime that all 3 hooks have been provided.

A new codemod is now available as part of the @reduxjs/rtk-codemods package that will convert a given createSlice call to the new "create callback" notation, which is primarily used for adding thunks inside of createSlice. Unlike the other codemods for replacing the obsolete/removed object syntax in createReducer and createSlice, this is purely optional.

What's Changed

Full Changelog: v2.0.0-beta.2...v2.0.0-beta.3

Contributors

markerikson, EskiMojo14, and Olesj-Bilous
Assets 2

v1.9.7

04 Oct 22:01
@markerikson markerikson
v1.9.7
2fe9e73
Compare
Choose a tag to compare
v1.9.7

This bugfix release rewrites the RTKQ hook TS types to significantly improve TS perf.

Changelog

RTKQ TS Perf

A number of users had reported that Intellisense for RTKQ API objects was extremely slow (multiple seconds) - see discussion in #3214 . We did some perf investigation on user-provided examples, and concluded that the biggest factor to slow RTKQ TS perf was the calculation of hook names like useGetPokemonQuery, which was generating a large TS union of types.

We've rewritten that hook names type calculation to use mapped types and a couple of intersections. In a specific user-provided stress test repo, it dropped TS calculation time by 60% (2600ms to 1000ms).

There's more potential work we can do to improve things, but this seems like a major perf improvement worth shipping now.

What's Changed

Full Changelog: v1.9.6...v1.9.7

Contributors

julian-ford, EskiMojo14, and kahirokunn
Assets 2

v2.0.0-beta.2

25 Sep 00:24
@markerikson markerikson
v2.0.0-beta.2
8910e2b
Compare
Choose a tag to compare
v2.0.0-beta.2 Pre-release
Pre-release

This beta release updates the build step to extract error messages and optimizes internal imports in RTK Query for smaller production bundle sizes, adds a selectCachedArgsForQuery util, and includes all changes in v1.9.6

npm i @reduxjs/toolkit@beta

yarn add @reduxjs/toolkit@beta

The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:

Changelog

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 "@reduxjs/toolkit", including some of the same methods. Manually deduplicating those saves about 600 bytes off the production RTKQ artifact.

Other Changes

We've added a selectCachedArgsForQuery util selector that will return the saved arguments that were used for a given cache entry.

This also includes all of the changes in v1.9.6.

What's Changed

Full Changelog: v2.0.0-beta.1...v2.0.0-beta.2

Contributors

markerikson and EskiMojo14
Assets 2

v1.9.6

24 Sep 23:47
@markerikson markerikson
v1.9.6
e351a09
Compare
Choose a tag to compare
v1.9.6

This bugfix release adds a new dev-mode middleware to catch accidentally dispatching an action creator, adds a new listener middleware option around waiting for forks, adds a new option to update provided tags when updateQueryData is used, reworks internal types to better handle uses with TS declaration output, and fixes a variety of small issues.

Changelog

Action Creator Dev Check Middleware

RTK already includes dev-mode middleware that check for the common mistakes of accidentally mutating state and putting non-serializable values into state or actions.

Over the years we've also seen a semi-frequent error where users accidentally pass an action creator reference to dispatch, instead of calling it and dispatching the action it returns.

We've added another dev-mode middleware that specifically catches this error and warns about it.

Additional Options

The listener middleware's listenerApi.fork() method now has an optional autoJoin flag that can be used to keep the effect from finishing until all active forked tasks have completed.

updateQueryData now has an updateProvidedTags option that will force a recalculation of that endpoint's provided tags. It currently defaults to false, and we'll likely turn that to true in the next major.

Other Fixes

The builder.addCase method now throws an error if a type string is empty.

fetchBaseQuery now uses an alternate method to clone the original Request in order to work around an obscure Chrome bug.

The immutability middleware logic was tweaked to avoid a potential stack overflow.

Types Changes

The internal type imports have been reworked to try to fix "type portability" issues when used in combination with TS declaration outputs.

A couple additional types were exported to help with wrapping createAsyncThunk.

What's Changed

Full Changelog: v1.9.5...v1.9.6

Contributors

ericanderson, dutzi, and 7 other contributors
Assets 2

v2.0.0-beta.1

26 Aug 22:59
@markerikson markerikson
v2.0.0-beta.1
898ed5a
Compare
Choose a tag to compare
v2.0.0-beta.1 Pre-release
Pre-release

This beta release updates the build and packaging setup to improve TS and ESM compatibility, fixes several TS issues, and updates to the latest React-Redux and Redux-Thunk deps.

npm i @reduxjs/toolkit@beta

yarn add @reduxjs/toolkit@beta

The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:

Build and TS Updates

We've made several tweaks to the packaging to improve compatibility for ESM and TS typedef definitions, which should fix some issues that were reported with beta.0.

We also fixed several assorted TS issues that were affecting users in specific edge cases.

Other Changes

We removed the AbortController polyfill from createAsyncThunk, saving some bytes.

We've updated deps to redux-thunk@3.0.0-beta.0 and react-redux@9.0.0-alpha.0.

What's Changed

Full Changelog: v2.0.0-beta.0...v2.0.0-beta.1

Contributors

markerikson, evertbouw, and 2 other contributors
Assets 2

v2.0.0-beta.0

30 May 23:55
@markerikson markerikson
v2.0.0-beta.0
556b20b
Compare
Choose a tag to compare
v2.0.0-beta.0 Pre-release
Pre-release

This beta release updates many of our TS types for improved type safety and behavior, updates entityAdapter.getSelectors() to accept a createSelector option, depends on the latest redux@5.0-beta.0 release, and includes all prior changes from the 2.0 alphas. This release has breaking changes.

npm i @reduxjs/toolkit@next

yarn add @reduxjs/toolkit@next

The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for most of the new features here:

Changelog

Store Configuration Tweaks and Type Safety

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 '@reduxjs/toolkit'

configureStore({
  reducer: rootReducer,
  middleware: 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.)

Similarly, the enhancers field used to accept an array directly. It now is a callback that receives a getDefaultEnhancers method, equivalent to getDefaultMiddleware():

const store = configureStore({
  reducer,
  middleware: (getDefaultMiddleware) => getDefaultMiddleware().concat(logger),
  enhancers: (getDefaultEnhancers) =>
    getDefaultEnhancers({
      autoBatch: false,
    }).concat(batchedSubscribe(debounceNotify)),
})

It too expects a Tuple return value if you're using TS.

Entity Adapter Updates

entityAdapter.getSelectors() now accepts an options object as its second argument. This allows you to pass in your own preferred createSelector method, which will be used to memoize the generated selectors. This could be useful if you want to use one of Reselect's new alternate memoizers, or some other memoization library with an equivalent signature.

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.

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 UnknownAction Type

The Redux core TS types have always exported an AnyAction type, which is defined to have {type: string} and treat any other field as any. This makes it easy to write uses like console.log(action.whatever), but unfortunately does not provide any meaningful type safety.

We now export an UnknownAction type, which treats all fields other than action.type as unknown. This encourages users to write type guards that check the action object and assert its specific TS type. Inside of those checks, you can access a field with better type safety.

UnknownAction is now the default any place in the Redux and RTK source that expects an action object.

AnyAction still exists for compatibility, but has been marked as deprecated.

Note that Redux Toolkit's action creators have a .match() method that acts as a useful type guard:

if (todoAdded.match(someUnknownAction)) {
  // action is now typed as a PayloadAction<Todo>
}

Earlier Alpha Changes

Summarizing the changes from earlier alphas:

New Features

  • combineSlices API with built-in support for slice reducer injection for code-splitting
  • selectors field in createSlice
  • Callback form of createSlice.reducers, which allows defining thunks inside createSlice
  • "Dynamic middleware" middleware
  • configureStore adds autoBatchEnhancer by default
  • Reselect v5 runs selectors an additional time on first call in dev to check for improper memoization, and includes new optional autotrack and weakmap memoizers with different tradeoffs

Breaking Changes

  • Object argument for createReducer and createSlice.extraReducers has been removed
  • Packaging converted to have full ESM/CJS compatibility
  • Dropped UMD build artifacts
  • JS build output is now "modern" and not transpiled for IE11 compatibility
  • Updated to Immer 10, and dropped the legacy ES5 compat option
  • Updated Redux core dep to 5.0-beta
  • actionCreator.toString() override removed (although we're reconsidering this)
  • Standalone getDefaultMiddleware removed
  • Other deprecated fields removed

What's Changed

Full Changelog: v2.0.0-alpha.6...v2.0.0-beta.0

Contributors

EskiMojo14 and Matt-Ord
Assets 2
24 Join discussion

v2.0.0-alpha.6

16 May 14:18
@markerikson markerikson
v2.0.0-alpha.6
44b4f67
Compare
Choose a tag to compare
v2.0.0-alpha.6 Pre-release
Pre-release

This is an alpha release for Redux Toolkit 2.0, and has breaking changes. This release updates createSlice to allow declaring thunks directly inside the reducers field using a callback syntax, adds a new "dynamic middleware" middleware, updates configureStore to add the autoBatchEnhancer by default, removes the .toString() override from action creators, updates Reselect from v4.x to v5.0-alpha, updates the Redux core to v5.0-alpha.6, and includes the latest changes from 1.9.x.

npm i @reduxjs/toolkit@alpha

yarn add @reduxjs/toolkit@alpha

The 2.0 integration branch contains the docs preview for the 2.0 changes. Not all changes are documented yet, but you can see API reference pages for some of the new features here:

Changelog

Declaring Thunks Inside createSlice.reducers

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've wanted to include a way to define thunks directly inside of createSlice, and have played around with various prototypes. There were always two major blocking issues, and a secondary concern:

1 It wasn't clear what the syntax for declaring a thunk inside should look like.
2. Thunks have access to getState and dispatch, but the RootState and AppDispatch types are normally inferred from the store, which in turn infers it from the slice state types. Declaring thunks inside createSlice would cause circular type inference errors, as the store needs the slice types but the slice needs the store types. We weren't willing to ship an API that would work okay for our JS users but not for our TS users, especially since we want people to use TS with RTK.
3. You can't do synchronous conditional imports in ES modules, and there's no good way to make the createAsyncThunk import optional. Either createSlice always depends on it (and adds that to the bundle size), or it can't use createAsyncThunk at all.

We've settled on these compromises:

  • You can declare thunks inside of createSlice.reducers, by using a "creator callback" syntax for the reducers field that is similar to the build callback syntax in RTK Query's createApi (using typed functions to create fields in an object). Doing this does look a bit different than the existing "object" syntax for the reducers field, but is still fairly similar.
  • You can customize some of the types for thunks inside of createSlice, but you cannot customize the state or dispatch types. If those are needed, you can manually do an as cast, like getState() as RootState.
  • createSlice does now always depend on createAsyncThunk, so the createAsyncThunk implementation will get added to the bundle.

In practice, we hope these are reasonable tradeoffs. Creating thunks inside of createSlice has been widely asked for, so we think it's an API that will see usage. If the TS customization options are a limitation, you can still declare thunks outside of createSlice as always, and most async thunks don't need dispatch or getState - they just fetch data and return. And finally, createAsyncThunk is already being used in many apps, either directly or as part of RTK Query, so in that case there's no additional bundle size increase - you've already paid that cost.

Here's what the new callback syntax looks like:

const todosSlice = createSlice({
  name: 'todos',
  initialState: {
    loading: false,
    todos: [],
  } as TodoState,
  reducers: (create) => ({
    // A normal "case reducer", same as always
    deleteTodo: create.reducer((state, action: PayloadAction<number>) => {
      state.todos.splice(action.payload, 1)
    }),
    // A case reducer with a "prepare callback" to customize the action
    addTodo: create.preparedReducer(
      (text: string) => {
        const id = nanoid()
        return { payload: { id, text } }
      },
      // action type is inferred from prepare callback
      (state, action) => {
        state.todos.push(action.payload)
      }
    ),
    // An async thunk
    fetchTodo: create.asyncThunk(
      // Async payload function as the first argument
      async (id: string, thunkApi) => {
        const res = await fetch(`myApi/todos?id=${id}`)
        return (await res.json()) as Item
      },
      // An object containing `{pending?, rejected?, fulfilled?, options?}` second
      {
        pending: (state) => {
          state.loading = true
        },
        rejected: (state, action) => {
          state.loading = false
        },
        fulfilled: (state, action) => {
          state.loading = false
          state.todos.push(action.payload)
        },
      }
    ),
  }),
})

// `addTodo` and `deleteTodo` are normal action creators.
// `fetchTodo` is the async thunk
export const { addTodo, deleteTodo, fetchTodo } = todosSlice.actions

"Dynamic Middleware" Middleware

A Redux store's middleware pipeline is fixed at store creation time and can't be changed later. We have seen ecosystem libraries that tried to allow dynamically adding and removing middleware, potentially useful for things like code splitting.

This is a relatively niche use case, but we've built our own version of a "dynamic middleware" middleware. Add it to the Redux store at setup time, and it lets you add and remove middleware later at runtime. It also comes with a React hook integration that will automatically add a middleware to the store and return the updated dispatch method.

import { createDynamicMiddleware, configureStore } from '@reduxjs/toolkit'

const dynamicMiddleware = createDynamicMiddleware()

const store = configureStore({
  reducer: {
    todos: todosReducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().prepend(dynamicMiddleware.middleware),
})

// later
dynamicMiddleware.addMiddleware(someOtherMiddleware)

Store Adds autoBatchEnhancer By Default

In v1.9.0, we added a new autoBatchEnhancer that delays notifying subscribers briefly when multiple "low-priority" actions are dispatched in a row. This improves perf, as UI updates are typically the most expensive part of the update process. RTK Query marks most of its own internal actions as "low-pri" by default, but you have to have the autoBatchEnhancer added to the store to benefit from that.

We've updated configureStore to add the autoBatchEnhancer to the store setup by default, so that users can benefit from the improved perf without needing to manually tweak the store config themselves.

configureStore now also accepts a callback for the enhancers option that receives a getDefaultEnhancers() param, equivalent to how the middleware callback receives getDefaultMiddleware():

const store = configureStore({
    reducer: rootReducer,
    middleware: (getDefaultMiddleware) =>
      getDefaultMiddleware().concat(loggerMiddleware),
    preloadedState,
    enhancers: (getDefaultEnhancers) =>
      getDefaultEnhancers().concat(anotherEnhancer),
  })

Deprecation Removals

When we first released the early alphas of RTK, one of the main selling points was that you could reuse RTK's action creators as "computed key" fields in the object argument to createReducer, like:

const todoAdded = createAction("todos/todoAdded");

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

This was possible because createAction overrides the fn.toString() field on these action creators to return the action type string. When JS sees the function, it implicitly calls todoAdded.toString(), which returns "todos/todoAdded", and that string is used as the key.

While this capability was useful early on, it's not useful today. Most users never call createAction, because createSlice automatically generates action creators. Additionally, it has no TS type safety. TS only sees that the key is a string, and has no idea what the correct TS type for action is. We later created the "builder callback" syntax for both createReducer and createSlice.extraReducers, started teaching that as the default, and removed the "object" argument to both of those in an earlier RTK 2.0 alpha.

Because of this, we've now removed the fn.toString() override. If you need to access the type string from an action creator function, those still have a .type field attached:

const todoAdded = createAction("todos/todoAdded");
console.log(todoAdded.type) // "todos/todoAdded"

We've also removed the standalone export of getDefaultMiddleware, which has been deprecated ever since we added the callback for the `configureStore.middlewa...

Read more

Contributors

ericanderson, markerikson, and 3 other contributors
Assets 2
12 Join discussion

v2.0.0-alpha.5

18 Apr 16:30
@markerikson markerikson
v2.0.0-alpha.5
805379b
Compare
Choose a tag to compare
v2.0.0-alpha.5 Pre-release
Pre-release

This is an alpha release for Redux Toolkit 2.0. This release adds a new combineSlices API for reducer injection, has many changes to our build setup and published package contents, updates the redux dep to the latest alpha, updates the immer dep to 10.0 final, includes the latest changes from 1.9.x, and has breaking changes.

Changelog

New combineSlices API

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}).

We don't have documentation added for these features yet, but here's example usages from the combineSlices PR tests:

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 new reducer with `numberSlice` injected
const injectedReducer = combinedReducer.inject(numberSlice)

// `state.number` now exists
expect(injectedReducer(undefined, dummyAction()).number).toBe(
  numberSlice.getInitialState()
)

Selectors support 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. You can call sliceObject.getSelectors(selectSliceState) to generate the selectors with an alternate location, similar to how entityAdapter.getSelectors() works.

Slice selectors
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)

Build Setup Updates

We've switched our build setup to use tsup, an ESBuild-powered build framework. This release should have identical build artifacts to 2.0.0-alpha.4, but let us know if there are any issues!

Immer 10.0

Immer 10.0 is now final, and 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 updated RTK to depend on the final Immer 10.0 release .

Redux 5.0 alpha and TS types updates

We've updated RTK to use the latest Redux 5.0-alpha.5 release, which tweaks the Reducer type, drops the internal $CombinedState type, and updates middleware types to default to unknown for actions.

For RTK, we've improved type inference for store enhancers, especially those that add additional fields to the state or store.

What's Changed

Full Changelog: v2.0.0-alpha.4...v2.0.0-alpha.5

Contributors

praxxis, dmitrigrabov, and 4 other contributors
Assets 2
1 Join discussion

v1.9.5

18 Apr 02:53
@markerikson markerikson
v1.9.5
d3bb412
Compare
Choose a tag to compare
v1.9.5

This bugfix release includes notable improvements to TS type inference when using the enhancers option in configureStore, and updates the listener middleware to only check predicates if the dispatched value is truly an action object.

What's Changed

  • update to latest remark-typescript-tools by @EskiMojo14 in #3311
  • add isAction helper function, and ensure listener middleware only runs for actions by @EskiMojo14 in #3372
  • Allow inference of enhancer state extensions, and fix inference when using callback form by @EskiMojo14 in #3207

Full Changelog: v1.9.4...v1.9.5

Contributors

EskiMojo14
Assets 2