docs: Fix relative link depth

docs/framework/angular/guides/caching.md

@@ -3,7 +3,7 @@ id: caching
 title: Caching Examples
 ---
 
-> Please thoroughly read the [Important Defaults](../guides/important-defaults) before reading this guide
+> Please thoroughly read the [Important Defaults](./guides/important-defaults) 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 `injectQuery(() => ({ queryKey: ['todos'], queryFn: fetchTodos })` initializes 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/injectQuery) 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/injectQuery) 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 `injectQuery(() => ({ queryKey: ['todos'], queryFn: fetchTodos })` query are destroyed 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/angular/guides/invalidations-from-mutations.md

@@ -40,4 +40,4 @@ export class TodosComponent {
 
 [//]: # 'Example2'
 
-You can wire up your invalidations to happen using any of the callbacks available in the [`injectMutation` function](../guides/mutations)
+You can wire up your invalidations to happen using any of the callbacks available in the [`injectMutation` function](./guides/mutations)

docs/framework/angular/installation.md

@@ -17,4 +17,4 @@ $ pnpm add @tanstack/angular-query-experimental
 $ yarn add @tanstack/angular-query-experimental
 ```
 
-> Wanna give it a spin before you download? Try out the [simple](../examples/angular/simple) or [basic](../examples/angular/basic) examples!
+> Wanna give it a spin before you download? Try out the [simple](./examples/simple) or [basic](./examples/basic) examples!

docs/framework/angular/overview.md

@@ -114,4 +114,4 @@ type Response = {
 
 ## You talked me into it, so what now?
 
-- Learn Angular Query at your own pace with our amazingly thorough [Walkthrough Guide](../installation) and [API Reference](../reference/injectQuery)
+- Learn Angular Query at your own pace with our amazingly thorough [Walkthrough Guide](./installation) and [API Reference](./reference/injectQuery)

docs/framework/angular/quick-start.md

@@ -7,7 +7,7 @@ title: Quick Start
 
 [//]: # 'Example'
 
-If you're looking for a fully functioning example, please have a look at our [basic codesandbox example](../examples/angular/basic)
+If you're looking for a fully functioning example, please have a look at our [basic codesandbox example](./examples/basic)
 
 ### Provide the client to your App
 

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

@@ -5,15 +5,15 @@ title: Advanced Server Rendering
 
 Welcome to the Advanced Server Rendering guide, where you will learn all about using React Query with streaming, Server Components and the Next.js app router.
 
-You might want to read the [Server Rendering & Hydration guide](../guides/ssr) before this one as it teaches the basics for using React Query with SSR, and [Performance & Request Waterfalls](../guides/request-waterfalls) as well as [Prefetching & Router Integration](../guides/prefetching) also contains valuable background.
+You might want to read the [Server Rendering & Hydration guide](./guides/ssr) before this one as it teaches the basics for using React Query with SSR, and [Performance & Request Waterfalls](./guides/request-waterfalls) as well as [Prefetching & Router Integration](./guides/prefetching) also contains valuable background.
 
 Before we start, let's note that while the `initialData` approach outlined in the SSR guide also works with Server Components, we'll focus this guide on the hydration APIs.
 
 ## Server Components & Next.js app router
 
 We won't cover Server Components in depth here, but the short version is that they are components that are guaranteed to _only_ run on the server, both for the initial page view and **also on page transitions**. This is similar to how Next.js `getServerSideProps`/`getStaticProps` and Remix `loader` works, as these also always run on the server but while those can only return data, Server Components can do a lot more. The data part is central to React Query however, so let's focus on that.
 
-How do we take what we learned in the Server Rendering guide about [passing data prefetched in framework loaders to the app](../guides/ssr#using-the-hydration-apis) and apply that to Server Components and the Next.js app router? The best way to start thinking about this is to consider Server Components as "just" another framework loader.
+How do we take what we learned in the Server Rendering guide about [passing data prefetched in framework loaders to the app](./guides/ssr#using-the-hydration-apis) and apply that to Server Components and the Next.js app router? The best way to start thinking about this is to consider Server Components as "just" another framework loader.
 
 ### A quick note on terminology
 
@@ -363,11 +363,11 @@ export function Providers(props: { children: React.ReactNode }) {
 }
 ```
 
-For more information, check out the [NextJs Suspense Streaming Example](../examples/nextjs-suspense-streaming).
+For more information, check out the [NextJs Suspense Streaming Example](./examples/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.
 
-The downside is easiest to explain if we look back at [the complex request waterfall example](../guides/request-waterfalls#code-splitting) in the Performance & Request Waterfalls guide. Server Components with prefetching effectively eliminates the request waterfalls both for the initial page load **and** any subsequent navigation. This prefetch-less approach however will only flatten the waterfalls on the initial page load but ends up the same deep waterfall as the original example on page navigations:
+The downside is easiest to explain if we look back at [the complex request waterfall example](./guides/request-waterfalls#code-splitting) in the Performance & Request Waterfalls guide. Server Components with prefetching effectively eliminates the request waterfalls both for the initial page load **and** any subsequent navigation. This prefetch-less approach however will only flatten the waterfalls on the initial page load but ends up the same deep waterfall as the original example on page navigations:
 
 ```
 1. |> JS for <Feed>

docs/framework/react/guides/caching.md

@@ -3,7 +3,7 @@ id: caching
 title: Caching Examples
 ---
 
-> Please thoroughly read the [Important Defaults](../guides/important-defaults) before reading this guide
+> Please thoroughly read the [Important Defaults](./guides/important-defaults) 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) 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](../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](./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.
 
 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#1-practical-react-query)
+- [React Query as a State Manager](./community/tkdodos-blog#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`](../guides/prefetching)
-  - [Manually place the data into the cache using `queryClient.setQueryData`](../guides/prefetching)
+  - [Prefetch the data using `queryClient.prefetchQuery`](./guides/prefetching)
+  - [Manually place the data into the cache using `queryClient.setQueryData`](./guides/prefetching)
 
 ## 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#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](../guides/mutations)
+You can wire up your invalidations to happen using any of the callbacks available in the [`useMutation` hook](./guides/mutations)

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)
+- [useQueryErrorResetBoundary](./reference/useQueryErrorResetBoundary)
 
 ### `QueryCache.getQuery()` has been replaced by `QueryCache.find()`.