chore: website rspress

website/docs/12.x/cookbook/basics/async-tests.md

@@ -5,7 +5,7 @@
 Typically, you would write synchronous tests, as they are simple and get the work done. However, there are cases when using asynchronous (async) tests might be necessary or beneficial. The two most common cases are:
 
 1. **Testing Code with asynchronous operations**: When your code relies on asynchronous operations, such as network calls or database queries, async tests are essential. Even though you should mock these network calls, the mock should act similarly to the actual behavior and hence by async.
-2. **UserEvent API:** Using the [User Event API](docs/api/events/user-event) in your tests creates more realistic event handling. These interactions introduce delays (even though these are typically event-loop ticks with 0 ms delays), requiring async tests to handle the timing correctly.
+2. **UserEvent API:** Using the [User Event API](/docs/api/events/user-event) in your tests creates more realistic event handling. These interactions introduce delays (even though these are typically event-loop ticks with 0 ms delays), requiring async tests to handle the timing correctly.
 
 Using async tests when needed ensures your tests are reliable and simulate real-world conditions accurately.
 
@@ -45,9 +45,9 @@ There are several asynchronous utilities you might use in your tests.
 
 ### `findBy*` queries
 
-The most common are the [`findBy*` queries](docs/api/queries#find-by). These are useful when waiting for a matching element to appear. They can be understood as a [`getBy*` queries](docs/api/queries#get-by) used in conjunction with a [`waitFor` function](docs/api/misc/async#waitfor).
+The most common are the [`findBy*` queries](/docs/api/queries#find-by). These are useful when waiting for a matching element to appear. They can be understood as a [`getBy*` queries](/docs/api/queries#get-by) used in conjunction with a [`waitFor` function](/docs/api/misc/async#waitfor).
 
-They accept the same predicates as `getBy*` queries like `findByRole`, `findByTest`, etc. They also have a multiple elements variant called [`findAllBy*`](docs/api/queries#find-all-by).
+They accept the same predicates as `getBy*` queries like `findByRole`, `findByTest`, etc. They also have a multiple elements variant called [`findAllBy*`](/docs/api/queries#find-all-by).
 
 ```typescript
 function findByRole: (
@@ -71,7 +71,7 @@ Each query has a default `timeout` value of 1000 ms and a default `interval` of
 const button = await screen.findByRole('button'), { name: 'Start' }, { timeout: 1000, interval: 50 });
 ```
 
-Alternatively, a default global `timeout` value can be set using the [`configure` function](docs/api/misc/config#configure):
+Alternatively, a default global `timeout` value can be set using the [`configure` function](/docs/api/misc/config#configure):
 
 ```typescript
 configure({ asyncUtilTimeout: timeout });
@@ -103,7 +103,7 @@ If you want to use it with `getBy*` queries, use the `findBy*` queries instead,
 
 ### `waitForElementToBeRemoved` function
 
-A specialized function, [`waitForElementToBeRemoved`](docs/api/misc/async#waitforelementtoberemoved), is used to verify that a matching element was present but has since been removed.
+A specialized function, [`waitForElementToBeRemoved`](/docs/api/misc/async#waitforelementtoberemoved), is used to verify that a matching element was present but has since been removed.
 
 ```typescript
 function waitForElementToBeRemoved<T>(

website/docs/12.x/docs/api.md

@@ -6,17 +6,17 @@ uri: /api
 
 React Native Testing Library consists of following APIs:
 
-- [`render` function](docs/api/render) - render your UI components for testing purposes
-- [`screen` object](docs/api/screen) - access rendered UI:
-  - [Queries](docs/api/queries) - find relevant components by various predicates: role, text, test ids, etc
-  - Lifecycle methods: [`rerender`](docs/api/screen#rerender), [`unmount`](docs/api/screen#unmount)
-  - Helpers: [`debug`](docs/api/screen#debug), [`toJSON`](docs/api/screen#tojson), [`root`](docs/api/screen#root)
-- [Jest matchers](docs/api/jest-matchers) - validate assumptions about your UI
-- [User Event](docs/api/events/user-event) - simulate common user interactions like [`press`](docs/api/events/user-event#press) or [`type`](docs/api/events/user-event#type) in a realistic way
-- [Fire Event](docs/api/events/fire-event) - simulate any component event in a simplified way purposes
+- [`render` function](/docs/api/render) - render your UI components for testing purposes
+- [`screen` object](/docs/api/screen) - access rendered UI:
+  - [Queries](/docs/api/queries) - find relevant components by various predicates: role, text, test ids, etc
+  - Lifecycle methods: [`rerender`](/docs/api/screen#rerender), [`unmount`](/docs/api/screen#unmount)
+  - Helpers: [`debug`](/docs/api/screen#debug), [`toJSON`](/docs/api/screen#tojson), [`root`](/docs/api/screen#root)
+- [Jest matchers](/docs/api/jest-matchers) - validate assumptions about your UI
+- [User Event](/docs/api/events/user-event) - simulate common user interactions like [`press`](/docs/api/events/user-event#press) or [`type`](/docs/api/events/user-event#type) in a realistic way
+- [Fire Event](/docs/api/events/fire-event) - simulate any component event in a simplified way purposes
 - Misc APIs:
-  - [`renderHook` function](docs/api/misc/render-hook) - render hooks for testing
-  - [Async utils](docs/api/misc/async): `findBy*` queries, `wait`, `waitForElementToBeRemoved`
-  - [Configuration](docs/api/misc/config): `configure`, `resetToDefaults`
-  - [Accessibility](docs/api/misc/accessibility): `isHiddenFromAccessibility`
-  - [Other](docs/api/misc/other): `within`, `act`, `cleanup`
+  - [`renderHook` function](/docs/api/misc/render-hook) - render hooks for testing
+  - [Async utils](/docs/api/misc/async): `findBy*` queries, `wait`, `waitForElementToBeRemoved`
+  - [Configuration](/docs/api/misc/config): `configure`, `resetToDefaults`
+  - [Accessibility](/docs/api/misc/accessibility): `isHiddenFromAccessibility`
+  - [Other](/docs/api/misc/other): `within`, `act`, `cleanup`

website/docs/12.x/docs/api/events/fire-event.mdx

@@ -5,7 +5,7 @@ function fireEvent(element: ReactTestInstance, eventName: string, ...data: unkno
 ```
 
 :::note
-For common events like `press` or `type` it's recommended to use [User Event API](docs/api/events/user-event) as it offers
+For common events like `press` or `type` it's recommended to use [User Event API](/docs/api/events/user-event) as it offers
 more realistic event simulation by emitting a sequence of events with proper event objects that mimic React Native runtime behavior.
 
 Use Fire Event for cases not supported by User Event and for triggering event handlers on composite components.
@@ -62,7 +62,7 @@ fireEvent.press: (element: ReactTestInstance, ...data: Array<any>) => void
 ```
 
 :::note
-It is recommended to use the User Event [`press()`](docs/api/events/user-event#press) helper instead as it offers more realistic simulation of press interaction, including pressable support.
+It is recommended to use the User Event [`press()`](/docs/api/events/user-event#press) helper instead as it offers more realistic simulation of press interaction, including pressable support.
 :::
 
 Invokes `press` event handler on the element or parent element in the tree.
@@ -98,7 +98,7 @@ fireEvent.changeText: (element: ReactTestInstance, ...data: Array<any>) => void
 ```
 
 :::note
-It is recommended to use the User Event [`type()`](docs/api/events/user-event#type) helper instead as it offers more realistic simulation of text change interaction, including key-by-key typing, element focus, and other editing events.
+It is recommended to use the User Event [`type()`](/docs/api/events/user-event#type) helper instead as it offers more realistic simulation of text change interaction, including key-by-key typing, element focus, and other editing events.
 :::
 
 Invokes `changeText` event handler on the element or parent element in the tree.
@@ -153,6 +153,6 @@ fireEvent.scroll(screen.getByText('scroll-view'), eventData);
 
 :::note
 
-Prefer using [`user.scrollTo`](docs/api/events/user-event#scrollto) over `fireEvent.scroll` for `ScrollView`, `FlatList`, and `SectionList` components. User Event provides a more realistic event simulation based on React Native runtime behavior.
+Prefer using [`user.scrollTo`](/docs/api/events/user-event#scrollto) over `fireEvent.scroll` for `ScrollView`, `FlatList`, and `SectionList` components. User Event provides a more realistic event simulation based on React Native runtime behavior.
 
 :::

website/docs/12.x/docs/api/jest-matchers.mdx

@@ -27,7 +27,7 @@ Alternatively, you can add above script to your Jest configuration (usually loca
 
 ## Migration from legacy Jest Native matchers.
 
-If you are already using legacy Jest Native matchers we have a [migration guide](docs/migration/jest-matchers) for moving to the built-in matchers.
+If you are already using legacy Jest Native matchers we have a [migration guide](/docs/migration/jest-matchers) for moving to the built-in matchers.
 
 ## Checking element existence
 
@@ -53,7 +53,7 @@ expect(element).toHaveTextContent(
 )
 ```
 
-This allows you to assert whether the given element has the given text content or not. It accepts either `string` or `RegExp` matchers, as well as [text match options](docs/api/queries#text-match-options) of `exact` and `normalizer`.
+This allows you to assert whether the given element has the given text content or not. It accepts either `string` or `RegExp` matchers, as well as [text match options](/docs/api/queries#text-match-options) of `exact` and `normalizer`.
 
 ### `toContainElement()`
 
@@ -87,7 +87,7 @@ expect(element).toHaveDisplayValue(
 )
 ```
 
-This allows you to assert whether the given `TextInput` element has a specified display value. It accepts either `string` or `RegExp` matchers, as well as [text match options](docs/api/queries#text-match-options) of `exact` and `normalizer`.
+This allows you to assert whether the given `TextInput` element has a specified display value. It accepts either `string` or `RegExp` matchers, as well as [text match options](/docs/api/queries#text-match-options) of `exact` and `normalizer`.
 
 ### `toHaveAccessibilityValue()`
 
@@ -202,7 +202,7 @@ expect(element).toHaveAccessibleName(
 )
 ```
 
-This allows you to assert whether the given element has a specified accessible name. It accepts either `string` or `RegExp` matchers, as well as [text match options](docs/api/queries#text-match-options) of `exact` and `normalizer`.
+This allows you to assert whether the given element has a specified accessible name. It accepts either `string` or `RegExp` matchers, as well as [text match options](/docs/api/queries#text-match-options) of `exact` and `normalizer`.
 
 The accessible name will be computed based on `aria-labelledby`, `accessibilityLabelledBy`, `aria-label`, and `accessibilityLabel` props, in the absence of these props, the element text content will be used.
 

website/docs/12.x/docs/api/misc/async.mdx

@@ -2,7 +2,7 @@
 
 ## `findBy*` queries
 
-The `findBy*` queries are used to find elements that are not instantly available but will be added as a result of some asynchronous action. Learn more details [here](docs/api/queries#find-by).
+The `findBy*` queries are used to find elements that are not instantly available but will be added as a result of some asynchronous action. Learn more details [here](/docs/api/queries#find-by).
 
 ## `waitFor`
 
@@ -101,7 +101,7 @@ In order to properly use `waitFor` you need at least React >=16.9.0 (featuring a
 :::
 
 :::note
-If you receive warnings related to `act()` function consult our [Understanding Act](docs/advanced/understanding-act.md) function document.
+If you receive warnings related to `act()` function consult our [Understanding Act](/docs/advanced/understanding-act.md) function document.
 :::
 
 ## `waitForElementToBeRemoved`
@@ -134,5 +134,5 @@ In order to properly use `waitForElementToBeRemoved` you need at least React >=1
 :::
 
 :::note
-If you receive warnings related to `act()` function consult our [Understanding Act](docs/advanced/understanding-act.md) function document.
+If you receive warnings related to `act()` function consult our [Understanding Act](/docs/advanced/understanding-act.md) function document.
 :::

website/docs/12.x/docs/api/misc/config.mdx

@@ -19,7 +19,7 @@ Default timeout, in ms, for async helper functions (`waitFor`, `waitForElementTo
 
 ### `defaultIncludeHiddenElements` option
 
-Default value for [includeHiddenElements](docs/api/queries#includehiddenelements-option) query option for all queries. The default value is set to `false`, so all queries will not match [elements hidden from accessibility](#ishiddenfromaccessibility). This is because the users of the app would not be able to see such elements.
+Default value for [includeHiddenElements](/docs/api/queries#includehiddenelements-option) query option for all queries. The default value is set to `false`, so all queries will not match [elements hidden from accessibility](#ishiddenfromaccessibility). This is because the users of the app would not be able to see such elements.
 
 This option is also available as `defaultHidden` alias for compatibility with [React Testing Library](https://testing-library.com/docs/dom-testing-library/api-configuration/#defaulthidden).
 

website/docs/12.x/docs/api/misc/other.mdx

@@ -8,7 +8,7 @@ function within(element: ReactTestInstance): Queries {}
 function getQueriesForElement(element: ReactTestInstance): Queries {}
 ```
 
-`within` (also available as `getQueriesForElement` alias) performs [queries](docs/api/queries) scoped to given element.
+`within` (also available as `getQueriesForElement` alias) performs [queries](/docs/api/queries) scoped to given element.
 
 :::note
 Please note that additional `render` specific operations like `update`, `unmount`, `debug`, `toJSON` are _not_ included.
@@ -31,7 +31,7 @@ Use cases for scoped queries include:
 
 Useful function to help testing components that use hooks API. By default any `render`, `update`, `fireEvent`, and `waitFor` calls are wrapped by this function, so there is no need to wrap it manually. This method is re-exported from [`react-test-renderer`](https://github.com/facebook/react/blob/main/packages/react-test-renderer/src/ReactTestRenderer.js#L567]).
 
-Consult our [Understanding Act function](docs/advanced/understanding-act.md) document for more understanding of its intricacies.
+Consult our [Understanding Act function](/docs/advanced/understanding-act.md) document for more understanding of its intricacies.
 
 ## `cleanup`