From ca2e663b38969d99329df2d52f8635ff6dbb79ac Mon Sep 17 00:00:00 2001 From: Chance Strickland Date: Wed, 30 Nov 2022 15:03:54 -0800 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Matt Brophy --- packages/remix-server-runtime/CHANGELOG.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/packages/remix-server-runtime/CHANGELOG.md b/packages/remix-server-runtime/CHANGELOG.md index 5742f9e5897..61f37434f16 100644 --- a/packages/remix-server-runtime/CHANGELOG.md +++ b/packages/remix-server-runtime/CHANGELOG.md @@ -4,7 +4,7 @@ ### Minor Changes -- We have been busy at work [Layering Remix on top of React Router 6.4](https://github.com/remix-run/remix/blob/main/decisions/0007-remix-on-react-router-6-4-0.md) and are excited to be releasing the step 1 in this process that consists of running the server flow through a local copy the new framework agnostic `@remix-run/router`. ([#4612](https://github.com/remix-run/remix/pull/4612)) +- We have been busy at work [Layering Remix on top of React Router 6.4](https://github.com/remix-run/remix/blob/main/decisions/0007-remix-on-react-router-6-4-0.md) and are excited to be releasing step 1 in this process that consists of performing all server-side data fetches/mutations through the new framework agnostic `@remix-run/router`. Server- and client-side rendering are still done the same as before, and will be updated in subsequent releases. ([#4612](https://github.com/remix-run/remix/pull/4612)) - Importing functions and types from the `remix` package is deprecated, and all ([#3284](https://github.com/remix-run/remix/pull/3284)) exported modules will be removed in the next major release. For more details, [see the release notes for 1.4.0](https://github.com/remix-run/remix/releases/tag/v1.4.0) @@ -19,14 +19,14 @@ Previously there was some ambiguity around _"thrown Responses go to the `CatchBoundary`"_. The `CatchBoundary` exists to give the _user_ a place to handle non-happy path code flows - such that they can throw Response instances from _their own code_ and handle them in a + such that they can throw `Response` instances from _their own code_ and handle them in a `CatchBoundary`. However, there are a handful of framework-internal errors that make - sense to have a non-500 status code, and the fact that these were being thrown as Responses - was causing them to go into the CatchBoundary, even though they were not user-thrown. + sense to have a non-500 status code, and the fact that these were being thrown as `Response` instances + was causing them to go into the `CatchBoundary`, even though they were not user-thrown. With this change, anything thrown by the framework itself (`Error` or `Response`) will go to the `ErrorBoundary`, and any user-thrown `Response` instances will go to the - `CatchBoundary`. Thereis one exception to this rule, which is that framework-detected + `CatchBoundary`. There is one exception to this rule, which is that framework-detected 404's will continue to go to the `CatchBoundary` since users should have one single location to handle 404 displays.