docs: fix internal links

Author: TkDodo

docs/framework/react/community/tkdodos-blog.md

@@ -3,7 +3,7 @@ id: tkdodos-blog
 title: TkDodo's Blog
 ---
 
-TanStack Query maintainer [TkDodo](https://twitter.com/tkdodo) has a series of blog posts about using and working with the library. Some articles show general best practices, but most have an _opinionated_ point of view.
+TanStack Query maintainer [TkDodo](https://bsky.app/profile/tkdodo.eu) has a series of blog posts about using and working with the library. Some articles show general best practices, but most have an _opinionated_ point of view.
 
 ## [#1: Practical React Query](https://tkdodo.eu/blog/practical-react-query)
 

docs/framework/react/guides/advanced-ssr.md

@@ -530,7 +530,7 @@ export default function Posts() {
 
 Now, your `getPosts` function can return e.g. `Temporal` datetime objects and the data will be serialized and deserialized on the client, assuming your transformer can serialize and deserialize those data types.
 
-For more information, check out the [Next.js App with Prefetching Example](../../../../examples/react/nextjs-app-prefetching).
+For more information, check out the [Next.js App with Prefetching Example](../examples/react/nextjs-app-prefetching).
 
 ## Experimental streaming without prefetching in Next.js
 
@@ -597,7 +597,7 @@ export function Providers(props: { children: React.ReactNode }) {
 }
 ```
 
-For more information, check out the [NextJs Suspense Streaming Example](../../../../examples/react/nextjs-suspense-streaming).
+For more information, check out the [NextJs Suspense Streaming Example](../examples/react/nextjs-suspense-streaming).
 
 The big upside is that you no longer need to prefetch queries manually to have SSR work, and it even still streams in the result! This gives you phenomenal DX and lower code complexity.
 

docs/framework/react/guides/caching.md

@@ -3,7 +3,7 @@ id: caching
 title: Caching Examples
 ---
 
-> Please thoroughly read the [Important Defaults](./important-defaults) before reading this guide
+> Please thoroughly read the [Important Defaults](./important-defaults.md) before reading this guide
 
 ## Basic Example
 
@@ -23,7 +23,7 @@ Let's assume we are using the default `gcTime` of **5 minutes** and the default
 - A second instance of `useQuery({ queryKey: ['todos'], queryFn: fetchTodos })` mounts elsewhere.
   - Since the cache already has data for the `['todos']` key from the first query, that data is immediately returned from the cache.
   - The new instance triggers a new network request using its query function.
-    - Note that regardless of whether both `fetchTodos` query functions are identical or not, both queries' [`status`](../reference/useQuery) are updated (including `isFetching`, `isPending`, and other related values) because they have the same query key.
+    - Note that regardless of whether both `fetchTodos` query functions are identical or not, both queries' [`status`](../reference/useQuery.md) are updated (including `isFetching`, `isPending`, and other related values) because they have the same query key.
   - When the request completes successfully, the cache's data under the `['todos']` key is updated with the new data, and both instances are updated with the new data.
 - Both instances of the `useQuery({ queryKey: ['todos'], queryFn: fetchTodos })` query are unmounted and no longer in use.
   - Since there are no more active instances of this query, a garbage collection timeout is set using `gcTime` to delete and garbage collect the query (defaults to **5 minutes**).

docs/framework/react/guides/dependent-queries.md

@@ -90,6 +90,6 @@ const usersMessages = useQueries({
 
 ## A note about performance
 
-Dependent queries by definition constitutes a form of [request waterfall](../../../react/guides/request-waterfalls), which hurts performance. If we pretend both queries take the same amount of time, doing them serially instead of in parallel always takes twice as much time, which is especially hurtful when it happens on a client that has high latency. If you can, it's always better to restructure the backend APIs so that both queries can be fetched in parallel, though that might not always be practically feasible.
+Dependent queries by definition constitutes a form of [request waterfall](./request-waterfalls.md), which hurts performance. If we pretend both queries take the same amount of time, doing them serially instead of in parallel always takes twice as much time, which is especially hurtful when it happens on a client that has high latency. If you can, it's always better to restructure the backend APIs so that both queries can be fetched in parallel, though that might not always be practically feasible.
 
 In the example above, instead of first fetching `getUserByEmail` to be able to `getProjectsByUser`, introducing a new `getProjectsByUserEmail` query would flatten the waterfall.

docs/framework/react/guides/important-defaults.md

@@ -36,7 +36,7 @@ Out of the box, TanStack Query is configured with **aggressive but sane** defaul
 
 Have a look at the following articles from our Community Resources for further explanations of the defaults:
 
-- [Practical React Query](../community/tkdodos-blog#1-practical-react-query)
-- [React Query as a State Manager](../community/tkdodos-blog#10-react-query-as-a-state-manager)
+- [Practical React Query](../community/tkdodos-blog.md#1-practical-react-query)
+- [React Query as a State Manager](../community/tkdodos-blog.md#10-react-query-as-a-state-manager)
 
 [//]: # 'Materials'

docs/framework/react/guides/initial-query-data.md

@@ -8,8 +8,8 @@ There are many ways to supply initial data for a query to the cache before you n
 - Declaratively:
   - Provide `initialData` to a query to prepopulate its cache if empty
 - Imperatively:
-  - [Prefetch the data using `queryClient.prefetchQuery`](../../../react/guides/prefetching)
-  - [Manually place the data into the cache using `queryClient.setQueryData`](../../../react/guides/prefetching)
+  - [Prefetch the data using `queryClient.prefetchQuery`](./prefetching.md)
+  - [Manually place the data into the cache using `queryClient.setQueryData`](./prefetching.md)
 
 ## Using `initialData` to prepopulate a query
 
@@ -170,6 +170,6 @@ const result = useQuery({
 
 ## Further reading
 
-For a comparison between `Initial Data` and `Placeholder Data`, have a look at the [Community Resources](../community/tkdodos-blog#9-placeholder-and-initial-data-in-react-query).
+For a comparison between `Initial Data` and `Placeholder Data`, have a look at the [Community Resources](../community/tkdodos-blog.md#9-placeholder-and-initial-data-in-react-query).
 
 [//]: # 'Materials'

docs/framework/react/guides/invalidations-from-mutations.md

@@ -36,4 +36,4 @@ const mutation = useMutation({
 
 [//]: # 'Example2'
 
-You can wire up your invalidations to happen using any of the callbacks available in the [`useMutation` hook](../mutations)
+You can wire up your invalidations to happen using any of the callbacks available in the [`useMutation` hook](./mutations.md)

docs/framework/react/guides/migrating-to-react-query-3.md

@@ -103,8 +103,8 @@ try {
 
 Together, these provide the same experience as before, but with added control to choose which component trees you want to reset. For more information, see:
 
-- [QueryErrorResetBoundary](../../reference/QueryErrorResetBoundary)
-- [useQueryErrorResetBoundary](../../reference/useQueryErrorResetBoundary)
+- [QueryErrorResetBoundary](../reference/QueryErrorResetBoundary.md)
+- [useQueryErrorResetBoundary](../reference/useQueryErrorResetBoundary.md)
 
 ### `QueryCache.getQuery()` has been replaced by `QueryCache.find()`.
 

docs/framework/react/guides/migrating-to-react-query-4.md

@@ -58,9 +58,9 @@ Please note in the case of `TypeScript` you need to use `tsx` as the parser; oth
 
 ### Query Keys (and Mutation Keys) need to be an Array
 
-In v3, Query and Mutation Keys could be a String or an Array. Internally, React Query has always worked with Array Keys only, and we've sometimes exposed this to consumers. For example, in the `queryFn`, you would always get the key as an Array to make working with [Default Query Functions](../default-query-function) easier.
+In v3, Query and Mutation Keys could be a String or an Array. Internally, React Query has always worked with Array Keys only, and we've sometimes exposed this to consumers. For example, in the `queryFn`, you would always get the key as an Array to make working with [Default Query Functions](./default-query-function.md) easier.
 
-However, we have not followed this concept through to all apis. For example, when using the `predicate` function on [Query Filters](../filters) you would get the raw Query Key. This makes it difficult to work with such functions if you use Query Keys that are mixed Arrays and Strings. The same was true when using global callbacks.
+However, we have not followed this concept through to all apis. For example, when using the `predicate` function on [Query Filters](./filters.md) you would get the raw Query Key. This makes it difficult to work with such functions if you use Query Keys that are mixed Arrays and Strings. The same was true when using global callbacks.
 
 To streamline all apis, we've decided to make all keys Arrays only:
 
@@ -100,7 +100,7 @@ Please note in the case of `TypeScript` you need to use `tsx` as the parser; oth
 
 ### The idle state has been removed
 
-With the introduction of the new [fetchStatus](../queries#fetchstatus) for better offline support, the `idle` state became irrelevant, because `fetchStatus: 'idle'` captures the same state better. For more information, please read [Why two different states](../queries#why-two-different-states).
+With the introduction of the new [fetchStatus](./queries.md#fetchstatus) for better offline support, the `idle` state became irrelevant, because `fetchStatus: 'idle'` captures the same state better. For more information, please read [Why two different states](./queries.md#why-two-different-states).
 
 This will mostly affect `disabled` queries that don't have any `data` yet, as those were in `idle` state before:
 
@@ -110,7 +110,7 @@ This will mostly affect `disabled` queries that don't have any `data` yet, as th
 + fetchStatus: 'idle' // [!code ++]
 ```
 
-Also, have a look at [the guide on dependent queries](../dependent-queries)
+Also, have a look at [the guide on dependent queries](./dependent-queries.md)
 
 #### disabled queries
 
@@ -121,7 +121,7 @@ Due to this change, disabled queries (even temporarily disabled ones) will start
   isInitialLoading // [!code ++]
 ```
 
-See also the guide on [disabling queries](../disabling-queries#isInitialLoading)
+See also the guide on [disabling queries](./disabling-queries.md#isInitialLoading)
 
 ### new API for `useQueries`
 
@@ -142,7 +142,7 @@ The `useQueries` hook now accepts an object with a `queries` prop as its input.
 
 ### Undefined is an illegal cache value for successful queries
 
-In order to make bailing out of updates possible by returning `undefined`, we had to make `undefined` an illegal cache value. This is in-line with other concepts of react-query, for example, returning `undefined` from the [initialData function](../initial-query-data#initial-data-function) will also _not_ set data.
+In order to make bailing out of updates possible by returning `undefined`, we had to make `undefined` an illegal cache value. This is in-line with other concepts of react-query, for example, returning `undefined` from the [initialData function](./initial-query-data.md#initial-data-function) will also _not_ set data.
 
 Further, it is an easy bug to produce `Promise<void>` by adding logging in the queryFn:
 
@@ -156,7 +156,7 @@ This is now disallowed on type level; at runtime, `undefined` will be transforme
 
 ### Queries and mutations, per default, need network connection to run
 
-Please read the [New Features announcement](#proper-offline-support) about online / offline support, and also the dedicated page about [Network mode](../network-mode)
+Please read the [New Features announcement](#proper-offline-support) about online / offline support, and also the dedicated page about [Network mode](./network-mode.md)
 
 Even though React Query is an Async State Manager that can be used for anything that produces a Promise, it is most often used for data fetching in combination with data fetching libraries. That is why, per default, queries and mutations will be `paused` if there is no network connection. If you want to opt-in to the previous behavior, you can globally set `networkMode: offlineFirst` for both queries and mutations:
 
@@ -217,7 +217,7 @@ queryClient.refetchQueries({ queryKey: ['todos'] }, { cancelRefetch: false })
 
 ### Query Filters
 
-A [query filter](../filters) is an object with certain conditions to match a query. Historically, the filter options have mostly been a combination of boolean flags. However, combining those flags can lead to impossible states. Specifically:
+A [query filter](./filters.md) is an object with certain conditions to match a query. Historically, the filter options have mostly been a combination of boolean flags. However, combining those flags can lead to impossible states. Specifically:
 
 ```
 active?: boolean
@@ -242,7 +242,7 @@ The filter defaults to `all`, and you can choose to only match `active` or `inac
 
 #### refetchActive / refetchInactive
 
-[queryClient.invalidateQueries](../../../../reference/QueryClient/#queryclientinvalidatequeries) had two additional, similar flags:
+[queryClient.invalidateQueries](../../../reference/QueryClient.md#queryclientinvalidatequeries) had two additional, similar flags:
 
 ```
 refetchActive: Boolean
@@ -280,7 +280,7 @@ React.useEffect(() => mySideEffectHere(data), [data])
 
 ### `persistQueryClient` and the corresponding persister plugins are no longer experimental and have been renamed
 
-The plugins `createWebStoragePersistor` and `createAsyncStoragePersistor` have been renamed to [`createSyncStoragePersister`](../../plugins/createSyncStoragePersister) and [`createAsyncStoragePersister`](../../plugins/createAsyncStoragePersister) respectively. The interface `Persistor` in `persistQueryClient` has also been renamed to `Persister`. Checkout [this stackexchange](https://english.stackexchange.com/questions/206893/persister-or-persistor) for the motivation of this change.
+The plugins `createWebStoragePersistor` and `createAsyncStoragePersistor` have been renamed to [`createSyncStoragePersister`](../plugins/createSyncStoragePersister.md) and [`createAsyncStoragePersister`](../plugins/createAsyncStoragePersister.md) respectively. The interface `Persistor` in `persistQueryClient` has also been renamed to `Persister`. Checkout [this stackexchange](https://english.stackexchange.com/questions/206893/persister-or-persistor) for the motivation of this change.
 
 Since these plugins are no longer experimental, their import paths have also been updated:
 
@@ -296,7 +296,7 @@ Since these plugins are no longer experimental, their import paths have also bee
 
 ### The `cancel` method on promises is no longer supported
 
-The [old `cancel` method](../query-cancellation#old-cancel-function) that allowed you to define a `cancel` function on promises, which was then used by the library to support query cancellation, has been removed. We recommend to use the [newer API](../query-cancellation) (introduced with v3.30.0) for query cancellation that uses the [`AbortController` API](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) internally and provides you with an [`AbortSignal` instance](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) for your query function to support query cancellation.
+The [old `cancel` method](./query-cancellation.md#old-cancel-function) that allowed you to define a `cancel` function on promises, which was then used by the library to support query cancellation, has been removed. We recommend to use the [newer API](./query-cancellation.md) (introduced with v3.30.0) for query cancellation that uses the [`AbortController` API](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) internally and provides you with an [`AbortSignal` instance](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal) for your query function to support query cancellation.
 
 ### TypeScript
 
@@ -427,7 +427,7 @@ React Query defaults to "tracking" query properties, which should give you a nic
 
 ### Bailing out of updates with setQueryData
 
-When using the [functional updater form of setQueryData](../../../../reference/QueryClient/#queryclientsetquerydata), you can now bail out of the update by returning `undefined`. This is helpful if `undefined` is given to you as `previousValue`, which means that currently, no cached entry exists and you don't want to / cannot create one, like in the example of toggling a todo:
+When using the [functional updater form of setQueryData](../../../reference/QueryClient.md#queryclientsetquerydata), you can now bail out of the update by returning `undefined`. This is helpful if `undefined` is given to you as `previousValue`, which means that currently, no cached entry exists and you don't want to / cannot create one, like in the example of toggling a todo:
 
 ```tsx
 queryClient.setQueryData(['todo', id], (previousTodo) =>

docs/framework/react/guides/migrating-to-v5.md

@@ -218,7 +218,7 @@ useQuery<number, string>({
 })
 ```
 
-For a way to set a different kind of Error globally, see [the TypeScript Guide](../../typescript#registering-a-global-error).
+For a way to set a different kind of Error globally, see [the TypeScript Guide](../typescript.md#registering-a-global-error).
 
 ### eslint `prefer-query-object-syntax` rule is removed
 
@@ -480,7 +480,7 @@ if (queryInfo.data) {
 }
 ```
 
-Here, we are only changing how the UI looks when the mutation is running instead of writing data directly to the cache. This works best if we only have one place where we need to show the optimistic update. For more details, have a look at the [optimistic updates documentation](../optimistic-updates).
+Here, we are only changing how the UI looks when the mutation is running instead of writing data directly to the cache. This works best if we only have one place where we need to show the optimistic update. For more details, have a look at the [optimistic updates documentation](./optimistic-updates.md).
 
 ### Limited, Infinite Queries with new maxPages option
 
@@ -494,21 +494,21 @@ Note that the infinite list must be bi-directional, which requires both `getNext
 
 ### Infinite Queries can prefetch multiple pages
 
-Infinite Queries can be prefetched like regular Queries. Per default, only the first page of the Query will be prefetched and will be stored under the given QueryKey. If you want to prefetch more than one page, you can use the `pages` option. Read the [prefetching guide](../prefetching) for more information.
+Infinite Queries can be prefetched like regular Queries. Per default, only the first page of the Query will be prefetched and will be stored under the given QueryKey. If you want to prefetch more than one page, you can use the `pages` option. Read the [prefetching guide](./prefetching.md) for more information.
 
 ### New `combine` option for `useQueries`
 
-See the [useQueries docs](../../reference/useQueries#combine) for more details.
+See the [useQueries docs](../reference/useQueries.md#combine) for more details.
 
 ### Experimental `fine grained storage persister`
 
-See the [experimental_createPersister docs](../../../react/plugins/createPersister) for more details.
+See the [experimental_createPersister docs](../plugins/createPersister.md) for more details.
 
 [//]: # 'FrameworkSpecificNewFeatures'
 
 ### Typesafe way to create Query Options
 
-See the [TypeScript docs](../../typescript#typing-query-options) for more details.
+See the [TypeScript docs](../typescript.md#typing-query-options) for more details.
 
 ### new hooks for suspense
 
@@ -524,6 +524,6 @@ const { data: post } = useSuspenseQuery({
 
 The experimental `suspense: boolean` flag on the query hooks has been removed.
 
-You can read more about them in the [suspense docs](../suspense).
+You can read more about them in the [suspense docs](./suspense.md).
 
 [//]: # 'FrameworkSpecificNewFeatures'