docs: fix TanStack casing

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -98,9 +98,9 @@ body:
   - type: input
     id: rq-version
     attributes:
-      label: Tanstack Query version
+      label: TanStack Query version
       description: |
-        Please let us know the exact version of Tanstack Query you were using when the issue occurred. Please don't just put in "latest", as this is subject to change.
+        Please let us know the exact version of TanStack Query you were using when the issue occurred. Please don't just put in "latest", as this is subject to change.
       placeholder: |
         e.g. v3.30.1
     validations:

docs/react/guides/custom-logger.md

@@ -3,7 +3,7 @@ id: custom-logger
 title: Custom Logger
 ---
 
-If you want to change how information is logged by Tanstack Query, you can set a custom logger when creating a `QueryClient`.
+If you want to change how information is logged by TanStack Query, you can set a custom logger when creating a `QueryClient`.
 
 ```tsx
 const queryClient = new QueryClient({

docs/react/guides/default-query-function.md

@@ -3,7 +3,7 @@ id: default-query-function
 title: Default Query Function
 ---
 
-If you find yourself wishing for whatever reason that you could just share the same query function for your entire app and just use query keys to identify what it should fetch, you can do that by providing a **default query function** to Tanstack Query:
+If you find yourself wishing for whatever reason that you could just share the same query function for your entire app and just use query keys to identify what it should fetch, you can do that by providing a **default query function** to TanStack Query:
 
 [//]: # 'Example'
 

docs/react/guides/disabling-queries.md

@@ -53,7 +53,7 @@ function Todos() {
 
 [//]: # 'Example'
 
-Permanently disabling a query opts out of many great features that Tanstack Query has to offer (like background refetches), and it's also not the idiomatic way. It takes you from the declarative approach (defining dependencies when your query should run) into an imperative mode (fetch whenever I click here). It is also not possible to pass parameters to `refetch`. Oftentimes, all you want is a lazy query that defers the initial fetch:
+Permanently disabling a query opts out of many great features that TanStack Query has to offer (like background refetches), and it's also not the idiomatic way. It takes you from the declarative approach (defining dependencies when your query should run) into an imperative mode (fetch whenever I click here). It is also not possible to pass parameters to `refetch`. Oftentimes, all you want is a lazy query that defers the initial fetch:
 
 ## Lazy Queries
 

docs/react/guides/does-this-replace-client-state.md

@@ -1,18 +1,18 @@
 ---
 id: does-this-replace-client-state
-title: Does Tanstack Query replace Redux, MobX or other global state managers?
+title: Does TanStack Query replace Redux, MobX or other global state managers?
 ---
 
 Well, let's start with a few important items:
 
-- Tanstack Query is a **server-state** library, responsible for managing asynchronous operations between your server and client
-- Redux, MobX, Zustand, etc. are **client-state** libraries that _can be used to store asynchronous data, albeit inefficiently when compared to a tool like Tanstack Query_
+- TanStack Query is a **server-state** library, responsible for managing asynchronous operations between your server and client
+- Redux, MobX, Zustand, etc. are **client-state** libraries that _can be used to store asynchronous data, albeit inefficiently when compared to a tool like TanStack Query_
 
-With those points in mind, the short answer is that Tanstack Query **replaces the boilerplate code and related wiring used to manage cache data in your client-state and replaces it with just a few lines of code.**
+With those points in mind, the short answer is that TanStack Query **replaces the boilerplate code and related wiring used to manage cache data in your client-state and replaces it with just a few lines of code.**
 
-For a vast majority of applications, the truly **globally accessible client state** that is left over after migrating all of your async code to Tanstack Query is usually very tiny.
+For a vast majority of applications, the truly **globally accessible client state** that is left over after migrating all of your async code to TanStack Query is usually very tiny.
 
-> There are still some circumstances where an application might indeed have a massive amount of synchronous client-only state (like a visual designer or music production application), in which case, you will probably still want a client state manager. In this situation it's important to note that **Tanstack Query is not a replacement for local/client state management**. However, you can use Tanstack Query along side most client state managers with zero issues.
+> There are still some circumstances where an application might indeed have a massive amount of synchronous client-only state (like a visual designer or music production application), in which case, you will probably still want a client state manager. In this situation it's important to note that **TanStack Query is not a replacement for local/client state management**. However, you can use TanStack Query along side most client state managers with zero issues.
 
 ## A Contrived Example
 
@@ -29,7 +29,7 @@ const globalState = {
 }
 ```
 
-Currently, the global state manager is caching 4 types of server-state: `projects`, `teams`, `tasks`, and `users`. If we were to move these server-state assets to Tanstack Query, our remaining global state would look more like this:
+Currently, the global state manager is caching 4 types of server-state: `projects`, `teams`, `tasks`, and `users`. If we were to move these server-state assets to TanStack Query, our remaining global state would look more like this:
 
 ```tsx
 const globalState = {
@@ -51,6 +51,6 @@ With all of those things removed, you may ask yourself, **"Is it worth it to kee
 
 **And that's up to you!**
 
-But Tanstack Query's role is clear. It removes asynchronous wiring and boilerplate from your application and replaces it with just a few lines of code.
+But TanStack Query's role is clear. It removes asynchronous wiring and boilerplate from your application and replaces it with just a few lines of code.
 
 What are you waiting for, give it a go already!

docs/react/guides/filters.md

@@ -3,7 +3,7 @@ id: filters
 title: Filters
 ---
 
-Some methods within Tanstack Query accept a `QueryFilters` or `MutationFilters` object.
+Some methods within TanStack Query accept a `QueryFilters` or `MutationFilters` object.
 
 ## `Query Filters`
 

docs/react/guides/important-defaults.md

@@ -3,7 +3,7 @@ id: important-defaults
 title: Important Defaults
 ---
 
-Out of the box, Tanstack Query is configured with **aggressive but sane** defaults. **Sometimes these defaults can catch new users off guard or make learning/debugging difficult if they are unknown by the user.** Keep them in mind as you continue to learn and use Tanstack Query:
+Out of the box, TanStack Query is configured with **aggressive but sane** defaults. **Sometimes these defaults can catch new users off guard or make learning/debugging difficult if they are unknown by the user.** Keep them in mind as you continue to learn and use TanStack Query:
 
 - Query instances via `useQuery` or `useInfiniteQuery` by default **consider cached data as stale**.
 
@@ -15,7 +15,7 @@ Out of the box, Tanstack Query is configured with **aggressive but sane** defaul
   - The network is reconnected
   - The query is optionally configured with a refetch interval
 
-If you see a refetch that you are not expecting, it is likely because you just focused the window and Tanstack Query is doing a [`refetchOnWindowFocus`](../guides/window-focus-refetching). During development, this will probably be triggered more frequently, especially because focusing between the Browser DevTools and your app will also cause a fetch, so be aware of that.
+If you see a refetch that you are not expecting, it is likely because you just focused the window and TanStack Query is doing a [`refetchOnWindowFocus`](../guides/window-focus-refetching). During development, this will probably be triggered more frequently, especially because focusing between the Browser DevTools and your app will also cause a fetch, so be aware of that.
 
 > To change this functionality, you can use options like `refetchOnMount`, `refetchOnWindowFocus`, `refetchOnReconnect` and `refetchInterval`.
 

docs/react/guides/infinite-queries.md

@@ -3,7 +3,7 @@ id: infinite-queries
 title: Infinite Queries
 ---
 
-Rendering lists that can additively "load more" data onto an existing set of data or "infinite scroll" is also a very common UI pattern. Tanstack Query supports a useful version of `useQuery` called `useInfiniteQuery` for querying these types of lists.
+Rendering lists that can additively "load more" data onto an existing set of data or "infinite scroll" is also a very common UI pattern. TanStack Query supports a useful version of `useQuery` called `useInfiniteQuery` for querying these types of lists.
 
 When using `useInfiniteQuery`, you'll notice a few things are different:
 

docs/react/guides/mutations.md

@@ -3,7 +3,7 @@ id: mutations
 title: Mutations
 ---
 
-Unlike queries, mutations are typically used to create/update/delete data or perform server side-effects. For this purpose, Tanstack Query exports a `useMutation` hook.
+Unlike queries, mutations are typically used to create/update/delete data or perform server side-effects. For this purpose, TanStack Query exports a `useMutation` hook.
 
 Here's an example of a mutation that adds a new todo to the server:
 
@@ -266,7 +266,7 @@ try {
 
 ## Retry
 
-By default Tanstack Query will not retry a mutation on error, but it is possible with the `retry` option:
+By default TanStack Query will not retry a mutation on error, but it is possible with the `retry` option:
 
 [//]: # 'Example9'
 

docs/react/guides/network-mode.md

@@ -3,9 +3,9 @@ id: network-mode
 title: Network Mode
 ---
 
-Tanstack Query provides three different network modes to distinguish how [Queries](../guides/queries) and [Mutations](../guides/mutations) should behave if you have no network connection. This mode can be set for each Query / Mutation individually, or globally via the query / mutation defaults.
+TanStack Query provides three different network modes to distinguish how [Queries](../guides/queries) and [Mutations](../guides/mutations) should behave if you have no network connection. This mode can be set for each Query / Mutation individually, or globally via the query / mutation defaults.
 
-Since Tanstack Query is most often used for data fetching in combination with data fetching libraries, the default network mode is [online](#network-mode-online).
+Since TanStack Query is most often used for data fetching in combination with data fetching libraries, the default network mode is [online](#network-mode-online).
 
 ## Network Mode: online
 
@@ -19,25 +19,25 @@ The flags `isFetching` and `isPaused` are derived from this state and exposed fo
 
 > Keep in mind that it might not be enough to check for `loading` state to show a loading spinner. Queries can be in `state: 'loading'`, but `fetchStatus: 'paused'` if they are mounting for the first time, and you have no network connection.
 
-If a query runs because you are online, but you go offline while the fetch is still happening, Tanstack Query will also pause the retry mechanism. Paused queries will then continue to run once you re-gain network connection. This is independent of `refetchOnReconnect` (which also defaults to `true` in this mode), because it is not a `refetch`, but rather a `continue`. If the query has been [cancelled](../guides/query-cancellation) in the meantime, it will not continue.
+If a query runs because you are online, but you go offline while the fetch is still happening, TanStack Query will also pause the retry mechanism. Paused queries will then continue to run once you re-gain network connection. This is independent of `refetchOnReconnect` (which also defaults to `true` in this mode), because it is not a `refetch`, but rather a `continue`. If the query has been [cancelled](../guides/query-cancellation) in the meantime, it will not continue.
 
 ## Network Mode: always
 
-In this mode, Tanstack Query will always fetch and ignore the online / offline state. This is likely the mode you want to choose if you use Tanstack Query in an environment where you don't need an active network connection for your Queries to work - e.g. if you just read from `AsyncStorage`, or if you just want to return `Promise.resolve(5)` from your `queryFn`.
+In this mode, TanStack Query will always fetch and ignore the online / offline state. This is likely the mode you want to choose if you use TanStack Query in an environment where you don't need an active network connection for your Queries to work - e.g. if you just read from `AsyncStorage`, or if you just want to return `Promise.resolve(5)` from your `queryFn`.
 
 - Queries will never be `paused` because you have no network connection.
 - Retries will also not pause - your Query will go to `error` state if it fails.
 - `refetchOnReconnect` defaults to `false` in this mode, because reconnecting to the network is not a good indicator anymore that stale queries should be refetched. You can still turn it on if you want.
 
 ## Network Mode: offlineFirst
 
-This mode is the middle ground between the first two options, where Tanstack Query will run the `queryFn` once, but then pause retries. This is very handy if you have a serviceWorker that intercepts a request for caching like in an [offline-first PWA](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers), or if you use HTTP caching via the [Cache-Control header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#the_cache-control_header).
+This mode is the middle ground between the first two options, where TanStack Query will run the `queryFn` once, but then pause retries. This is very handy if you have a serviceWorker that intercepts a request for caching like in an [offline-first PWA](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Offline_Service_workers), or if you use HTTP caching via the [Cache-Control header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#the_cache-control_header).
 
 In those situations, the first fetch might succeed because it comes from an offline storage / cache. However, if there is a cache miss, the network request will go out and fail, in which case this mode behaves like an `online` query - pausing retries.
 
 ## Devtools
 
-The [Tanstack Query Devtools](../devtools) will show Queries in a `paused` state if they would be fetching, but there is no network connection. There is also a toggle button to _Mock offline behavior_. Please note that this button will _not_ actually mess with your network connection (you can do that in the browser devtools), but it will set the [OnlineManager](../reference/onlineManager) in an offline state.
+The [TanStack Query Devtools](../devtools) will show Queries in a `paused` state if they would be fetching, but there is no network connection. There is also a toggle button to _Mock offline behavior_. Please note that this button will _not_ actually mess with your network connection (you can do that in the browser devtools), but it will set the [OnlineManager](../reference/onlineManager) in an offline state.
 
 ## Signature
 

docs/react/guides/paginated-queries.md

@@ -3,7 +3,7 @@ id: paginated-queries
 title: Paginated / Lagged Queries
 ---
 
-Rendering paginated data is a very common UI pattern and in Tanstack Query, it "just works" by including the page information in the query key:
+Rendering paginated data is a very common UI pattern and in TanStack Query, it "just works" by including the page information in the query key:
 
 [//]: # 'Example'
 ```tsx
@@ -18,7 +18,7 @@ However, if you run this simple example, you might notice something strange:
 
 **The UI jumps in and out of the `success` and `loading` states because each new page is treated like a brand new query.**
 
-This experience is not optimal and unfortunately is how many tools today insist on working. But not Tanstack Query! As you may have guessed, Tanstack Query comes with an awesome feature called `keepPreviousData` that allows us to get around this.
+This experience is not optimal and unfortunately is how many tools today insist on working. But not TanStack Query! As you may have guessed, TanStack Query comes with an awesome feature called `keepPreviousData` that allows us to get around this.
 
 ## Better Paginated Queries with `keepPreviousData`
 

docs/react/guides/parallel-queries.md

@@ -7,7 +7,7 @@ title: Parallel Queries
 
 ## Manual Parallel Queries
 
-When the number of parallel queries does not change, there is **no extra effort** to use parallel queries. Just use any number of Tanstack Query's `useQuery` and `useInfiniteQuery` hooks side-by-side!
+When the number of parallel queries does not change, there is **no extra effort** to use parallel queries. Just use any number of TanStack Query's `useQuery` and `useInfiniteQuery` hooks side-by-side!
 
 [//]: # 'Example'
 
@@ -30,7 +30,7 @@ function App () {
 
 ## Dynamic Parallel Queries with `useQueries`
 
-If the number of queries you need to execute is changing from render to render, you cannot use manual querying since that would violate the rules of hooks. Instead, Tanstack Query provides a `useQueries` hook, which you can use to dynamically execute as many queries in parallel as you'd like.
+If the number of queries you need to execute is changing from render to render, you cannot use manual querying since that would violate the rules of hooks. Instead, TanStack Query provides a `useQueries` hook, which you can use to dynamically execute as many queries in parallel as you'd like.
 
 `useQueries` accepts an **options object** with a **queries key** whose value is an **array of query objects**. It returns an **array of query results**: