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

Update dependency @reduxjs/toolkit to v1.9.7 #9

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

Update dependency @reduxjs/toolkit to v1.9.7 #9

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Mar 5, 2022 •
edited

Mend Renovate

This PR contains the following updates:

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

Release Notes

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

v1.9.7

Compare Source

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: reduxjs/redux-toolkit@v1.9.6...v1.9.7

v1.9.6

Compare Source

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: reduxjs/redux-toolkit@v1.9.5...v1.9.6

v1.9.5

Compare Source

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

Full Changelog: reduxjs/redux-toolkit@v1.9.4...v1.9.5

v1.9.4

Compare Source

This bugfix release includes tweaks to RTKQ options handling, tweaks for perf updates, dependency updates, and updates to our CI tooling.

Also, please check out our ongoing RTK 2.0 alpha releases! They have significant improvements to bundle size, ESM/CJS compatibility, TS typings, and reducer update performance. We're looking for real-world feedback on behavior, performance, and any issues you might run into.

Changelog

RTK Query Options Updates

Passing transformResponse as part of enhanceEndpoints can now override the TS type of the original data.

fetchBaseQuery now properly checks for a global responseHandler option.

Performance and Internals

RTK Query now uses Immer's original() to do comparisons inside of copyWithStructuralSharing, which should significantly speed up performance when applying changes from re-fetched data.

RTKQ's internal subscriptionUpdated action is now marked as batchable.

We've updated dependencies to Immer 9.0.21, Reselect 4.1.8, and Redux 4.2.1.

CI Updates

We've added a suite of example apps built with different frameworks such as CRA 4, CRA 5, Next, and Vite, as well as examples that check for compatibility in Node with CJS and ESM modes and with various TS module resolution modes.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.9.3...v1.9.4

v1.9.3

Compare Source

This release fixes a couple issues with the skip/skipToken options for query hooks, and makes a small perf tweak to serializing query args.

Changelog

Skip Behavior

We made a change in v1.9.0 that tried to make some skip behavior more consistent, including clearing out the cached data. However, we had overlooked that our own docs actually said "skipping a query will keep the cached data", and several users pointed this out as they'd been relying on that behavior.

We've reverted that change. Now, setting {skip: true} or skipToken for a query with existing results will keep the data value (reflecting the last successful query), but currentData will be undefined (reflecting the current settings).

We also identified and fixed an issue that could cause subscription entries to leak under a specific combination of timing and settings changes.

Query Arg Serialization Perf

RTKQ relies on serializing query arguments to serve as the cache keys, with the default using JSON.stringify() + some logic for sorting keys. There was a report that in some apps, large query arg objects could take a while to stringify and this was being done repeatedly. We've added a WeakMap-based cache for query args to avoid re-serializing existing arg values.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.9.2...v1.9.3

v1.9.2

Compare Source

This bugfix release fixes a memory leak in createListenerMiddleware, optimizes performance inside serializableMiddleware, adds new options for fetchBaseQuery, adds support for path RegExp exclusions in serializableMiddleware and immutabilityMiddleware, and improves some TS types.

Changelog

Bug Fixes

createListenerMiddleware had a memory leak that turned out to be due to use of Promise.race(). We've restructured the logic to fix that.

fetchBaseQuery now correctly combines global options with endpoint / default options in all cases.

New Options

fetchBaseQuery now supports a jsonReplacer option that will be used when processing JSON.

Both dev check middleware now support regular expressions in the ignoredPaths array in addition to strings. This adds extra flexibility in skipping certain fields.

TS Changes

The CaseReducer type was sometimes incorrectly inferring its return type in rare cases. That's been fixed.

The isAnyOf/isAllOf matcher function TS types have been tweaked to not require an individual first parameter. This allows spreading arrays of matchers as arguments, like const isLoading = isAnyOf(...interestingPendingThunksArray).

Other Changes

The serializableMiddleware now uses a WeakSet if available to cache values it's seen. This should significantly speed up checks against large state values in development builds.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.9.1...v1.9.2

v1.9.1

Compare Source

This bugfix release fixes assorted issues that were reported with RTK 1.9.0, and adds a few additional requested tweaks and improvements.

Changelog

Fixes

The createAsyncThunk.withTypes function was fully broken (it type-checked correctly, but pointed to the wrong function due to a name shadowing issue). That now works correctly.

The maxRetries option for RTKQ was inadvertently filtering out 0 values, and those are now accepted.

fulfillWithValue had incorrect types that made it appear as if the data was nested an additional level deeper. The types are now correct.

The ActionCreatorWithoutPayload type was tweaked to force an error when an action creator is accidentally called with an argument, which happens in cases like onClick={todoAdded}. This avoids accidentally passing values like React event objects as the payload.

Timer handling for batchActions and autoBatchEnhancer now works in more JS runtime environments.

Other Changes

The TagDescription type is now exported from RTKQ.

API endpoints now have a .name field containing the endpoint name, such as "getPokemon".

Calling promise.abort() on a createAsyncThunk promise before an async condition resolves will now be treated as if the condition itself returned false, bailing out and not dispatching anything.

The merge option now receives a third argument containing {arg, baseQueryMeta, fulfilledTimeStamp, requestId}, in case that info is useful in deciding how to merge.

The @reduxjs/rtk-codemods package has been updated to fix cases where the createSliceBuilder codemod didn't preserve fields with function variable arguments, like [todoAdded]: adapter.addOne. That package has been updated to v0.0.3.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.9.0...v1.9.1

v1.9.0

Compare Source

This feature release adds several new options for RTK Query's createApi and fetchBaseQuery APIs, adds a new upsertQueryData util, rewrites RTKQ's internals for improved performance, adds a new autoBatchEnhancer, deprecates the "object" syntax for createReducer and createSlice.extraReducers, deprecates and removes broken utils for getting running query promises, improves TS inference, exports additional types, and fixes a number of reported issues.

npm i @​reduxjs/toolkit@latest

yarn add @​reduxjs/toolkit@latest

We plan to start work on RTK 2.0 in the next few weeks. RTK 2.0 will focus on dropping legacy build compatibility and deprecated APIs, with some potential new features. See the linked discussion thread and give us feedback on ideas!

Deprecations and Removals

Object Argument for createReducer and createSlice.extraReducers

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 intend to remove the "object" form for both createReducer and createSlice.extraReducers in RTK 2.0. The builder callback form is effectively the same number of lines of code, and works much better with TypeScript.

Starting with this release, RTK will print a one-time runtime warning for both createReducer and createSlice.extraReducers if you pass in an object argument.

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 for Deprecated Object Reducer Syntax

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. It currently contains two codemods: createReducerBuilder and createSliceBuilder.

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 testing and feedback on more real-world codebases!

Object reducer codemod before/after examples Before: 
createReducer(initialState, {
  [todoAdded1a]: (state, action) => {
    // stuff
  },
  [todoAdded1b]: (state, action) => action.payload,
});

const slice1 = createSlice({
  name: "a",
  initialState: {},
  extraReducers: {
    [todoAdded1a]: (state, action) => {
      // stuff
    },
    [todoAdded1b]: (state, action) => action.payload,
  }
})

After:

createReducer(initialState, (builder) => {
  builder.addCase(todoAdded1a, (state, action) => {
    // stuff
  });

  builder.addCase(todoAdded1b, (state, action) => action.payload);
})

const slice1 = createSlice({
  name: "a",
  initialState: {},

  extraReducers: (builder) => {
    builder.addCase(todoAdded1a, (state, action) => {
      // stuff
    });

    builder.addCase(todoAdded1b, (state, action) => action.payload);
  }
})
getRunningOperationPromises Deprecation and Replacement

In v1.7.0, we added an api.util.getRunningOperationPromises() method for use with SSR scenarios, as well as a singular getRunningOperationPromise() method intended for possible use with React Suspense.

Unfortunately, in #​2477 we realized that both those methods have a fatal flaw - they do not work with multiple stores in SSR.

As of this release, we are immediately marking getRunningOperationPromises() as deprecated and discouraging its use before we remove it completely in RTK 2.0! It will now throw both runtime and compile errors in development to enforce moving away from using it. However, we are leaving its existing behavior in production builds to avoid actual breakage.

The getRunningOperationPromise() util was experimental, and as far as we can tell not actually being used by anyone, so we are removing getRunningOperationPromise completely in this release.

As replacements, RTKQ now includes four new thunks attached to api.util:

  • getRunningQueryThunk(endpointName, queryArgs)
  • getRunningMutationThunk(endpointName, fixedCacheKeyOrRequestId)
  • getRunningQueriesThunk()
  • getRunningMutationsThunk()

Usages would typically change like this:

-await Promise.all(api.util.getRunningOperationPromises())
+await Promise.all(dispatch(api.util.getRunningQueriesThunk()))

Changelog

New RTK Query createApi Options

createApi endpoints now have several additional options that can be passed in, some of which are intended to work together.

merge Option

RTKQ was built around the assumption that the server is the source of truth, and every refetch replaces the cached data on the client. There are use cases when it would be useful to merge an incoming response into the existing cached data instead, such as pagination or APIs that return varying results over time.

Query endpoints can now accept a merge(cachedData, responseData) callback that lets you do Immer-powered "mutations" to update the existing cached data instead of replacing it entirely.

Since RTKQ assumes that each response per key should replace the existing cache entry by default, the merge option is expected to be used with the serializeQueryArgs and forceRefetch options, as described below.

serializeQueryArgs Option

RTK Query always serializes the cache key value, and uses the string as the actual key for storing the cache entry. The default serialization is the name of the endpoint, plus either the primitive value or a stable-serialized object. An example might be state.api.queries['getPokemon("pikachu")'].

RTKQ already supported customization of this serialization behavior at the createApi level. Now, each endpoint can specify its own serializeQueryArgs method.

The per-endpoint serializeQueryArgs may return either a string, an object, a number, or a boolean. If it's a string, that value will be used as-is. Otherwise, the return value will be run through the default serialization logic. This simplifies the common case of stripping out a couple unwanted object fields from the cache key.

This option serves two main purposes: leaving out values that are passed in to an endpoint but not really part of the "key" conceptually (like a socket or client instance), and altering cache key behavior to use a single entry for the endpoint (such as in an infinite loading / pagination scenario).

Also, the defaultSerializeQueryArgs util is now exported.

    getPost: build.query<Post, { id: string; client: MyApiClient }>({
      queryFn: async ({ id, client }) => {
        const post = await client.fetchPost(id)
        return { data: post }
      },
      serializeQueryArgs: ({ queryArgs, endpointDefinition, endpointName }) => {
        const { id } = queryArgs
        // This can return a string, an object, a number, or a boolean.
        // If it returns an object, number or boolean, that value
        // will be serialized automatically via `defaultSerializeQueryArgs`
        return { id } // omit `client` from the cache key

        // Alternately, you can use `defaultSerializeQueryArgs`:
        // return defaultSerializeQueryArgs({
        //   endpointName,
        //   queryArgs: { id },
        //   endpointDefinition
        // })
        // Or  create and return a string yourself:
        // return `getPost(${id})`
      },
    }),
forceRefresh option

Sometimes you may want to force a refetch, even though RTKQ thinks that the serialized query args haven't changed and there's already a fulfilled cache entry.

This can be used to force RTKQ to actually refetch. One expected use case is an "infinite pagination" scenario where there is one cache entry for the endpoint, different page numbers are given as query args, and the incoming responses are merged into the existing cache entry:

    listItems: build.query<string[], number>({
      query: (pageNumber) => `/listItems?page=${pageNumber}`,
      // Only have one cache entry because the arg always maps to one string
      serializeQueryArgs: ({ endpointName }) => {
        return endpointName
      },
      // Always merge incoming data to the cache entry
      merge: (currentCache, newItems) => {
        currentCache.push(...newItems)
      },
      // Refetch when the page arg changes
      forceRefetch({ currentArg, previousArg }) {
        return currentArg !== previousArg
      },
    }),
transformErrorResponse Option

Similar to transformResponse, endpoints can now specify a transformErrorResponse option as well.

upsertQueryData Util

RTKQ already has an updateQueryData util to synchronously modify the contents of an existing cache entry, but there was no way to create a new cache entry and its metadata programmatically.

This release adds a new api.util.upsertQueryData API that allows creating a cache entry + its data programmatically. As with the other util methods, this is a thunk that should be dispatched, and you should pass in the exact cache key arg and complete data value you want to insert:

dispatch(
  api.util.upsertQueryData('post', '3', {
    id: '3',
    title: 'All about cheese.',
    contents: 'I love cheese!',
   })
)

The dispatch acts like all other RTKQ requests, so the process is async, and the thunk returns a promise that resolves when the upsert is complete.

RTK Query Performance Improvements

We've significantly rewritten RTK Query's internal implementation to improve performance, especially in cases where many components with query hooks mount at the same time. The middleware has been "flattened" and runs fewer internal checks against each action, subscription updates are grouped together, and some unnecessary memoized selectors have been removed. One consequence is that forgetting to add the RTKQ middleware now throws an error instead of logging a warning.

Overall, RTK Query processing time should be noticeably faster than it was in 1.8.

RTK Query also can take advantage of the new "auto-batch enhancer" (described below) for some additional perf optimization, and we recommend adding that to your Redux store configuration.

fetchBaseQuery Options

fetchBaseQuery has several new options for processing requests:

You can now specify a timeout option for both individual endpoints and fetchBaseQuery . If provided, requests that take longer than this value will automatically abort.

fetchBaseQuery now supports passing the responseHandler and validateStatus options directly to fetchBaseQuery itself, in addition to accepting it as part of specific endpoints. If provided, these options will be applied as defaults to all requests for that API, which simplifies using them on many endpoints. Providing them for endpoints overrides the global option.

You can now specify a jsonContentType string that will be used to set the content-type header for a request with a jsonifiable body that does not have an explicit content-type header. Defaults to "application/json".

You can now specify a isJsonContentType callback that checks to see if the request body or response body should be stringified. The default looks for values like "application/json" and "application/vnd.api+json". You can also now specify responseHandler: 'content-type' to have RTKQ automatically check to see whether a response should be treated as text or JSON.

The prepareHeaders method can now return void and does not have to return headers.

Other RTK Query Changes

The refetch() methods now return a promise that can be awaited.

Query endpoints can now accept a retryCondition callback as an alternative to maxRetries. If you provide retryCondition, it will be called to determine if RTKQ should retry a failed request again.

New Auto-Batching Store Enhancer

There are several different ways to "batch actions" with Redux stores, ranging from reducers to debounced subscriber notifications.

RTK now includes a new autoBatchEnhancer() store enhancer that uses a variation on the "debounced notification" approach, inspired by React's technique of batching renders and determining if an update is low-priority or high-priority.

The enhancer looks for any actions tagged with an action.meta[SHOULD_AUTOBATCH] = true flag, and delays notifying subscribers until a queued callback runs. This means that if multiple "auto-batched" actions are dispatched in a row, there will be only one subscriber notification. However, if any "normal-priority" action without that flag are dispatched before the queued callback runs, the enhancer will notify subscribers immediately instead and ignore the callback.

This allows Redux users to selectively tag certain actions for effective batching behavior, making this purely opt-in on a per-action basis, while retaining normal notification behavior for all other actions.

The enhancer defaults to using requestAnimationFrame, but can also be configured to use queueMicrotask to run at the end of an event loop tick, setTimeout, or a user-provided callback.

RTK Query's internals have been updated to mark several key actions as batchable. While the enhancer is purely opt-in, benchmarks indicate that it can help speed up UI performance with RTK Query, especially when rendering many components with query hooks. We recommend adding this enhancer to your store setup if you're using RTK Query:

  const store = configureStore({
  reducer,
  enhancers: (existingEnhancers) => {
    // Add the autobatch enhancer to the store setup
    return existingEnhancers.concat(autoBatchEnhancer())
  },
})

Additionally, there's a prepareAutoBatched util that can be used to help add the SHOULD_AUTOBATCH flag to actions, designed for use with createSlice:

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 } as CounterState,
  reducers: {
    incrementBatched: {
      // Batched, low-priority
      reducer(state) {
        state.value += 1
      },
      // Use the `prepareAutoBatched` utility to automatically
      // add the `action.meta[SHOULD_AUTOBATCH]` field the enhancer needs
      prepare: prepareAutoBatched<void>(),
    },
    // Not batched, normal priority
    decrementUnbatched(state) {
      state.value -= 1
    },
  },
})
TypeScript Improvements

RTK 1.9 now requires TS 4.2 or greater, and supports through TS 4.9.

The action type strings generated by createAction are now full TS template literals when possible.

There's now a createAsyncThunk.withTypes() method that creates a "pre-typed" version of createAsyncThunk with types like {state, dispatch, extra} baked in. This can be used to simplify customizing createAsyncThunk with the right types once during app setup.

RTK Query now exports TS types for "pre-typed hook results", for cases when you want to wrap the query/mutation hooks in your own code. Additionally, RTKQ also exports BaseQueryApi and exposes TS-only types for endpoint definitions.

configureStore now correctly infers changes to the store shape from any store enhancers, such as adding actual extra fields to store.

RTK now exports additional types from redux-thunk.

Bug Fixes

Manually initiated RTKQ promises should resolve correctly.

Previous API tags are removed before adding new ones, instead of accidentally merging them together.

invalidateTags works correctly when dealing with persisted query state.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.8.6...v1.9.0

v1.8.6

Compare Source

This bugfix release fixes a couple of issues with RTKQ endpoint tags not invalidating correctly, and tweaks the dispatch type inference to handle more variations of arrays.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.8.5...v1.8.6

v1.8.5

Compare Source

This bugfix releas fixes an issue with large keepUnusedDataFor values overflowing JS timers, exports the types for the Redux DevTools Extension option, and and improves behavior of URL string generation.

Changelog

keepUnusedDataFor Timer Fix

keepUnusedDataFor accepts a value in seconds. When there are no more active subscriptions for a piece of data, RTKQ will set a timer using setTimeout, and keepUnusedDataFor * 1000 as the timer value.

We've been advising users that if they want to keep data in the cache forever that they should use a very large value for keepUnusedDataFor, such as 10 years in seconds.

However, it turns out that JS engines use a 32-bit signed int for timers, and 32-bits in milliseconds is only 24.8 days. If a timer is given a value larger than that, it triggers immediately.

We've updated the internal logic to clamp the keepUnusedDataFor value to be between 0 and THIRTY_TWO_BIT_MAX_TIMER_SECONDS - 1.

Note that in RTK 1.9 (coming soon), RTKQ will also accept Infinity as a special keepUnusedDataFor value to indicate cached data should never be expired.

Other Changes

RTK inlines the TS types for the Redux DevTools Extension options to avoid an extra dependency, but the TS type for the options object wasn't exported publicly. We now export the DevToolsEnhancerOptions type.

The logic for generating a final URL has been updated to avoid adding an extra trailing /.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.8.4...v1.8.5

v1.8.4

Compare Source

This bugfix release adds exported TS types for RTKQ hooks for use in wrapping logic, adds useDebugValue to the hooks to improve display in the React DevTools, updates the inlined types for the Redux DevTools options, and fixes an issue in createEntityAdapter that could result in duplicate IDs being stored.

Changelog

RTKQ Hook Result Types

RTK's types heavily rely on inference to minimize the amount of type info users have to provide. However, this can also make it difficult to write functions that wrap calls to RTK APIs.

Some users have asked to have types that help them write "higher-order hooks". RTK now exports types that represent "the return object for a query/mutation hook with a given value": TypedUseQueryHookResult and TypedUseMutationResult. Both require <ResultType, QueryArg, BaseQuery> as generics, like this:

const baseQuery = fetchBaseQuery({url: "https://some.server"});

type CustomHookResult = TypedUseQueryHookResult<MyResultObject, MyArgObject, typeof baseQuery>

const useMyCustomHook = (arg: MyArgObject) : CustomHookResult => {
  return api.useGetSomeDataQuery(arg);
}
Redux DevTools Options Fixes

As of Redux DevTools 3.0, some of field names for custom DevTools options have changed to actionsAllowlist and actionsDenylist. Since we inline the types instead of having a separate dependency, we've updated our TS types to match that. No runtime behavior was changed.

Other Changes

RTKQ hooks now use useDebugValue to give a better preview of the current value in the React DevTools "Component" tab.

The <ApiProvider> component now does a better job of registering and cleaning up focus listeners.

Fixed a bug with createEntityAdapter that could allow duplicate IDs to be added depending on update parameters.

What's Changed

Full Changelog: reduxjs/redux-toolkit@v1.8.3...v1.8.4

v1.8.3

Compare Source

This bugfix release fixes a few minor issues and bits of behavior, including updating the React-Redux peer dep to ^8.0.2 final, stable sorting in createEntityAdapter.updateMany and some initial state handling in createSlice.

Changelog

React-Redux Peer Dep

We'd previously published an RTK build that accepted React-Redux v8 beta as a peer dep (for use with RTK Query). Since React-Redux v8 is out now, we've updated the peer dep to ^8.0.2.

Entity Adapter Updates

Previously, applying updates via createEntityAdapter.updateMany caused sorting order to change. Entities that had the same sorting result should have stayed in the same order relative to each other, but if one of those items had any updates, it would sort to the back of that group. This was due to items being removed from the lookup table and re-added, and since JS engines iterate keys in insertion order, the updated item would now end up compared later than before.

We've reworked the implementation of updateMany to avoid that. This also ended up fixing another issue where multiple update entries targeting the same item ID would only have the first applied.

createSlice Initial State

createSlice now logs an error if initialState is undefined. This is most commonly seen when users misspell initialState. It also has better handling for values that can't be frozen by Immer such as primitives.

RTK Query

Several assorted improvements, including TS types for BaseQuery and checking if the body can actually be safely stringified.

What's Changed

Configuration

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

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, 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 has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.8.0 Update dependency @reduxjs/toolkit to v1.8.1 Mar 31, 2022
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from 4fbbafe to 6797233 Compare March 31, 2022 14:47
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from 6797233 to 2ade14f Compare June 18, 2022 21:03
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.8.1 Update dependency @reduxjs/toolkit to v1.8.2 Jun 18, 2022
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from 2ade14f to cd5fd3a Compare September 25, 2022 21:51
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.8.2 Update dependency @reduxjs/toolkit to v1.8.5 Sep 25, 2022
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from cd5fd3a to 9a29c0f Compare November 20, 2022 10:16
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.8.5 Update dependency @reduxjs/toolkit to v1.9.0 Nov 20, 2022
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from 9a29c0f to 2160b60 Compare March 19, 2023 00:14
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.9.0 Update dependency @reduxjs/toolkit to v1.9.3 Mar 19, 2023
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from 2160b60 to fefd4d6 Compare May 29, 2023 21:54
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.9.3 Update dependency @reduxjs/toolkit to v1.9.5 May 29, 2023
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.9.5 Update dependency @reduxjs/toolkit to v1.9.6 Sep 25, 2023
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from fefd4d6 to 155389b Compare September 25, 2023 02:32
@renovate renovate bot force-pushed the renovate/reduxjs-toolkit-1.x branch from 155389b to 8e120c1 Compare October 5, 2023 05:49
@renovate renovate bot changed the title Update dependency @reduxjs/toolkit to v1.9.6 Update dependency @reduxjs/toolkit to v1.9.7 Oct 5, 2023
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
dependencies renovate
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
0 participants