update spelling from behaviour to behavior for more consistent docs

Author: tylercaceres

docs/api/actionCreatorMiddleware.mdx

@@ -12,7 +12,7 @@ hide_title: true
 A custom middleware that detects if an action creator has been mistakenly dispatched, instead of being called before dispatching.
 
 A common mistake is to call `dispatch(actionCreator)` instead of `dispatch(actionCreator())`.
-This tends to "work" as the action creator has the static `type` property, but can lead to unexpected behaviour.
+This tends to "work" as the action creator has the static `type` property, but can lead to unexpected behavior.
 
 ## Options
 

docs/api/combineSlices.mdx

@@ -213,7 +213,7 @@ const reducerWithUser = rootReducer.inject(userSlice, {
 ```
 
 This may be useful for hot reload, or "removing" a reducer by replacing it with a function that always returns `null`.
-Note that for predictable behaviour, your types should account for all of the possible reducers you intend to occupy a path.
+Note that for predictable behavior, your types should account for all of the possible reducers you intend to occupy a path.
 
 ```ts no-transpile title="'Removing' a reducer, by replacing it with a no-op function"
 declare module '.' {

docs/rtk-query/api/created-api/hooks.mdx

@@ -460,7 +460,7 @@ type UseQuerySubscriptionResult = {
 
   - `arg`: The argument passed to the query defined in the endpoint.
     You can also pass in `skipToken` here as an alternative way of skipping the query, see [skipToken](#skiptoken)
-  - `options`: A set of options that control the fetching behaviour of the hook
+  - `options`: A set of options that control the fetching behavior of the hook
 
 - **Returns**
   - An object containing a function to `refetch` the data

docs/rtk-query/usage/automated-refetching.mdx

@@ -108,7 +108,7 @@ By declaring these tags as what can possibly be provided to the cache, it enable
 
 ### Providing cache data
 
-Each individual `query` endpoint can have its cached data _provide_ particular tags. Doing so enables a relationship between cached data from one or more query endpoints and the behaviour of one or more mutation endpoints.
+Each individual `query` endpoint can have its cached data _provide_ particular tags. Doing so enables a relationship between cached data from one or more query endpoints and the behavior of one or more mutation endpoints.
 
 The `providesTags` property on a `query` endpoint is used for this purpose.
 
@@ -237,7 +237,7 @@ In order to provide stronger control over invalidating the appropriate data, you
 
 ### Invalidating cache data
 
-Each individual mutation endpoint can `invalidate` particular tags for existing cached data. Doing so enables a relationship between cached data from one or more query endpoints and the behaviour of one or more mutation endpoints.
+Each individual mutation endpoint can `invalidate` particular tags for existing cached data. Doing so enables a relationship between cached data from one or more query endpoints and the behavior of one or more mutation endpoints.
 
 The `invalidatesTags` property on a mutation endpoint is used for this purpose.
 
@@ -621,7 +621,7 @@ A powerful use-case is to use an ID like `'LIST'` as a label for data provided b
 
 :::
 
-We can compare the scenarios below to see how using a `'LIST'` id can be leveraged to optimize behaviour.
+We can compare the scenarios below to see how using a `'LIST'` id can be leveraged to optimize behavior.
 
 #### Invalidating everything of a type
 
@@ -774,7 +774,7 @@ If you intend for the `addPost` mutation to refresh all posts including individu
 
 The information provided to the cache is not limited to successful data fetches. The concept can be used to inform RTK Query that when a particular failure has been encountered, to `provide` a specific `tag` for that failed cache data. A separate endpoint can then `invalidate` the data for that `tag`, telling RTK Query to re-attempt the previously failed endpoints if a component is still subscribed to the failed data.
 
-The example below demonstrates an example with the following behaviour:
+The example below demonstrates an example with the following behavior:
 
 - Provides an `UNAUTHORIZED` cache tag if a query fails with an error code of `401 UNAUTHORIZED`
 - Provides an `UNKNOWN_ERROR` cache tag if a query fails with a different error

docs/rtk-query/usage/cache-behavior.mdx

@@ -12,7 +12,7 @@ description: 'RTK Query > Usage > Cache Behavior: defaults, cache lifetimes, and
 
 A key feature of RTK Query is its management of cached data. When data is fetched from the server, RTK Query will store the data in the Redux store as a 'cache'. When an additional request is performed for the same data, RTK Query will provide the existing cached data rather than sending an additional request to the server.
 
-RTK Query provides a number of concepts and tools to manipulate the cache behaviour and adjust it to your needs.
+RTK Query provides a number of concepts and tools to manipulate the cache behavior and adjust it to your needs.
 
 ## Default Cache Behavior
 
@@ -73,7 +73,7 @@ If 'ComponentThree' is unmounted in the example above, regardless of how much ti
 
 ## Manipulating Cache Behavior
 
-On top of the default behaviour, RTK Query provides a number of methods to re-fetch data earlier in scenarios where it should be considered invalid, or is otherwise deemed suitable to be 'refreshed'.
+On top of the default behavior, RTK Query provides a number of methods to re-fetch data earlier in scenarios where it should be considered invalid, or is otherwise deemed suitable to be 'refreshed'.
 
 ### Reducing subscription time with `keepUnusedDataFor`
 

docs/rtk-query/usage/customizing-queries.mdx

@@ -18,7 +18,7 @@ The default method to handle queries is via the [`baseQuery`](../api/createApi#b
 
 To process queries, endpoints are defined with a [`query`](../api/createApi.mdx#query) option, which passes its return value to a common [`baseQuery`](../api/createApi#basequery) function used for the API.
 
-By default, RTK Query ships with [`fetchBaseQuery`](../api/fetchBaseQuery), which is a lightweight [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) wrapper that automatically handles request headers and response parsing in a manner similar to common libraries like `axios`. If `fetchBaseQuery` alone does not meet your needs, you can customize its behaviour with a wrapper function, or create your own [`baseQuery`](../api/createApi.mdx#basequery) function from scratch for [`createApi`](../api/createApi) to use.
+By default, RTK Query ships with [`fetchBaseQuery`](../api/fetchBaseQuery), which is a lightweight [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) wrapper that automatically handles request headers and response parsing in a manner similar to common libraries like `axios`. If `fetchBaseQuery` alone does not meet your needs, you can customize its behavior with a wrapper function, or create your own [`baseQuery`](../api/createApi.mdx#basequery) function from scratch for [`createApi`](../api/createApi) to use.
 
 See also [`baseQuery API Reference`](../api/createApi.mdx#basequery).
 
@@ -263,15 +263,15 @@ RTK Query comes with `fetchBaseQuery` out of the box, which makes it straightfor
 
 RTK Query supports defining endpoints that run arbitrary async logic and return a result. Individual endpoints on [`createApi`](../api/createApi.mdx) accept a [`queryFn`](../api/createApi.mdx#queryfn) property, which let you write your own async function with whatever logic you want inside.
 
-This can be useful for scenarios where you want to have particularly different behaviour for a single endpoint, or where the query itself is not relevant, including:
+This can be useful for scenarios where you want to have particularly different behavior for a single endpoint, or where the query itself is not relevant, including:
 
 - One-off queries that use a different base URL
 - One-off queries that use different request handling, such as automatic re-tries
-- One-off queries that use different error handling behaviour
+- One-off queries that use different error handling behavior
 - Queries that make requests using a third-party library SDK, such as Firebase or Supabase
 - Queries that perform async tasks that are not a typical request/response
 - Performing multiple requests with a single query ([example](#performing-multiple-requests-with-a-single-query))
-- Leveraging invalidation behaviour with no relevant query ([example](#using-a-no-op-queryfn))
+- Leveraging invalidation behavior with no relevant query ([example](#using-a-no-op-queryfn))
 - Using [Streaming Updates](./streaming-updates) with no relevant initial request ([example](#streaming-data-with-no-initial-request))
 
 See also [`queryFn API Reference`](../api/createApi.mdx#queryfn) for the type signature and available options.
@@ -1015,7 +1015,7 @@ const api = createApi({
     refetchPostsAndUsers: build.mutation<null, void>({
       // The query is not relevant here, so a `null` returning `queryFn` is used
       queryFn: () => ({ data: null }),
-      // This mutation takes advantage of tag invalidation behaviour to trigger
+      // This mutation takes advantage of tag invalidation behavior to trigger
       // any queries that provide the 'Post' or 'User' tags to re-fetch if the queries
       // are currently subscribed to the cached data
       invalidatesTags: ['Post', 'User'],

docs/rtk-query/usage/migrating-to-rtk-query.mdx

@@ -22,7 +22,7 @@ The most common use case for side effects in Redux apps is fetching data. Redux
 
 RTK Query is purpose-built to solve the use case of data fetching. While it can't replace all of the situations where you'd use thunks or other side effects approaches, **using RTK Query should eliminate the need for most of that hand-written side effects logic**.
 
-RTK Query is expected to cover a lot of overlapping behaviour that users may have previously used `createAsyncThunk` for, including caching purposes, and request lifecycle management (e.g. `isUninitialized`, `isLoading`, `isError` states).
+RTK Query is expected to cover a lot of overlapping behavior that users may have previously used `createAsyncThunk` for, including caching purposes, and request lifecycle management (e.g. `isUninitialized`, `isLoading`, `isError` states).
 
 In order to migrate data-fetching features from existing Redux tools to RTK Query, the appropriate endpoints should be added to an RTK Query API slice, and the previous feature code deleted. This generally will not include much common code kept between the two, as the tools work differently and one will replace the other.
 
@@ -271,7 +271,7 @@ export function useGetPokemonByNameQuery(name: string) {
 
 Our code above meets all of the design specifications, so let's use it! Below we can see how the hook can be called in a component, and return the relevant data & status booleans.
 
-Our implementation below provides the following behaviour in the component:
+Our implementation below provides the following behavior in the component:
 
 - When our component is mounted, if a request for the provided pokemon name has not already been sent for the session, send the request off
 - The hook always provides the latest received `data` when available, as well as the request status booleans `isUninitialized`, `isPending`, `isFulfilled` & `isRejected` in order to determine the current UI at any given moment as a function of our state.

docs/rtk-query/usage/persistence-and-rehydration.mdx

@@ -21,7 +21,7 @@ See also [Server Side Rendering](./server-side-rendering.mdx).
 
 Generally, persisting API slices is not recommended and instead, mechanisms like
 [`Cache-Control` Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)
-should be used in browsers to define cache behaviour.
+should be used in browsers to define cache behavior.
 Persisting and rehydrating an api slice might always leave the user with very stale data if the user
 has not visited the page for some time.
 Nonetheless, in environments like Native Apps, where there is no browser cache to take care of this,

docs/rtk-query/usage/queries.mdx

@@ -330,7 +330,7 @@ function PostsList() {
 }
 ```
 
-To summarize the above behaviour - the returned values must be correctly memoized. See also [Deriving Data with Selectors](https://redux.js.org/usage/deriving-data-selectors) and [Redux Essentials - RTK Query Advanced Patterns](https://redux.js.org/tutorials/essentials/part-8-rtk-query-advanced#selecting-values-from-results) for additional information.
+To summarize the above behavior - the returned values must be correctly memoized. See also [Deriving Data with Selectors](https://redux.js.org/usage/deriving-data-selectors) and [Redux Essentials - RTK Query Advanced Patterns](https://redux.js.org/tutorials/essentials/part-8-rtk-query-advanced#selecting-values-from-results) for additional information.
 
 ### Avoiding unnecessary requests
 

docs/rtk-query/usage/usage-without-react-hooks.mdx

@@ -55,7 +55,7 @@ The `endpoint.select(arg)` function creates a _new_ selector instance - it isn't
 
 :::
 
-With React hooks, this behaviour is instead handled within [`useQuery`](../api/created-api/hooks.mdx#usequery), [`useQueryState`](../api/created-api/hooks.mdx#usequerystate), and [`useLazyQuery`](../api/created-api/hooks.mdx#uselazyquery).
+With React hooks, this behavior is instead handled within [`useQuery`](../api/created-api/hooks.mdx#usequery), [`useQueryState`](../api/created-api/hooks.mdx#usequerystate), and [`useLazyQuery`](../api/created-api/hooks.mdx#uselazyquery).
 
 ```ts title="Accessing cached data & request status" no-transpile
 const result = api.endpoints.getPosts.select()(state)