Merge branch 'dev' into v2

Author: brophdawg11

.changeset/deprecate-fetcher-type-submission.md

@@ -0,0 +1,5 @@
+---
+"@remix-run/react": patch
+---
+
+Deprecate `fetcher.type` and `fetcher.submission` for Remix v2

.changeset/dirty-wolves-knock.md

@@ -0,0 +1,5 @@
+---
+"@remix-run/server-runtime": patch
+---
+
+Don't log server errors for aborted requests as that is an expected flow

.changeset/four-feet-grab.md

@@ -0,0 +1,7 @@
+---
+"@remix-run/dev": patch
+"@remix-run/react": patch
+"@remix-run/server-runtime": patch
+---
+
+Deprecate `CatchBoundary` in favor of `future.v2_errorBoundary`

.changeset/no-log-on-aborted-request.md

@@ -31,3 +31,4 @@ tsconfig.tsbuildinfo
 /scripts/playground/template/package-lock.json
 
 /NOTES.md
+/RELEASENOTES.md

.changeset/three-cheetahs-lick.md

@@ -65,6 +65,7 @@
 - bsharrow
 - bsides
 - bustamantedev
+- buzinas
 - c43721
 - camiaei
 - CanRau
@@ -358,6 +359,7 @@
 - nexxeln
 - ni554n
 - nicholaschiang
+- nicksrandall
 - nickytonline
 - niconiahi
 - nielsdb97
@@ -460,6 +462,7 @@
 - tjefferson08
 - tombiju
 - tombyrer
+- TomerAberbach
 - toyozaki
 - turkerdev
 - tvanantwerp

.gitignore

@@ -307,7 +307,7 @@ If you want one of the special characters Remix uses for these route conventions
 
 ## Folders for Organization
 
-Routes can also be folders with a conventional node module resolution `index.tsx` file inside defining the route module. The rest of the files in the folder will not become routes. This allows you to organize your code closer to the routes that use them instead of repeating the feature names across other folders.
+Routes can also be folders with a `route.tsx` file inside defining the route module. The rest of the files in the folder will not become routes. This allows you to organize your code closer to the routes that use them instead of repeating the feature names across other folders.
 
 <docs-info>The files inside a folder have no meaning for the route paths, the route path is completely defined by the folder name</docs-info>
 

contributors.yml

@@ -11,8 +11,8 @@ Remix can help you build optimistic UI with [`useNavigation`][use-navigation] an
 ## Strategy
 
 1. User submits a form (or you do with [`useSubmit`][use-submit] or [`fetcher.submit`][fetcher-submission]).
-2. Remix makes the submission and its data immediately available to you on [`navigation.formData`][navigation-formdata] or [`fetcher.submission`][fetcher-submission].
-3. App uses [`submission.formData`][form-data] to render an optimistic version of _what it will render_ when the submission completes successfully.
+2. Remix makes the submission and its data immediately available to you on [`navigation.formData`][navigation-formdata] or [`fetcher.formData`][fetcher-submission].
+3. App uses [`formData`][form-data] to render an optimistic version of _what it will render_ when the submission completes successfully.
 4. Remix automatically revalidates all the data.
    - If successful, the user doesn't even notice.
    - If it fails, the page data is automatically in sync with the server so the UI reverts automatically.

docs/file-conventions/route-files-v2.md

@@ -44,8 +44,10 @@ function SomeComponent() {
 
   // build UI with these
   fetcher.state;
-  fetcher.type;
-  fetcher.submission;
+  fetcher.formMethod;
+  fetcher.formAction;
+  fetcher.formData;
+  fetcher.formEncType;
   fetcher.data;
 }
 ```
@@ -71,6 +73,8 @@ You can know the state of the fetcher with `fetcher.state`. It will be one of:
 
 #### `fetcher.type`
 
+<docs-error>`fetcher.type` is deprecated and will be removed in v2.</docs-error>
+
 This is the type of state the fetcher is in. It's like `fetcher.state`, but more granular. Depending on the fetcher's state, the types can be the following:
 
 - `state === "idle"`
@@ -89,8 +93,47 @@ This is the type of state the fetcher is in. It's like `fetcher.state`, but more
   - **actionRedirect** - The action from an "actionSubmission" returned a redirect and the page is transitioning to the new location.
   - **normalLoad** - A route's loader is being called without a submission (`fetcher.load()`).
 
+##### Moving away from `fetcher.type`
+
+The `type` field has been been deprecated and will be removed in v2. We've found that `state` is sufficient for almost all use-cases, and when it's not you can derive sub-types via `fetcher.state` and other fields. Here's a few examples:
+
+```js
+function Component() {
+  let fetcher = useFetcher();
+
+  let isDone =
+    fetcher.state === "idle" && fetcher.data != null;
+
+  let isActionSubmission = fetcher.state === "submitting";
+
+  let isActionReload =
+    fetcher.state === "loading" &&
+    fetcher.formMethod != null &&
+    fetcher.formMethod != "get" &&
+    // If we returned data, we must be reloading
+    fetcher.data != null;
+
+  let isActionRedirect =
+    fetcher.state === "loading" &&
+    fetcher.formMethod != null &&
+    navigation.formMethod != "get" &&
+    // If we have no data we must have redirected
+    fetcher.data == null;
+
+  let isLoaderSubmission =
+    navigation.state === "loading" &&
+    navigation.state.formMethod === "get";
+
+  let isNormalLoad =
+    navigation.state === "loading" &&
+    navigation.state.formMethod == null;
+}
+```
+
 #### `fetcher.submission`
 
+<docs-error>`fetcher.submission` is deprecated and will be removed in v2. Instead, the fields inside of `submission` have been flattened onto the `fetcher` itself (`fetcher.formMethod`, `fetcher.formAction`, `fetcher.formData`, `fetcher.formEncType`)</docs-error>
+
 When using `<fetcher.Form>` or `fetcher.submit()`, the form submission is available to build optimistic UI.
 
 It is not available when the fetcher state is "idle" or "loading".
@@ -153,7 +196,7 @@ function SomeComponent() {
   const fetcher = useFetcher();
 
   useEffect(() => {
-    if (fetcher.type === "init") {
+    if (fetcher.state === "idle" && fetcher.data == null) {
       fetcher.load("/some/route");
     }
   }, [fetcher]);
@@ -204,7 +247,10 @@ function NewsletterSignup() {
   const ref = useRef();
 
   useEffect(() => {
-    if (newsletter.type === "done" && newsletter.data.ok) {
+    if (
+      newsletter.state === "idle" &&
+      newsletter.data?.ok
+    ) {
       ref.current.reset();
     }
   }, [newsletter]);
@@ -225,7 +271,7 @@ function NewsletterSignup() {
         </button>
       </p>
 
-      {newsletter.type === "done" ? (
+      {newsletter.state === "idle" && newsletter.data ? (
         newsletter.data.ok ? (
           <p>Thanks for subscribing!</p>
         ) : newsletter.data.error ? (
@@ -283,18 +329,12 @@ export function NewsletterSignup() {
       Form={newsletter.Form}
       data={newsletter.data}
       state={newsletter.state}
-      type={newsletter.type}
     />
   );
 }
 
 // used here and in the route
-export function NewsletterForm({
-  Form,
-  data,
-  state,
-  type,
-}) {
+export function NewsletterForm({ Form, data, state }) {
   // refactor a bit in here, just read from props instead of useFetcher
 }
 ```
@@ -309,12 +349,7 @@ import { NewsletterForm } from "~/NewsletterSignup";
 export default function NewsletterSignupRoute() {
   const data = useActionData<typeof action>();
   return (
-    <NewsletterForm
-      Form={Form}
-      data={data}
-      state="idle"
-      type="done"
-    />
+    <NewsletterForm Form={Form} data={data} state="idle" />
   );
 }
 ```
@@ -355,7 +390,11 @@ function UserAvatar({ partialUser }) {
   const [showDetails, setShowDetails] = useState(false);
 
   useEffect(() => {
-    if (showDetails && userDetails.type === "init") {
+    if (
+      showDetails &&
+      userDetails.state === "idle" &&
+      !userDetails.data
+    ) {
       userDetails.load(`/users/${user.id}/details`);
     }
   }, [showDetails, userDetails]);
@@ -367,7 +406,7 @@ function UserAvatar({ partialUser }) {
     >
       <img src={partialUser.profileImageUrl} />
       {showDetails ? (
-        userDetails.type === "done" ? (
+        userDetails.state === "idle" && userDetails.data ? (
           <UserPopup user={userDetails.data} />
         ) : (
           <UserPopupLoading />

docs/guides/optimistic-ui.md

@@ -27,14 +27,14 @@ For example, imagine a UI where the sidebar lists projects, and the main view di
 +-----------------+----------------------------┘
 ```
 
-When the user clicks a checkbox, the submission goes to the action to change the state of the task. Instead of creating a "loading state" we want to create an "optimistic UI" that will **immediately** update the checkbox to appear checked even though the server hasn't processed it yet. In the checkbox component, we can use `fetcher.submission`:
+When the user clicks a checkbox, the submission goes to the action to change the state of the task. Instead of creating a "loading state" we want to create an "optimistic UI" that will **immediately** update the checkbox to appear checked even though the server hasn't processed it yet. In the checkbox component, we can use `fetcher.formData`:
 
 ```tsx
 function Task({ task }) {
   const toggle = useFetcher();
-  const checked = toggle.submission
+  const checked = toggle.formData
     ? // use the optimistic version
-      Boolean(toggle.submission.formData.get("complete"))
+      Boolean(toggle.formData.get("complete"))
     : // use the normal version
       task.complete;
 
@@ -81,7 +81,7 @@ This is where `useFetchers` comes in. Up in the sidebar, we can access all the i
 The strategy has three steps:
 
 1. Find the submissions for tasks in a specific project
-2. Use the `fetcher.submission.formData` to immediately update the count
+2. Use the `fetcher.formData` to immediately update the count
 3. Use the normal task's state if it's not inflight
 
 Here's some sample code:
@@ -95,15 +95,15 @@ function ProjectTaskCount({ project }) {
   const myFetchers = new Map();
   for (const f of fetchers) {
     if (
-      f.submission &&
-      f.submission.action.startsWith(
+      f.formAction &&
+      f.formAction.startsWith(
         `/projects/${project.id}/task`
       )
     ) {
-      const taskId = f.submission.formData.get("id");
+      const taskId = f.formData.get("id");
       myFetchers.set(
         parseInt(taskId),
-        f.submission.formData.get("complete") === "on"
+        f.formData.get("complete") === "on"
       );
     }
   }

docs/hooks/use-fetcher.md

@@ -4,6 +4,10 @@ title: useTransition
 
 # `useTransition`
 
+<docs-error>This API will be removed in v2 in favor of [`useNavigation`][use-navigation]. You can start using the new `useNavigation` hook today to make upgrading in the future easy, but you can keep using `useTransition` until v2.</docs-error>
+
+---
+
 <docs-success>Watch the <a href="https://www.youtube.com/playlist?list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">📼 Remix Singles</a>: <a href="https://www.youtube.com/watch?v=y4VLIFjFq8k&list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">Pending UI</a>, <a href="https://www.youtube.com/watch?v=bMLej7bg5Zo&list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">Clearing Inputs After Form Submissions</a>, and <a href="https://www.youtube.com/watch?v=EdB_nj01C80&list=PLXoynULbYuEDG2wBFSZ66b85EIspy3fy6">Optimistic UI</a></docs-success>
 
 This hook tells you everything you need to know about a page transition to build pending navigation indicators and optimistic UI on data mutations. Things like:
@@ -114,11 +118,62 @@ function SubmitButton() {
 }
 ```
 
+### Moving away from `transition.type`
+
+The `type` field has been removed in the new `useNavigation` hook (which will replace `useTransition` in Remix v2). We've found that `state` is sufficient for almost all use-cases, and when it's not you can derive sub-types via `navigation.state` and other fields. Also note that the `loaderSubmission` type is now represented with `state: "loading"`. Here's a few examples:
+
+```js
+function Component() {
+  let navigation = useNavigation();
+
+  let isActionSubmission =
+    navigation.state === "submitting";
+
+  let isActionReload =
+    navigation.state === "loading" &&
+    navigation.formMethod != null &&
+    navigation.formMethod != "get" &&
+    // We had a submission navigation and are loading the submitted location
+    navigation.formAction === navigation.pathname;
+
+  let isActionRedirect =
+    navigation.state === "loading" &&
+    navigation.formMethod != null &&
+    navigation.formMethod != "get" &&
+    // We had a submission navigation and are now navigating to different location
+    navigation.formAction !== navigation.pathname;
+
+  let isLoaderSubmission =
+    navigation.state === "loading" &&
+    navigation.state.formMethod === "get" &&
+    // We had a loader submission and are navigating to the submitted location
+    navigation.formAction === navigation.pathname;
+
+  let isLoaderSubmissionRedirect =
+    navigation.state === "loading" &&
+    navigation.state.formMethod === "get" &&
+    // We had a loader submission and are navigating to a new location
+    navigation.formAction !== navigation.pathname;
+}
+```
+
 ## `transition.submission`
 
 Any transition that started from a `<Form>` or `useSubmit` will have your form's submission attached to it. This is primarily useful to build "Optimistic UI" with the `submission.formData` [`FormData`][form-data] object.
 
-TODO: Example
+### Moving away from `transition.submission`
+
+The `submission` field has been removed in the new `useNavigation` hook (which will replace `useTransition` in Remix v2) and the same sub-fields are now exposed directly on the `navigation`:
+
+```js
+function Component() {
+  let navigation = useNavigation();
+  // navigation.formMethod
+  // navigation.formAction
+  // navigation.formData
+  // navigation.formEncType
+}
+```
 
 ## `transition.location`
 
@@ -149,10 +204,6 @@ function PendingLink({ to, children }) {
 
 Note that this link will not appear "pending" if a form is being submitted to the URL the link points to, because we only do this for "loading" states. The form will contain the pending UI for when the state is "submitting", once the action is complete, then the link will go pending.
 
-## v2 deprecation
-
-This API will be removed in v2 in favor of [`useNavigation`][use-navigation]. You can start using the new `useNavigation` hook today to make upgrading in the future easy, but you can keep using `useTransition` before v2.
-
 [usefetcher]: ./use-fetcher
 [form-data]: https://developer.mozilla.org/en-US/docs/Web/API/FormData
 [use-navigation]: ./use-navigation

docs/hooks/use-fetchers.md

@@ -4,6 +4,8 @@ title: CatchBoundary
 
 # `CatchBoundary`
 
+<docs-warning>The separation of `CatchBoundary` and `ErrorBoundary` has been deprecated and Remix v2 will use a singular `ErrorBoundary` for all thrown Responses and Errors. It is recommended that you opt-into the new behavior in Remix v1 via the `future.v2_errorBoundary` flag in your `remix.config.js` file. Please refer to the [ErrorBoundary (v2)][error-boundary-v2] docs for more information.</docs-warning>
+
 A `CatchBoundary` is a React component that renders whenever an action or loader throws a `Response`.
 
 **Note:** We use the word "catch" to represent the codepath taken when a `Response` type is thrown; you thought about bailing from the "happy path". This is different from an uncaught error you did not expect to occur.
@@ -29,3 +31,5 @@ export function CatchBoundary() {
   );
 }
 ```
+
+[error-boundary-v2]: ./error-boundary-v2

docs/hooks/use-transition.md

@@ -0,0 +1,11 @@
+---
+title: ErrorBoundary (v2)
+---
+
+# `ErrorBoundary (v2)`
+
+<docs-info>You can opt into the Remix v2 `ErrorBoundary` behavior via the `future.v2_errorBoundary` flag in your `remix.config.js`</docs-info>
+
+If you export an `ErrorBoundary` component from your route module, it will be used as the React Router [`errorElement`][rr-error-element] and will render if you throw from a loader/action or if React throws during rendering your Route component.
+
+[rr-error-element]: https://reactrouter.com/route/error-element