Merge branch 'main' into release-next

Author: brophdawg11

contributors.yml

@@ -63,6 +63,7 @@
 - dokeet
 - Drishtantr
 - edwin177
+- eiffelwong1
 - ek9
 - ekaansharora
 - elanis
@@ -118,6 +119,7 @@
 - jrakotoharisoa
 - juanpprieto
 - kachun333
+- Kakamotobi
 - kantuni
 - kark
 - KAROTT7

docs/components/link.md

@@ -67,7 +67,7 @@ A relative `<Link to>` value (that does not begin with `/`) resolves relative to
 
 ## `relative`
 
-By default, links are relative to the route hierarchy (`relative="route"`), so `..` will go up one `Route` level. Occasionally, you may find that you have matching URL patterns that do not make sense to be nested, and you'd prefer to use relative _path_ routing. You can opt into this behavior with `relative="path"`:
+By default, links are relative to the route hierarchy (`relative="route"`), so `..` will go up one `Route` level from the current contextual route. Occasionally, you may find that you have matching URL patterns that do not make sense to be nested, and you'd prefer to use relative _path_ routing from the current contextual route path. You can opt into this behavior with `relative="path"`:
 
 ```jsx
 // Contact and EditContact do not share additional UI layout
@@ -81,7 +81,8 @@ By default, links are relative to the route hierarchy (`relative="route"`), so `
 
 function EditContact() {
   // Since Contact is not a parent of EditContact we need to go up one level
-  // in the path, instead of one level in the Route hierarchy
+  // in the current contextual route path, instead of one level in the Route
+  // hierarchy
   return (
     <Link to=".." relative="path">
       Cancel

docs/hooks/use-resolved-path.md

@@ -67,13 +67,23 @@ And then it gets worse if you define the splat route as a child:
 ```
 
 - Now, `useResolvedPath(".")` and `useResolvedPath("..")` resolve to the exact same path inside `<Dashboard />`
-- If you were using a Data Router and defined an `action` on the splat route, you'd get a 405 error on `<Form>` submissions because they (by default) submit to `"."` which would resolve to the parent `/dashboard` route which doesn't have an `action`.
+- If you were using a Data Router and defined an `action` on the splat route, you'd get a 405 error on `<Form>` submissions inside `<Dashboard>` because they (by default) submit to `"."` which would resolve to the parent `/dashboard` route which doesn't have an `action`.
 
 ### Behavior with the flag
 
 When you enable the flag, this "bug" is fixed so that path resolution is consistent across all route types, and `useResolvedPath(".")` always resolves to the current pathname for the contextual route. This includes any dynamic param or splat param values.
 
-If you want to navigate between "sibling" routes within a splat route, it is suggested you move your splat route to it's own child (`<Route path="*" element={<Dashboard />} />`) and use `useResolvedPath("../teams")` and `useResolvedPath("../projects")` parent-relative paths to navigate to sibling routes.
+If you want to navigate between "sibling" routes within a splat route, it is suggested you move your splat route to it's own child and use `useResolvedPath("../teams")` and `useResolvedPath("../projects")` parent-relative paths to navigate to sibling `/dashboard` routes. Note that here we also use `index` so that the URL `/dashboard` also renders the `<Dashboard>` component.
+
+```jsx
+<BrowserRouter>
+  <Routes>
+    <Route path="/dashboard">
+      <Route index path="*" element={<Dashboard />} />
+    </Route>
+  </Routes>
+</BrowserRouter>
+```
 
 [navlink]: ../components/nav-link
 [resolvepath]: ../utils/resolve-path

docs/hooks/use-view-transition-state.md

@@ -30,15 +30,18 @@ Consider clicking on an image in a list that you need to expand into the hero im
 
 ```jsx
 function NavImage({ src, alt, id }) {
-  let to = `/images/${idx}`;
-  let vt = unstable_useViewTransitionState(href);
+  const to = `/images/${id}`;
+  const isTransitioning =
+    unstable_useViewTransitionState(to);
   return (
     <Link to={to} unstable_viewTransition>
       <img
         src={src}
         alt={alt}
         style={{
-          viewTransitionName: vt ? "image-expand" : "",
+          viewTransitionName: isTransitioning
+            ? "image-expand"
+            : "",
         }}
       />
     </Link>

docs/route/error-element.md

@@ -46,7 +46,7 @@ Put an `errorElement` at the top of your route tree and handle nearly every erro
 
 <docs-warning>We recommend _always_ providing at least a root-level `errorElement` before shipping your application to production, because the UI of the default `errorElement` is ugly and not intended for end-user consumption.</docs-warning>
 
-If you do not provide an `errorElement` in your route tree to handle a given error, errors will bubble up and be handled by a default `errorElement` which will print the error message and stack trace. Some folks have questioned why the stack trace shows up in production builds. Normally, you don't want to expose stack traces on your production sites for security reasons. However, this is more applicable to server-side errors (and Remix does indeed strip stack traces from server-side loader/action responses). In the case of client-side `react-router-dom` applications the code is already available in the browser anyway so any hiding is just security through obscurity. Furthermore, we would still want to expose the error in the console, so removing it from the UI display is still not hiding any information about the stack trace. Not showing it in the UI _and_ not logging it to to the console would mean that application developers have no information _at all_ about production bugs, which poses its own set of issues. So, again we recommend you always add a root level `errorElement` before deploying your site to production!
+If you do not provide an `errorElement` in your route tree to handle a given error, errors will bubble up and be handled by a default `errorElement` which will print the error message and stack trace. Some folks have questioned why the stack trace shows up in production builds. Normally, you don't want to expose stack traces on your production sites for security reasons. However, this is more applicable to server-side errors (and Remix does indeed strip stack traces from server-side loader/action responses). In the case of client-side `react-router-dom` applications the code is already available in the browser anyway so any hiding is just security through obscurity. Furthermore, we would still want to expose the error in the console, so removing it from the UI display is still not hiding any information about the stack trace. Not showing it in the UI _and_ not logging it to the console would mean that application developers have no information _at all_ about production bugs, which poses its own set of issues. So, again we recommend you always add a root level `errorElement` before deploying your site to production!
 
 ## Throwing Manually
 
@@ -77,13 +77,13 @@ Here's a "not found" case in a [loader][loader]:
 
 As soon as you know you can't render the route with the data you're loading, you can throw to break the call stack. You don't have to worry about the rest of the work in the loader (like parsing the user's markdown bio) when it doesn't exist. Just throw and get out of there.
 
-This also means you don't have to worry about a bunch of error branching code in your route component, it won't even try to render if you throw in the loader or action, instead your `errorElement` will render.
+This also means you don't have to worry about a bunch of error branching code in your route component. It won't even try to render if you throw in the loader or action, since your `errorElement` will render instead.
 
 You can throw anything from a loader or action just like you can return anything: responses (like the previous example), errors, or plain objects.
 
 ## Throwing Responses
 
-While you can throw anything and it will be provided back to you through [`useRouteError`][userouteerror], If you throw a [Response][response], React Router will automatically parse the response data before returning it to your components.
+While you can throw anything and it will be provided back to you through [`useRouteError`][userouteerror], if you throw a [Response][response], React Router will automatically parse the response data before returning it to your components.
 
 Additionally, [`isRouteErrorResponse`][isrouteerrorresponse] lets you check for this specific type in your boundaries. Coupled with [`json`][json], you can easily throw responses with some data and render different cases in your boundary:
 

docs/routers/create-browser-router.md

@@ -116,12 +116,13 @@ const router = createBrowserRouter(routes, {
 
 The following future flags are currently available:
 
-| Flag                     | Description                                                           |
-| ------------------------ | --------------------------------------------------------------------- |
-| `v7_fetcherPersist`      | Delay active fetcher cleanup until they return to an `idle` state     |
-| `v7_normalizeFormMethod` | Normalize `useNavigation().formMethod` to be an uppercase HTTP Method |
-| `v7_partialHydration`    | Support partial hydration for Server-rendered apps                    |
-| `v7_prependBasename`     | Prepend the router basename to navigate/fetch paths                   |
+| Flag                                        | Description                                                           |
+| ------------------------------------------- | --------------------------------------------------------------------- |
+| `v7_fetcherPersist`                         | Delay active fetcher cleanup until they return to an `idle` state     |
+| `v7_normalizeFormMethod`                    | Normalize `useNavigation().formMethod` to be an uppercase HTTP Method |
+| `v7_partialHydration`                       | Support partial hydration for Server-rendered apps                    |
+| `v7_prependBasename`                        | Prepend the router basename to navigate/fetch paths                   |
+| [`v7_relativeSplatPath`][relativesplatpath] | Fix buggy relative path resolution in splat routes                    |
 
 ## `hydrationData`
 
@@ -197,3 +198,4 @@ Useful for environments like browser devtool plugins or testing to use a differe
 [query]: ./create-static-handler#handlerqueryrequest-opts
 [clientloader]: https://remix.run/route/client-loader
 [hydratefallback]: ../route/hydrate-fallback-element
+[relativesplatpath]: ../hooks/use-resolved-path#splat-paths

packages/react-router-dom-v5-compat/CHANGELOG.md

@@ -108,7 +108,7 @@
   <BrowserRouter>
     <Routes>
       <Route path="dashboard">
-        <Route path="*" element={<Dashboard />} />
+        <Route index path="*" element={<Dashboard />} />
       </Route>
     </Routes>
   </BrowserRouter>

packages/react-router-dom/CHANGELOG.md

@@ -108,7 +108,7 @@
   <BrowserRouter>
     <Routes>
       <Route path="dashboard">
-        <Route path="*" element={<Dashboard />} />
+        <Route index path="*" element={<Dashboard />} />
       </Route>
     </Routes>
   </BrowserRouter>

packages/react-router-native/CHANGELOG.md

@@ -108,7 +108,7 @@
   <BrowserRouter>
     <Routes>
       <Route path="dashboard">
-        <Route path="*" element={<Dashboard />} />
+        <Route index path="*" element={<Dashboard />} />
       </Route>
     </Routes>
   </BrowserRouter>

packages/react-router/CHANGELOG.md

@@ -108,7 +108,7 @@
   <BrowserRouter>
     <Routes>
       <Route path="dashboard">
-        <Route path="*" element={<Dashboard />} />
+        <Route index path="*" element={<Dashboard />} />
       </Route>
     </Routes>
   </BrowserRouter>