Merge branch 'main' into release-next

Author: brophdawg11

GOVERNANCE.md

@@ -84,9 +84,9 @@ This table gives a high-level overview of the stages, but please see the individ
 | Stage | Name          | Entrance Criteria                                                                                                                      | Purpose                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | ----- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | 0     | Proposal      | Proposal discussion opened on GitHub                                                                                                   | We start with a GitHub Proposal to provide the lowest barrier to RFC submission. Anyone can submit an RFC and community members can review, comment, up-vote without any initial involvement of the SC.                                                                                                                                                                                                                                                                           |
-| 1     | Consideration | Proposal acceptance from 2 or more SC members                                                                                          | The consideration phase is the first "funnel" for incoming RFCs where the SC can officially express interest in the more popular RFCs. We only require 2 SC members to express interest to move an RFC into the **Consideration** phase to allow for low-friction experimentation of features in the **Alpha** stage.                                                                                                                                                             |
+| 1     | Consideration | Proposal acceptance from 2 SC members                                                                                                  | The consideration phase is the first "funnel" for incoming RFCs where the SC can officially express interest in the more popular RFCs. We only require 2 SC members to express interest to move an RFC into the **Consideration** phase to allow for low-friction experimentation of features in the **Alpha** stage.                                                                                                                                                             |
 | 2     | Alpha         | Pull request (PR) opened to implement the feature in an "unstable" state                                                               | The **Alpha** stage is the next funnel for RFCs. Once interest has been expressed by the SC in the **Consideration** phase we open the RFC up for a sample PR implementation and a mechanism for community members to alpha test the feature without requiring that anything be shipped in a React Router SemVer release. This stage allows evaluation of the RFC in running applications and consideration of what a practical implementation of the RFC looks like in the code. |
-| 3     | Beta          | PR approval from at least 50% of the SC members indicating their acceptance of the PR for an unstable API                              | A RFC enters the **Beta** stage once enough members of the SC feel comfortable not only with the code for the beta feature, but have also seen positive feedback from alpha testers that the feature is working as expected. Once an **Alpha** stage PR has enough SC approvals, it will be merged and be included in the next React Router release.                                                                                                                              |
+| 3     | Beta          | PR approval from 2 SC members indicating their acceptance of the PR for an unstable API                                                | A RFC enters the **Beta** stage once enough members of the SC feel comfortable not only with the code for the beta feature, but have also seen positive feedback from alpha testers that the feature is working as expected. Once an **Alpha** stage PR has enough SC approvals, it will be merged and be included in the next React Router release.                                                                                                                              |
 | 4     | Stabilization | At least 1 month in the Beta stage and PR opened to stabilize the APIs. This PR should also include documentation for the new feature. | The **Stabilization** phase exists to ensure that unstable features are available for enough time for applications to update their React Router version and opt-into beta testing. We don't want to rush features through beta testing so that we have maximal feedback prior to stabilizing a feature.                                                                                                                                                                           |
 | 5     | Stable        | PR approval from at least 50% of the SC members indicating their acceptance of the PR for a stable API                                 | A RFC is completed and enters the **Stable** stage once enough members of the SC feel comfortable not only with the code for the stable feature, but have also seen positive feedback from beta testers that the feature is working as expected. Once an **Beta** stage PR has enough SC approvals and has spent the required amount of time in the **Beta** stage, it can be merged and included in the next React Router release.                                               |
 
@@ -103,7 +103,7 @@ This table gives a high-level overview of the stages, but please see the individ
 
 ### Stage 1 — Consideration
 
-- A proposal enters **Stage 1 — Consideration** when two or more SC members indicate interest/support for the idea as a valuable addition to React Router
+- A proposal enters **Stage 1 — Consideration** when 2 SC members indicate interest/support for the idea as a valuable addition to React Router
 - Upon entering this stage, a GitHub Issue will be created for the feature and added to the roadmap
 - These initial supporting SC members will be the champions for the feature and will be loosely responsible for shepherding the feature through the stages of the RFC process
 - At this stage, the proposal is eligible for a sample PR implementation from a core team or community member
@@ -129,7 +129,8 @@ This table gives a high-level overview of the stages, but please see the individ
 
 ### Stage 3 — Beta
 
-- A proposal enters **Stage 3 — Beta** once it receives **Stage 2 — Alpha** PR approvals from at least 50% of the SC members and is merged to `dev`
+- A proposal enters **Stage 3 — Beta** once it receives **Stage 2 — Alpha** PR approvals from 2 SC members and is merged to `dev`
+  - An SC member authoring the PR counts an an implicit approval, so in those cases explicit approval is required from 1 additional SC member
 - This will include the feature in `nightly` releases and the next normal SemVer release for broader beta testing under the `unstable_` flag
 
 ### Stage 4 — Stabilization

docs/how-to/form-validation.md

@@ -89,7 +89,7 @@ export async function action({
 
 If any validation errors are found, they are returned from the `action` to the fetcher. This is our way of signaling to the UI that something needs to be corrected, otherwise the user will be redirected to the dashboard.
 
-Note the `data({ errors }, { status: 400 })` call. Setting a 400 status is the web standard way to signal to the client that there was a validation error (Bad Request). In React Router, only 200 status codes trigger page data revalidation so a 400 prevent that.
+Note the `data({ errors }, { status: 400 })` call. Setting a 400 status is the web standard way to signal to the client that there was a validation error (Bad Request). In React Router, only 2xx status codes trigger page data revalidation, so sending a 400 status prevents the normal revalidation that would occur after an `action`.
 
 ## 3. Displaying Validation Errors
 

docs/how-to/middleware.md

@@ -472,7 +472,7 @@ const authMiddleware = async ({ request, context }) => {
 
 ### `next()` and Error Handling
 
-React Router contains built-in error handling via the route [`ErrorBoundary`][ErrorBoundary] export. Just like when a `action`/`loader` throws, if a `middleware` throws it will be caught and handled at the appropriate [`ErrorBoundary`] and a [`Response`][Response] will be returned through the ancestor `next()` call. This means that the `next()` function should never throw and should always return a [`Response`][Response], so you don't need to worry about wrapping it in a try/catch.
+React Router contains built-in error handling via the route [`ErrorBoundary`][ErrorBoundary] export. Just like when a `action`/`loader` throws, if a `middleware` throws it will be caught and handled at the appropriate [`ErrorBoundary`][ErrorBoundary] and a [`Response`][Response] will be returned through the ancestor `next()` call. This means that the `next()` function should never throw and should always return a [`Response`][Response], so you don't need to worry about wrapping it in a try/catch.
 
 This behavior is important to allow middleware patterns such as automatically setting required headers on outgoing responses (i.e., committing a session) from a root `middleware`. If any error from a `middleware` caused `next()` to `throw`, we'd miss the execution of ancestor middlewares on the way out and those required headers wouldn't be set.
 

docs/start/data/installation.md

@@ -27,7 +27,7 @@ npm i react-router
 
 Create a router and pass it to `RouterProvider`:
 
-```tsx lines=[3-4,9-14,19]
+```tsx lines=[3-4,6-11,16]
 import React from "react";
 import ReactDOM from "react-dom/client";
 import { createBrowserRouter } from "react-router";

docs/start/framework/data-loading.md

@@ -15,6 +15,8 @@ Loader data is automatically serialized from loaders and deserialized in compone
 
 The type for the `loaderData` prop is [automatically generated][type-safety].
 
+<docs-info>We try to support the same set of [serializable types][serializable-types] that React permits server components to pass as props to client components. This future proofs your application for any eventual migration to [RSC][rsc].</docs-info>
+
 ## Client Data Loading
 
 `clientLoader` is used to fetch data on the client. This is useful for pages or full projects that you'd prefer to fetch data from the browser only.
@@ -182,14 +184,18 @@ export default function Product() {
 
 ---
 
-Next: [Actions](./actions)
+Next: [Actions][actions]
 
 See also:
 
-- [Streaming with Suspense](../../how-to/suspense)
-- [Client Data](../../how-to/client-data)
-- [Using Fetchers](../../how-to/fetchers#loading-data)
+- [Streaming with Suspense][streaming]
+- [Client Data][client-data]
+- [Using Fetchers][fetchers]
 
-[advanced_data_fetching]: ../tutorials/advanced-data-fetching
-[data]: ../../api/react-router/data
 [type-safety]: ../../explanation/type-safety
+[serializable-types]: https://react.dev/reference/rsc/use-client#serializable-types
+[rsc]: ../../how-to/react-server-components
+[actions]: ./actions
+[streaming]: ../../how-to/suspense
+[client-data]: ../../how-to/client-data
+[fetchers]: ../../how-to/fetchers#loading-data