You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The basename of the app for situations where you can't deploy to the root of the domain, but a sub directory.
83
85
@@ -101,7 +103,7 @@ createBrowserRouter(routes, {
101
103
<Link to="/"/>; // results in <a href="/app/" />
102
104
```
103
105
104
-
## `future`
106
+
## `opts.future`
105
107
106
108
An optional set of [Future Flags][api-development-strategy] to enable for this Router. We recommend opting into newly released future flags sooner rather than later to ease your eventual migration to v7.
107
109
@@ -125,7 +127,7 @@ The following future flags are currently available:
125
127
|[`v7_relativeSplatPath`][relativesplatpath]| Fix buggy relative path resolution in splat routes |
126
128
|`unstable_skipActionErrorRevalidation`| Do not revalidate by default if the action returns a 4xx/5xx `Response`|
127
129
128
-
## `hydrationData`
130
+
## `opts.hydrationData`
129
131
130
132
When [Server-Rendering][ssr] and [opting-out of automatic hydration][hydrate-false], the `hydrationData` option allows you to pass in hydration data from your server-render. This will almost always be a subset of data from the `StaticHandlerContext` value you get back from [handler.query][query]:
<docs-warning>This is a low-level API intended for advanced use-cases. This overrides React Router's internal handling of `loader`/`action` execution, and if done incorrectly will break your app code. Please use with caution and perform the appropriate testing.</docs-warning>
188
190
@@ -228,6 +230,8 @@ interface HandlerResult {
228
230
}
229
231
```
230
232
233
+
### Overview
234
+
231
235
`unstable_dataStrategy` receives the same arguments as a `loader`/`action` (`request`, `params`) but it also receives a `matches` array which is an array of the matched routes where each match is extended with 2 new fields for use in the data strategy function:
232
236
233
237
-**`match.resolve`** - An async function that will resolve any `route.lazy` implementations and execute the route's handler (if necessary), returning a `HandlerResult`
@@ -359,7 +363,156 @@ let router = createBrowserRouter(routes, {
359
363
});
360
364
```
361
365
362
-
## `window`
366
+
## `opts.unstable_patchRoutesOnMiss`
367
+
368
+
<docs-warning>This API is marked "unstable" so it is subject to breaking API changes in minor releases</docs-warning>
369
+
370
+
By default, React Router wants you to provide a full route tree up front via `createBrowserRouter(routes)`. This allows React Router to perform synchronous route matching, execute loaders, and then render route components in the most optimistic manner without introducing waterfalls. The tradeoff is that your initial JS bundle is larger by definition - which may slow down application start-up times as your application grows.
371
+
372
+
To combat this, we introduced [`route.lazy`][route-lazy] in [v6.9.0][6-9-0] which let's you lazily load the route _implementation_ (`loader`, `Component`, etc.) while still providing the route _definition_ aspects up front (`path`, `index`, etc.). This is a good middle ground because React Router still knows about your routes up front and can perform synchronous route matching, but then delay loading any of the route implementation aspects until the route is actually navigated to.
373
+
374
+
In some cases, even this doesn't go far enough. For very large applications, providing all route definitions up front can be prohibitively expensive. Additionally, it might not even be possible to provide all route definitions up front in certain Micro-Frontend or Module-Federation architectures.
375
+
376
+
This is where `unstable_patchRoutesOnMiss` comes in ([RFC][fog-of-war-rfc]). This API is for advanced use-cases where you are unable to provide the full route tree up-front and need a way to lazily "discover" portions of the route tree at runtime. This feature is often referred to as ["Fog of War"][fog-of-war] because similar to how video games expand the "world" as you move around - the router would be expanding its routing tree as the user navigated around the app - but would only ever end up loading portions of the tree that the user visited.
`unstable_patchRoutesOnMiss` will be called anytime React Router is unable to match a `path`. The arguments include the `path`, any partial `matches`, and a `patch` function you can call to patch new routes into the tree at a specific location. This method is executed during the `loading` portion of the navigation for `GET` requests and during the `submitting` portion of the navigation for non-`GET` requests.
// Load/patch the `a` route as a child of the route with id `root`
412
+
let route =awaitgetARoute(); // { path: 'a', Component: A }
413
+
patch("root", [route]);
414
+
}
415
+
},
416
+
}
417
+
);
418
+
```
419
+
420
+
In the above example, if the user clicks a clink to `/a`, React Router won't be able to match it initially and will call `patchRoutesOnMiss` with `/a` and a `matches` array containing the root route match. By calling `patch`, it the `a` route will be added to the route tree and React Router will perform matching again. This time it will successfully match the `/a` path and the navigation will complete successfully.
421
+
422
+
**Patching new root-level routes**
423
+
424
+
If you need to patch a new route to the top of the tree (i.e., it doesn't have a parent), you can pass `null` as the `routeId`:
**Co-locating route discovery with route definition**
483
+
484
+
If you don't wish to perform your own pseudo-matching, you can leverage the partial `matches` array and the `handle` field on a route to keep the children definitions co-located:
0 commit comments