kjuulh/vidow
1
0
Fork 0
Code Issues 1 Pull Requests 4 Packages Projects Releases Wiki Activity

Update all dependencies #19

Merged
kjuulh merged 1 commits from renovate/all into main 2022-11-04 21:41:47 +01:00
Conversation 0 Commits 1 Files Changed 4 +36 -36
kjuulh commented 2022-11-04 20:53:20 +01:00
Owner
Copy Link

This PR contains the following updates:

Package Type Update Change
@reduxjs/toolkit (source) dependencies minor 1.8.6 -> 1.9.0
@types/react (source) devDependencies patch 18.0.24 -> 18.0.25
clap dependencies patch 4.0.18 -> 4.0.19
react-redux dependencies patch 8.0.4 -> 8.0.5

Release Notes

reduxjs/redux-toolkit

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 TS 4.8.

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: https://github.com/reduxjs/redux-toolkit/compare/v1.8.6...v1.9.0

clap-rs/clap

v4.0.19

Compare Source

Features
  • ColorChoice now implements ValueEnum
reduxjs/react-redux

v8.0.5

Compare Source

This release fixes a few minor TS issues.

What's Changed

Full Changelog: https://github.com/reduxjs/react-redux/compare/v8.0.4...v8.0.5

Configuration

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

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [@reduxjs/toolkit](https://redux-toolkit.js.org) ([source](https://github.com/reduxjs/redux-toolkit)) | dependencies | minor | [`1.8.6` -> `1.9.0`](https://renovatebot.com/diffs/npm/@reduxjs%2ftoolkit/1.8.6/1.9.0) | | [@types/react](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/react) ([source](https://github.com/DefinitelyTyped/DefinitelyTyped)) | devDependencies | patch | [`18.0.24` -> `18.0.25`](https://renovatebot.com/diffs/npm/@types%2freact/18.0.24/18.0.25) | | [clap](https://github.com/clap-rs/clap) | dependencies | patch | `4.0.18` -> `4.0.19` | | [react-redux](https://github.com/reduxjs/react-redux) | dependencies | patch | [`8.0.4` -> `8.0.5`](https://renovatebot.com/diffs/npm/react-redux/8.0.4/8.0.5) | --- ### Release Notes <details> <summary>reduxjs/redux-toolkit</summary> ### [`v1.9.0`](https://github.com/reduxjs/redux-toolkit/releases/tag/v1.9.0) [Compare Source](https://github.com/reduxjs/redux-toolkit/compare/v1.8.6...v1.9.0) 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. ```bash npm i @&#8203;reduxjs/toolkit@latest yarn add @&#8203;reduxjs/toolkit@latest ``` We plan to start work on [RTK 2.0](https://github.com/reduxjs/redux-toolkit/issues/958) 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: ```js 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: ```js 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`**](https://www.npmjs.com/package/@&#8203;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: ```bash 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!** <details> <summary> Object reducer codemod before/after examples </summary> Before: ```js 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: ```js 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); } }) ``` </details> ##### `getRunningOperationPromises` Deprecation and Replacement In [`v1.7.0`](https://github.com/reduxjs/redux-toolkit/releases/tag/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 [#&#8203;2477](https://github.com/reduxjs/redux-toolkit/issues/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: ```diff -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. ```ts 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: ```ts 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: ```ts 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](https://blog.isquaredsoftware.com/2020/01/blogged-answers-redux-batching-techniques/), 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**: ```ts 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`: ```ts 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 TS 4.8. 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 - Add `isJsonContentType` predicate to `fetchBaseQuery` by [@&#8203;msutkowski](https://github.com/msutkowski) in https://github.com/reduxjs/redux-toolkit/pull/2331 - Add `jsonContentType` to `fetchBaseQuery` options by [@&#8203;msutkowski](https://github.com/msutkowski) in https://github.com/reduxjs/redux-toolkit/pull/2403 - Add ThunkMiddleware to the re-exported types from redux-thunk by [@&#8203;orta](https://github.com/orta) in https://github.com/reduxjs/redux-toolkit/pull/2451 - add timeout option to fetchBaseQuery by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2143 - createSlice: use template literal types for action type by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2250 - add types for manually typing hook results in userland code by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2276 - Add 'content-type' ResponseHandler by [@&#8203;taylorkline](https://github.com/taylorkline) in https://github.com/reduxjs/redux-toolkit/pull/2363 - feature : endpoint-specific args serializers by [@&#8203;michal-kurz](https://github.com/michal-kurz) in https://github.com/reduxjs/redux-toolkit/pull/2493 - RFC: add "merge" functionality by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/1059 - Add runtime deprecation warning for reducer object notation by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2591 - feat: Add the ability to type `StoreEnhancers` by [@&#8203;fostyfost](https://github.com/fostyfost) in https://github.com/reduxjs/redux-toolkit/pull/2550 - Batch RTKQ "subscribe on reject" actions, and improve cache collection timer handling by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2599 - add transformErrorReponse to rtkq endpoints by [@&#8203;dreyks](https://github.com/dreyks) in https://github.com/reduxjs/redux-toolkit/pull/1841 - Fix manually initiate()d rtk-query promises by [@&#8203;wesen](https://github.com/wesen) in https://github.com/reduxjs/redux-toolkit/pull/2187 - Implement codemods for createReducer and createSlice builder by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2602 - RFC: Expose endpoint types by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/1646 - add createAsyncThunk.withTypes by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2604 - return promise from query result & hook `refetch` by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2212 - retry condition by http error response by [@&#8203;kahirokunn](https://github.com/kahirokunn) in https://github.com/reduxjs/redux-toolkit/pull/2239 - implemented upsertQueryData functionality per [#&#8203;1720](https://github.com/reduxjs/redux-toolkit/issues/1720) [#&#8203;2007](https://github.com/reduxjs/redux-toolkit/issues/2007) by [@&#8203;barnabasJ](https://github.com/barnabasJ) in https://github.com/reduxjs/redux-toolkit/pull/2266 - Consolidate RTKQ middleware to simplify stack size by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2641 - Try fixing createAsyncThunk issues with TS 4.8 by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2643 - Fix assorted issues with the RTKQ middleware refactor by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2644 - fix `upsertQueryData` race situations by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2646 - Fix upsert by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2669 - Export the BaseQueryApi interface from rtk-query so it can be used as a type in TypeScript without importing from dist/. by [@&#8203;nsthorat](https://github.com/nsthorat) in https://github.com/reduxjs/redux-toolkit/pull/2740 - Fix retryCondition `error`. by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2743 - fix: export ToolkitStore interface from configureStore by [@&#8203;adamhari](https://github.com/adamhari) in https://github.com/reduxjs/redux-toolkit/pull/2750 - reset `dispatchQueued` variable after flushing by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2757 - Add `forceRefetch` to `QueryExtraOptions` by [@&#8203;schadenn](https://github.com/schadenn) in https://github.com/reduxjs/redux-toolkit/pull/2663 - Speed up subscription behavior by tracking state in middleware by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2759 - `prepareHeaders` does not need to return `headers` any more by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2775 - Add `codemods-cli` and rewrite "object reducer" codemods by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2768 - remove alpha compatibility fallbacks by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2777 - fix `skipToken` behaviour in `useQueryState` by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2779 - `fetchBaseQuery`: allow `headers` option by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2778 - \[breaking fix] replace `getRunningOperationPromise(s)` with `getRunning(Query|Queries|Mutation|Mutations)Thunk` by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2481 - General pre-1.9-beta cleanup by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2789 - Convert "middleware not registered" warning into a full error by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2792 - Rework endpoint serializeQueryArgs to allow object/number returns by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2835 - allow for global `responseHandler` and `validateStatus` configuration by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/redux-toolkit/pull/2823 - Fix refetches when sQA returns same value and queryArgs are object by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2844 - Add an auto-batching enhancer that delays low-pri notifications and use with RTKQ by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2846 - Check middleware registration directly to avoid persistence issues by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2850 - Fix "running thunks" types and remove unnecessary RTKQ selectors by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2856 - Make autobatching notification queueing configurable by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2857 - Hopefully final v1.9 tweaks by [@&#8203;markerikson](https://github.com/markerikson) in https://github.com/reduxjs/redux-toolkit/pull/2859 **Full Changelog**: https://github.com/reduxjs/redux-toolkit/compare/v1.8.6...v1.9.0 </details> <details> <summary>clap-rs/clap</summary> ### [`v4.0.19`](https://github.com/clap-rs/clap/blob/HEAD/CHANGELOG.md#&#8203;4019---2022-11-04) [Compare Source](https://github.com/clap-rs/clap/compare/v4.0.18...v4.0.19) ##### Features - `ColorChoice` now implements `ValueEnum` </details> <details> <summary>reduxjs/react-redux</summary> ### [`v8.0.5`](https://github.com/reduxjs/react-redux/releases/tag/v8.0.5) [Compare Source](https://github.com/reduxjs/react-redux/compare/v8.0.4...v8.0.5) This release fixes a few minor TS issues. #### What's Changed - `Provider`: pass state (`S`) generic through to `ProviderProps` by [@&#8203;OliverJAsh](https://github.com/OliverJAsh) in https://github.com/reduxjs/react-redux/pull/1960 - wrap `equalityFn` type in `NoInfer` by [@&#8203;phryneas](https://github.com/phryneas) in https://github.com/reduxjs/react-redux/pull/1965 - Fix wrapped component prop types when passing nullish mapDispatchToProps by [@&#8203;marconi1992](https://github.com/marconi1992) in https://github.com/reduxjs/react-redux/pull/1928 **Full Changelog**: https://github.com/reduxjs/react-redux/compare/v8.0.4...v8.0.5 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4yNDEuMTEiLCJ1cGRhdGVkSW5WZXIiOiIzMi4yNDEuMTEifQ==-->
kjuulh force-pushed renovate/all from b54389a0f2 to d43615a69e 2022-11-04 21:21:07 +01:00 Compare
kjuulh merged commit d43615a69e into main 2022-11-04 21:41:47 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
kjuulh
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kjuulh/vidow#19
Delete Branch "renovate/all"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?