docs: Change docs code-snippet types to tsx (TanStack#3857)

* Change docs code-snippet types to tsx

The tanstack.com site shows the code-snippets as `bash` as a fallback,
as js is not expected as a language type. (see
[here](https://github.com/TanStack/tanstack.com/blob/main/app/components/CodeBlock.tsx)
for allowed language types).

In addition to allowing JS as a snippet type (TanStack/tanstack.com#17),
changing the documentation to be `tsx` ensures that syntax
highlighting and the language type appears correct.

* Apply suggestions from code review

* Update docs/guides/disabling-queries.md

Co-authored-by: Dominik Dorfmeister <[email protected]>

docs/devtools.md

@@ -21,7 +21,7 @@ $ yarn add @tanstack/react-query-devtools
 
 You can import the devtools like this:
 
-```js
+```tsx
 import { ReactQueryDevtools } from '@tanstack/react-query-devtools'
 ```
 
@@ -33,7 +33,7 @@ Floating Mode will mount the devtools as a fixed, floating element in your app a
 
 Place the following code as high in your React app as you can. The closer it is to the root of the page, the better it will work!
 
-```js
+```tsx
 import { ReactQueryDevtools } from '@tanstack/react-query-devtools'
 
 function App() {
@@ -66,7 +66,7 @@ function App() {
 
 Embedded Mode will embed the devtools as a regular component in your application. You can style it however you'd like after that!
 
-```js
+```tsx
 import { ReactQueryDevtoolsPanel } from '@tanstack/react-query-devtools'
 
 function App() {

docs/guides/background-fetching-indicators.md

@@ -5,7 +5,7 @@ title: Background Fetching Indicators
 
 A query's `status === 'loading'` state is sufficient enough to show the initial hard-loading state for a query, but sometimes you may want to display an additional indicator that a query is refetching in the background. To do this, queries also supply you with an `isFetching` boolean that you can use to show that it's in a fetching state, regardless of the state of the `status` variable:
 
-```js
+```tsx
 function Todos() {
   const { status, data: todos, error, isFetching } = useQuery(
     'todos',
@@ -34,7 +34,7 @@ function Todos() {
 
 In addition to individual query loading states, if you would like to show a global loading indicator when **any** queries are fetching (including in the background), you can use the `useIsFetching` hook:
 
-```js
+```tsx
 import { useIsFetching } from '@tanstack/react-query'
 
 function GlobalLoadingIndicator() {

docs/guides/custom-logger.md

@@ -5,7 +5,7 @@ title: Custom Logger
 
 If you want to change how information is logged by React Query, you can set a custom logger when creating a `QueryClient`.
 
-```js
+```tsx
 const queryClient = new QueryClient({
   logger: {
     log: (...args) => {

docs/guides/default-query-function.md

@@ -5,7 +5,7 @@ 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 React Query:
 
-```js
+```tsx
 // Define a default query function that will receive the query key
 const defaultQueryFn = async ({ queryKey }) => {
   const { data } = await axios.get(`https://jsonplaceholder.typicode.com${queryKey[0]}`);

docs/guides/dependent-queries.md

@@ -5,7 +5,7 @@ title: Dependent Queries
 
 Dependent (or serial) queries depend on previous ones to finish before they can execute. To achieve this, it's as easy as using the `enabled` option to tell a query when it is ready to run:
 
-```js
+```tsx
 // Get the user
 const { data: user } = useQuery(['user', email], getUserByEmail)
 
@@ -24,21 +24,21 @@ const { status, fetchStatus, data: projects } = useQuery(
 
 The `projects` query will start in:
 
-```js
+```tsx
 status: 'loading'
 fetchStatus: 'idle'
 ```
 
 As soon as the `user` is available, the `projects` query will be `enabled` and will then transition to:
 
-```js
+```tsx
 status: 'loading'
 fetchStatus: 'fetching'
 ```
 
 Once we have the projects, it will go to:
 
-```js
+```tsx
 status: 'success'
 fetchStatus: 'idle'
 ```

docs/guides/disabling-queries.md

@@ -16,7 +16,7 @@ When `enabled` is `false`:
 - The query will ignore query client `invalidateQueries` and `refetchQueries` calls that would normally result in the query refetching.
 - `refetch` returned from `useQuery` can be used to manually trigger the query to fetch.
 
-```jsx
+```tsx
 function Todos() {
   const {
     isLoading,
@@ -65,7 +65,7 @@ Permanently disabling a query opts out of many great features that react-query h
 
 The enabled option can not only be used to permenantly disable a query, but also to enable / disable it at a later time. A good example would be a filter form where you only want to fire off the first request once the user has entered a filter value:
 
-```jsx
+```tsx
 function Todos() {
   const [filter, setFilter] = React.useState('')
 

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

@@ -18,7 +18,7 @@ For a vast majority of applications, the truly **globally accessible client stat
 
 Here we have some "global" state being managed by a global state library:
 
-```js
+```tsx
 const globalState = {
   projects,
   teams,
@@ -31,7 +31,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 React Query, our remaining global state would look more like this:
 
-```js
+```tsx
 const globalState = {
   themeMode,
   sidebarStatus,

docs/guides/filters.md

@@ -9,7 +9,7 @@ Some methods within React Query accept a `QueryFilters` or `MutationFilters` obj
 
 A query filter is an object with certain conditions to match a query with:
 
-```js
+```tsx
 // Cancel all queries
 await queryClient.cancelQueries()
 
@@ -47,7 +47,7 @@ A query filter object supports the following properties:
 
 A mutation filter is an object with certain conditions to match a mutation with:
 
-```js
+```tsx
 // Get the number of all fetching mutations
 await queryClient.isMutating()
 

docs/guides/infinite-queries.md

@@ -22,7 +22,7 @@ When using `useInfiniteQuery`, you'll notice a few things are different:
 
 Let's assume we have an API that returns pages of `projects` 3 at a time based on a `cursor` index along with a cursor that can be used to fetch the next group of projects:
 
-```js
+```tsx
 fetch('/api/projects?cursor=0')
 // { data: [...], nextCursor: 3}
 fetch('/api/projects?cursor=3')
@@ -41,7 +41,7 @@ With this information, we can create a "Load More" UI by:
 
 > Note: It's very important you do not call `fetchNextPage` with arguments unless you want them to override the `pageParam` data returned from the `getNextPageParam` function. e.g. Do not do this: `<button onClick={fetchNextPage} />` as this would send the onClick event to the `fetchNextPage` function.
 
-```js
+```tsx
 import { useInfiniteQuery } from '@tanstack/react-query'
 
 function Projects() {
@@ -99,7 +99,7 @@ When an infinite query becomes `stale` and needs to be refetched, each group is
 
 If you only want to actively refetch a subset of all pages, you can pass the `refetchPage` function to `refetch` returned from `useInfiniteQuery`.
 
-```js
+```tsx
 const { refetch } = useInfiniteQuery(['projects'], fetchProjects, {
   getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
 })
@@ -120,7 +120,7 @@ The function is executed for each page, and only pages where this function retur
 
 By default, the variable returned from `getNextPageParam` will be supplied to the query function, but in some cases, you may want to override this. You can pass custom variables to the `fetchNextPage` function which will override the default variable like so:
 
-```js
+```tsx
 function Projects() {
   const fetchProjects = ({ pageParam = 0 }) =>
     fetch('/api/projects?cursor=' + pageParam)
@@ -145,7 +145,7 @@ function Projects() {
 
 Bi-directional lists can be implemented by using the `getPreviousPageParam`, `fetchPreviousPage`, `hasPreviousPage` and `isFetchingPreviousPage` properties and functions.
 
-```js
+```tsx
 useInfiniteQuery(['projects'], fetchProjects, {
   getNextPageParam: (lastPage, pages) => lastPage.nextCursor,
   getPreviousPageParam: (firstPage, pages) => firstPage.prevCursor,
@@ -156,7 +156,7 @@ useInfiniteQuery(['projects'], fetchProjects, {
 
 Sometimes you may want to show the pages in reversed order. If this is case, you can use the `select` option:
 
-```js
+```tsx
 useInfiniteQuery(['projects'], fetchProjects, {
   select: data => ({
     pages: [...data.pages].reverse(),
@@ -169,7 +169,7 @@ useInfiniteQuery(['projects'], fetchProjects, {
 
 Manually removing first page:
 
-```js
+```tsx
 queryClient.setQueryData(['projects'], data => ({
   pages: data.pages.slice(1),
   pageParams: data.pageParams.slice(1),
@@ -178,7 +178,7 @@ queryClient.setQueryData(['projects'], data => ({
 
 Manually removing a single value from an individual page:
 
-```js
+```tsx
 const newPagesArray = oldPagesArray?.pages.map((page) =>
   page.filter((val) => val.id !== updatedId)
 ) ?? []

docs/guides/initial-query-data.md

@@ -17,7 +17,7 @@ There may be times when you already have the initial data for a query available
 
 > IMPORTANT: `initialData` is persisted to the cache, so it is not recommended to provide placeholder, partial or incomplete data to this option and instead use `placeholderData`
 
-```js
+```tsx
 function Todos() {
   const result = useQuery(['todos'], () => fetch('/todos'), {
     initialData: initialTodos,
@@ -31,7 +31,7 @@ By default, `initialData` is treated as totally fresh, as if it were just fetche
 
 - If you configure your query observer with `initialData`, and no `staleTime` (the default `staleTime: 0`), the query will immediately refetch when it mounts:
 
-  ```js
+  ```tsx
   function Todos() {
     // Will show initialTodos immediately, but also immediately refetch todos after mount
     const result = useQuery(['todos'], () => fetch('/todos'), {
@@ -42,7 +42,7 @@ By default, `initialData` is treated as totally fresh, as if it were just fetche
 
 - If you configure your query observer with `initialData` and a `staleTime` of `1000` ms, the data will be considered fresh for that same amount of time, as if it was just fetched from your query function.
 
-  ```js
+  ```tsx
   function Todos() {
     // Show initialTodos immediately, but won't refetch until another interaction event is encountered after 1000 ms
     const result = useQuery(['todos'], () => fetch('/todos'), {
@@ -53,7 +53,7 @@ By default, `initialData` is treated as totally fresh, as if it were just fetche
   ```
 
 - So what if your `initialData` isn't totally fresh? That leaves us with the last configuration that is actually the most accurate and uses an option called `initialDataUpdatedAt`. This option allows you to pass a numeric JS timestamp in milliseconds of when the initialData itself was last updated, e.g. what `Date.now()` provides. Take note that if you have a unix timestamp, you'll need to convert it to a JS timestamp by multiplying it by `1000`.
-  ```js
+  ```tsx
   function Todos() {
     // Show initialTodos immediately, but won't refetch until another interaction event is encountered after 1000 ms
     const result = useQuery(['todos'], () => fetch('/todos'), {
@@ -72,7 +72,7 @@ By default, `initialData` is treated as totally fresh, as if it were just fetche
 
 If the process for accessing a query's initial data is intensive or just not something you want to perform on every render, you can pass a function as the `initialData` value. This function will be executed only once when the query is initialized, saving you precious memory and/or CPU:
 
-```js
+```tsx
 function Todos() {
   const result = useQuery(['todos'], () => fetch('/todos'), {
     initialData: () => {
@@ -86,7 +86,7 @@ function Todos() {
 
 In some circumstances, you may be able to provide the initial data for a query from the cached result of another. A good example of this would be searching the cached data from a todos list query for an individual todo item, then using that as the initial data for your individual todo query:
 
-```js
+```tsx
 function Todo({ todoId }) {
   const result = useQuery(['todo', todoId], () => fetch('/todos'), {
     initialData: () => {
@@ -101,7 +101,7 @@ function Todo({ todoId }) {
 
 Getting initial data from the cache means the source query you're using to look up the initial data from is likely old, but `initialData`. Instead of using an artificial `staleTime` to keep your query from refetching immediately, it's suggested that you pass the source query's `dataUpdatedAt` to `initialDataUpdatedAt`. This provides the query instance with all the information it needs to determine if and when the query needs to be refetched, regardless of initial data being provided.
 
-```js
+```tsx
 function Todo({ todoId }) {
   const result = useQuery(['todo', todoId], () => fetch(`/todos/${todoId}`), {
     initialData: () =>
@@ -116,7 +116,7 @@ function Todo({ todoId }) {
 
 If the source query you're using to look up the initial data from is old, you may not want to use the cached data at all and just fetch from the server. To make this decision easier, you can use the `queryClient.getQueryState` method instead to get more information about the source query, including a `state.dataUpdatedAt` timestamp you can use to decide if the query is "fresh" enough for your needs:
 
-```js
+```tsx
 function Todo({ todoId }) {
   const result = useQuery(['todo', todoId], () => fetch(`/todos/${todoId}`), {
     initialData: () => {

docs/guides/invalidations-from-mutations.md

@@ -7,13 +7,13 @@ Invalidating queries is only half the battle. Knowing **when** to invalidate the
 
 For example, assume we have a mutation to post a new todo:
 
-```js
+```tsx
 const mutation = useMutation(postTodo)
 ```
 
 When a successful `postTodo` mutation happens, we likely want all `todos` queries to get invalidated and possibly refetched to show the new todo item. To do this, you can use `useMutation`'s `onSuccess` options and the `client`'s `invalidateQueries` function:
 
-```js
+```tsx
 import { useMutation, useQueryClient } from '@tanstack/react-query'
 
 const queryClient = useQueryClient()