@rangojs/router 0.0.0-experimental.dfdb0387 → 0.0.0-experimental.ede38110

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (36) hide show
  1. package/dist/vite/index.js +16 -8
  2. package/package.json +3 -3
  3. package/skills/handler-use/SKILL.md +362 -0
  4. package/skills/intercept/SKILL.md +20 -0
  5. package/skills/layout/SKILL.md +22 -0
  6. package/skills/middleware/SKILL.md +32 -3
  7. package/skills/migrate-nextjs/SKILL.md +560 -0
  8. package/skills/migrate-react-router/SKILL.md +764 -0
  9. package/skills/parallel/SKILL.md +59 -0
  10. package/skills/rango/SKILL.md +24 -22
  11. package/skills/route/SKILL.md +24 -0
  12. package/src/browser/navigation-bridge.ts +21 -2
  13. package/src/browser/partial-update.ts +9 -2
  14. package/src/browser/prefetch/fetch.ts +20 -4
  15. package/src/browser/react/use-navigation.ts +11 -10
  16. package/src/browser/segment-reconciler.ts +10 -14
  17. package/src/build/route-trie.ts +50 -24
  18. package/src/client.tsx +82 -174
  19. package/src/index.ts +37 -9
  20. package/src/reverse.ts +4 -1
  21. package/src/route-definition/dsl-helpers.ts +159 -20
  22. package/src/route-definition/helpers-types.ts +57 -13
  23. package/src/route-types.ts +7 -0
  24. package/src/router/handler-context.ts +4 -1
  25. package/src/router/lazy-includes.ts +5 -5
  26. package/src/router/manifest.ts +22 -13
  27. package/src/router/match-middleware/cache-lookup.ts +2 -1
  28. package/src/segment-content-promise.ts +67 -0
  29. package/src/segment-loader-promise.ts +122 -0
  30. package/src/segment-system.tsx +11 -61
  31. package/src/server/context.ts +26 -3
  32. package/src/types/route-entry.ts +11 -0
  33. package/src/types/segments.ts +0 -1
  34. package/src/urls/include-helper.ts +24 -14
  35. package/src/urls/path-helper-types.ts +30 -4
  36. package/src/vite/utils/prerender-utils.ts +20 -6
@@ -1864,7 +1864,7 @@ import { resolve } from "node:path";
1864
1864
  // package.json
1865
1865
  var package_default = {
1866
1866
  name: "@rangojs/router",
1867
- version: "0.0.0-experimental.dfdb0387",
1867
+ version: "0.0.0-experimental.ede38110",
1868
1868
  description: "Django-inspired RSC router with composable URL patterns",
1869
1869
  keywords: [
1870
1870
  "react",
@@ -2006,7 +2006,7 @@ var package_default = {
2006
2006
  "test:unit:watch": "vitest"
2007
2007
  },
2008
2008
  dependencies: {
2009
- "@vitejs/plugin-rsc": "^0.5.19",
2009
+ "@vitejs/plugin-rsc": "^0.5.23",
2010
2010
  "magic-string": "^0.30.17",
2011
2011
  picomatch: "^4.0.3",
2012
2012
  "rsc-html-stream": "^0.0.7"
@@ -2026,7 +2026,7 @@ var package_default = {
2026
2026
  },
2027
2027
  peerDependencies: {
2028
2028
  "@cloudflare/vite-plugin": "^1.25.0",
2029
- "@vitejs/plugin-rsc": "^0.5.14",
2029
+ "@vitejs/plugin-rsc": "^0.5.23",
2030
2030
  react: "^18.0.0 || ^19.0.0",
2031
2031
  vite: "^7.3.0"
2032
2032
  },
@@ -3580,11 +3580,19 @@ function substituteRouteParams(pattern, params, encode = encodeURIComponent) {
3580
3580
  let hadOmittedOptional = false;
3581
3581
  for (const [key, value] of Object.entries(params)) {
3582
3582
  const escaped = escapeRegExp2(key);
3583
- result = result.replace(
3584
- new RegExp(`:${escaped}(\\([^)]*\\))?\\??`),
3585
- encode(value)
3586
- );
3587
- result = result.replace(`*${key}`, encode(value));
3583
+ if (value === "") {
3584
+ result = result.replace(
3585
+ new RegExp(`:${escaped}(\\([^)]*\\))?(?!\\?)`),
3586
+ ""
3587
+ );
3588
+ result = result.replace(`*${key}`, "");
3589
+ } else {
3590
+ result = result.replace(
3591
+ new RegExp(`:${escaped}(\\([^)]*\\))?\\??`),
3592
+ encode(value)
3593
+ );
3594
+ result = result.replace(`*${key}`, encode(value));
3595
+ }
3588
3596
  }
3589
3597
  result = result.replace(/:([a-zA-Z_][a-zA-Z0-9_]*)(\([^)]*\))?\?/g, () => {
3590
3598
  hadOmittedOptional = true;
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@rangojs/router",
3
- "version": "0.0.0-experimental.dfdb0387",
3
+ "version": "0.0.0-experimental.ede38110",
4
4
  "description": "Django-inspired RSC router with composable URL patterns",
5
5
  "keywords": [
6
6
  "react",
@@ -142,7 +142,7 @@
142
142
  "test:unit:watch": "vitest"
143
143
  },
144
144
  "dependencies": {
145
- "@vitejs/plugin-rsc": "^0.5.19",
145
+ "@vitejs/plugin-rsc": "^0.5.23",
146
146
  "magic-string": "^0.30.17",
147
147
  "picomatch": "^4.0.3",
148
148
  "rsc-html-stream": "^0.0.7"
@@ -162,7 +162,7 @@
162
162
  },
163
163
  "peerDependencies": {
164
164
  "@cloudflare/vite-plugin": "^1.25.0",
165
- "@vitejs/plugin-rsc": "^0.5.14",
165
+ "@vitejs/plugin-rsc": "^0.5.23",
166
166
  "react": "^18.0.0 || ^19.0.0",
167
167
  "vite": "^7.3.0"
168
168
  },
@@ -0,0 +1,362 @@
1
+ ---
2
+ name: handler-use
3
+ description: Attach default loaders, middleware, parallels, and other use items directly to handlers via handler.use, and compose them with explicit use() at mount sites
4
+ argument-hint: "[handler]"
5
+ ---
6
+
7
+ # Handler-Attached `.use`
8
+
9
+ A handler function (or branded `Static`/`Prerender`/`Passthrough` definition) can carry its own defaults via a `.use` callback that returns an array of `use` items (loader, middleware, parallel, intercept, layout, loading, etc.). The mount-site DSL (`path()`, `layout()`, `parallel()`, `intercept()`) merges those defaults with any explicit `use()` callback supplied at the registration site.
10
+
11
+ This lets handlers be **self-contained, reusable units** — a page brings its own loader, a layout brings its own middleware, a parallel slot brings its own data + skeleton — without forcing every caller to wire the same items at every mount site.
12
+
13
+ Canonical implementation reference:
14
+ [src/route-definition/resolve-handler-use.ts](../../src/route-definition/resolve-handler-use.ts)
15
+
16
+ ## Defining a handler with `.use`
17
+
18
+ Attach `.use` to the function (or to the branded definition for `Static()`/`Prerender()`/`Passthrough()`):
19
+
20
+ ```typescript
21
+ import {
22
+ loader,
23
+ middleware,
24
+ loading,
25
+ createLoader,
26
+ type Handler,
27
+ } from "@rangojs/router";
28
+
29
+ export const ProductLoader = createLoader(async (ctx) =>
30
+ fetchProduct(ctx.params.slug),
31
+ );
32
+
33
+ const ProductPage: Handler<"/product/:slug"> = async (ctx) => {
34
+ const product = await ctx.use(ProductLoader);
35
+ return <ProductView product={product} />;
36
+ };
37
+
38
+ ProductPage.use = () => [
39
+ loader(ProductLoader),
40
+ loading(<ProductSkeleton />),
41
+ middleware(async (ctx, next) => {
42
+ await next();
43
+ ctx.header("Cache-Control", "private, max-age=60");
44
+ }),
45
+ ];
46
+ ```
47
+
48
+ Now `ProductPage` carries its loader, loading state, and response-header middleware regardless of where it is mounted.
49
+
50
+ ## Allowed items per mount site
51
+
52
+ `handler.use()` is the same callback shape regardless of where the handler runs, but the runtime validates that the items it returns are valid for the mount site. Driven by `MOUNT_SITE_ALLOWED_TYPES` in [resolve-handler-use.ts](../../src/route-definition/resolve-handler-use.ts):
53
+
54
+ | Mount site | Allowed item types |
55
+ | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
56
+ | `path()` / `route()` | `layout`, `parallel`, `intercept`, `middleware`, `revalidate`, `loader`, `loading`, `errorBoundary`, `notFoundBoundary`, `cache`, `transition` |
57
+ | `layout()` | All of the above, plus `route`, `include` |
58
+ | `parallel()` (per slot) | `revalidate`, `loader`, `loading`, `errorBoundary`, `notFoundBoundary`, `transition` |
59
+ | `intercept()` | `middleware`, `revalidate`, `loader`, `loading`, `errorBoundary`, `notFoundBoundary`, `layout`, `route`, `when`, `transition` |
60
+ | Response routes (`path.json()`, `path.text()`, …) | `middleware`, `cache` |
61
+
62
+ If `handler.use()` returns a disallowed item for a mount site, registration throws:
63
+
64
+ ```
65
+ handler.use() returned middleware() which is not valid inside parallel().
66
+ Allowed types: revalidate, loader, loading, errorBoundary, notFoundBoundary, transition.
67
+ ```
68
+
69
+ The narrowest contract is `parallel()` — slots cannot bring their own middleware or layout; only data, loading, error/notFound boundaries, revalidation, and transitions.
70
+
71
+ ## Composition with explicit `use()`
72
+
73
+ Every mount site that takes a `use` callback merges in this order:
74
+
75
+ 1. **`handler.use()` items first** — the handler's defaults.
76
+ 2. **Explicit `use()` items second** — overrides specified at the mount site.
77
+
78
+ Items of the same kind from the explicit `use()` follow the existing override rules of that item type. The most important ones for composition:
79
+
80
+ - **`loading()`** — last definition wins, so explicit `loading()` replaces the handler's default.
81
+ - **`parallel({ "@slot": … })`** — the last `parallel()` call wins per slot name. Other slots from earlier calls are preserved (see `skills/parallel`).
82
+ - **`loader()`, `middleware()`, etc.** — accumulate; both the handler's and the explicit ones run.
83
+
84
+ Skip the boilerplate: if neither `handler.use` nor explicit `use()` is provided, no merge happens.
85
+
86
+ ```typescript
87
+ // Handler brings a loader + a (placeholder) loading; explicit use replaces loading.
88
+ const SidebarSlot: Handler = async (ctx) => {
89
+ const data = await ctx.use(SidebarLoader);
90
+ return <Sidebar data={data} />;
91
+ };
92
+ SidebarSlot.use = () => [
93
+ loader(SidebarLoader),
94
+ loading(<DefaultSidebarSkeleton />),
95
+ ];
96
+
97
+ parallel({ "@sidebar": SidebarSlot }, () => [
98
+ // Replaces the default skeleton; SidebarLoader from handler.use still runs.
99
+ loading(<SiteSpecificSidebarSkeleton />),
100
+ ]);
101
+ ```
102
+
103
+ ## Composable parallel slots (the main pay-off)
104
+
105
+ The parallel slot site is where `handler.use` shines. A slot handler that owns its data/loading lets a layout declare **just** the slot names — every loader, skeleton, and revalidation contract travels with the slot itself.
106
+
107
+ ### Without `handler.use` (every caller wires it up)
108
+
109
+ ```typescript
110
+ layout(<DashboardLayout />, () => [
111
+ parallel({ "@cart": CartSummary }, () => [
112
+ loader(CartLoader),
113
+ loading(<CartSkeleton />),
114
+ revalidate(revalidateCartData),
115
+ ]),
116
+ parallel({ "@notifs": NotificationPanel }, () => [
117
+ loader(NotificationsLoader),
118
+ loading(<NotifsSkeleton />),
119
+ revalidate(revalidateNotifs),
120
+ ]),
121
+ path("/dashboard", DashboardIndex, { name: "dashboard.index" }),
122
+ ]);
123
+ ```
124
+
125
+ Every layout that wants `@cart` must repeat the same loader/loading/revalidate triplet.
126
+
127
+ ### With `handler.use` (slot owns its dependencies)
128
+
129
+ ```typescript
130
+ const CartSummary: Handler = async (ctx) => {
131
+ const cart = await ctx.use(CartLoader);
132
+ return <CartSummaryView cart={cart} />;
133
+ };
134
+ CartSummary.use = () => [
135
+ loader(CartLoader),
136
+ loading(<CartSkeleton />),
137
+ revalidate(revalidateCartData),
138
+ ];
139
+
140
+ const NotificationPanel: Handler = async (ctx) => {
141
+ const items = await ctx.use(NotificationsLoader);
142
+ return <NotificationsView items={items} />;
143
+ };
144
+ NotificationPanel.use = () => [
145
+ loader(NotificationsLoader),
146
+ loading(<NotifsSkeleton />),
147
+ revalidate(revalidateNotifs),
148
+ ];
149
+
150
+ // Mount sites become declarative — no per-call data wiring.
151
+ layout(<DashboardLayout />, () => [
152
+ parallel({ "@cart": CartSummary, "@notifs": NotificationPanel }),
153
+ path("/dashboard", DashboardIndex, { name: "dashboard.index" }),
154
+ ]);
155
+
156
+ layout(<AccountLayout />, () => [
157
+ // Same slot, same defaults, zero re-wiring.
158
+ parallel({ "@cart": CartSummary }),
159
+ path("/account", AccountIndex, { name: "account.index" }),
160
+ ]);
161
+ ```
162
+
163
+ Each slot handler is now a portable, self-contained unit. Different layouts can use the same slot without copying data plumbing.
164
+
165
+ ### Streaming behavior is per-slot
166
+
167
+ A slot's `loading()` (whether from `handler.use` or explicit) makes that slot an independent streaming unit — its loader does not block the parent layout. Two slot handlers with their own loading skeletons stream independently.
168
+
169
+ ```typescript
170
+ parallel({
171
+ "@cart": CartSummary, // handler.use loading() → streams independently
172
+ "@cartBadge": CartBadge, // no loading() anywhere → awaited before paint
173
+ });
174
+ ```
175
+
176
+ ### Two scopes for explicit `use` at the mount site: shared (broadcast) and slot-local
177
+
178
+ `parallel()` accepts an explicit `use()` callback that **broadcasts** to every slot in the call ([dsl-helpers.ts](../../src/route-definition/dsl-helpers.ts)). That's the right behavior for the items the parallel allow-list permits and that accumulate (`loader`, `revalidate`, `errorBoundary`, `notFoundBoundary`, `transition`) — every slot gets them. (Note: `middleware` is not allowed inside `parallel()`; see the allowed-types table above.)
179
+
180
+ For single-assignment items like `loading()`, broadcasting overwrites every slot's `handler.use` default. Pass a **slot descriptor** `{ handler, use }` instead: items in the descriptor's `use` apply only to that slot.
181
+
182
+ ```typescript
183
+ parallel({
184
+ "@meta": MetaSlot,
185
+ "@sidebar": {
186
+ handler: SidebarSlot,
187
+ use: () => [loading(<SidebarSkeleton />)], // ← only @sidebar
188
+ },
189
+ });
190
+ ```
191
+
192
+ Per-slot merge order is **handler.use → shared use → slot-local use** (narrowest scope wins for last-write-wins items like `loading()`):
193
+
194
+ ```typescript
195
+ parallel(
196
+ {
197
+ "@cart": {
198
+ handler: Cart,
199
+ use: () => [loading(<CartSkeleton />)], // wins for @cart
200
+ },
201
+ "@notifs": Notifs, // gets <BroadcastSkeleton />
202
+ },
203
+ () => [
204
+ loader(SharedAnalyticsLoader), // accumulates on every slot
205
+ loading(<BroadcastSkeleton />), // applies to slots without slot-local
206
+ ],
207
+ );
208
+ ```
209
+
210
+ Use the descriptor's `use` for `loading(false)` too — opting one slot out of streaming without affecting siblings:
211
+
212
+ ```typescript
213
+ parallel(
214
+ {
215
+ "@cart": { handler: Cart, use: () => [loading(false)] }, // @cart awaits
216
+ "@notifs": Notifs, // @notifs still streams with broadcast skeleton
217
+ },
218
+ () => [loading(<BroadcastSkeleton />)],
219
+ );
220
+ ```
221
+
222
+ Rule of thumb: shared `use` is for items that legitimately apply to every slot. Slot-local `use` is for per-slot precision — especially `loading()` and `loading(false)`.
223
+
224
+ ### Replacing a whole slot from a parent's `handler.use`
225
+
226
+ A handler can publish a default `parallel({...})` set via its `.use`, and the mount site can replace any individual slot by re-declaring it. Last `parallel()` per slot name wins (see `skills/parallel` § Slot Override Semantics).
227
+
228
+ ```typescript
229
+ const ProductPage: Handler<"/product/:slug"> = (ctx) => (
230
+ <article>
231
+ <ProductHero slug={ctx.params.slug} />
232
+ <ParallelOutlet name="@related" />
233
+ <ParallelOutlet name="@reviews" />
234
+ </article>
235
+ );
236
+ ProductPage.use = () => [
237
+ parallel({
238
+ "@related": DefaultRelatedProducts,
239
+ "@reviews": DefaultReviews,
240
+ }),
241
+ ];
242
+
243
+ path("/product/:slug", ProductPage, { name: "product" }, () => [
244
+ // Override @related only; @reviews keeps the default from handler.use.
245
+ parallel({ "@related": SiteSpecificRelated }),
246
+ ]);
247
+ ```
248
+
249
+ ## Other mount sites
250
+
251
+ ### Pages (`path()`)
252
+
253
+ Page handlers can carry middleware, loaders, error boundaries, parallel slots, etc. — anything from the `path` row of the table above.
254
+
255
+ ```typescript
256
+ const CheckoutPage: Handler<"/checkout"> = async (ctx) => { /* … */ };
257
+ CheckoutPage.use = () => [
258
+ middleware(requireAuth),
259
+ loader(CartLoader),
260
+ errorBoundary(<CheckoutError />),
261
+ notFoundBoundary(<CheckoutNotFound />),
262
+ ];
263
+ ```
264
+
265
+ ### Layouts (`layout()`)
266
+
267
+ Layout handlers can carry middleware that runs for every child route, plus default parallels, includes, etc.
268
+
269
+ ```typescript
270
+ const AdminLayout: Handler = (ctx) => {
271
+ const user = ctx.get(CurrentUser);
272
+ return <Admin user={user} />;
273
+ };
274
+ AdminLayout.use = () => [
275
+ middleware(requireAdmin),
276
+ parallel({ "@adminNotifs": AdminNotifsSlot }),
277
+ ];
278
+ ```
279
+
280
+ ### Intercepts (`intercept()`)
281
+
282
+ Intercept handlers can carry their own middleware chain, loaders, and even nested layouts/routes for the modal shell.
283
+
284
+ ```typescript
285
+ const QuickViewModal: Handler = async (ctx) => {
286
+ const product = await ctx.use(ProductLoader);
287
+ return <QuickView product={product} />;
288
+ };
289
+ QuickViewModal.use = () => [
290
+ loader(ProductLoader),
291
+ loading(<QuickViewSkeleton />),
292
+ layout(<ModalChrome />),
293
+ ];
294
+ ```
295
+
296
+ ## `loading()` is a single-assignment item — scope it correctly
297
+
298
+ Most `use` items accumulate when merged: `handler.use` `middleware()` runs _and_ explicit `middleware()` runs; both `loader()` registrations apply. `loading()` is different — it mutates `entry.loading` directly, last call wins ([dsl-helpers.ts `loadingFn`](../../src/route-definition/dsl-helpers.ts)).
299
+
300
+ For pages, layouts, and intercepts that's straightforward: explicit `loading()` at the mount site replaces any `loading()` from `handler.use`. The merge order is `handler.use → explicit`, so the explicit one is the last writer and wins.
301
+
302
+ For parallel slots, the shared `parallel(..., () => [...])` callback is **broadcast** to every slot in the call. A single `loading()` placed there lands on every slot, overwriting each slot's `handler.use` default. To scope `loading()` to one slot, use the **slot descriptor** form:
303
+
304
+ ```typescript
305
+ const Cart: Handler = async (ctx) => { /* … */ };
306
+ Cart.use = () => [loader(CartLoader), loading(<CartSkeleton />)];
307
+
308
+ const Notifs: Handler = async (ctx) => { /* … */ };
309
+ Notifs.use = () => [loader(NotifsLoader), loading(<NotifsSkeleton />)];
310
+
311
+ // ✅ @cart gets a custom skeleton; @notifs keeps its handler.use default.
312
+ parallel({
313
+ "@cart": {
314
+ handler: Cart,
315
+ use: () => [loading(<CustomCartSkeleton />)],
316
+ },
317
+ "@notifs": Notifs,
318
+ });
319
+
320
+ // ✅ Opt one slot out of streaming while siblings still stream the broadcast.
321
+ parallel(
322
+ {
323
+ "@cart": { handler: Cart, use: () => [loading(false)] },
324
+ "@notifs": Notifs,
325
+ },
326
+ () => [loading(<BroadcastSkeleton />)],
327
+ );
328
+ ```
329
+
330
+ Per-slot merge order is **handler.use → shared use → slot-local use**. Slot-local is the narrowest scope, so it wins for last-write-wins items like `loading()`. Items that accumulate within the parallel allow-list (`loader`, `revalidate`, `errorBoundary`, `notFoundBoundary`, `transition`) compose across all three layers regardless.
331
+
332
+ Other things to keep in mind about `loading()`:
333
+
334
+ - Any `loading()` (regardless of source) makes the segment a streaming unit. A handler that includes `loading()` in its `.use` opts every mount site into streaming by default. To opt back out, pass `loading(false)` at the mount site (`loading: false` handling in [match-middleware/segment-resolution.ts](../../src/router/match-middleware/segment-resolution.ts)) — use the slot descriptor form for parallel slots so the opt-out doesn't broadcast.
335
+
336
+ Rule of thumb: only put `loading()` in `handler.use` if you genuinely want every mount site to stream by default. Use the slot descriptor's `use` for any per-slot intent at a `parallel()` call.
337
+
338
+ ## Edge cases & gotchas
339
+
340
+ - **ReactNode handlers cannot have `.use`.** A bare JSX element passed as a handler (e.g., `path("/about", <About />)`) has no function to attach properties to. Pass a function or branded definition instead.
341
+ - **Branded handlers** — `Static()`, `Prerender()`, and `Passthrough()` are positional constructors (not object-arg). Construct first, then attach `.use` to the returned definition:
342
+
343
+ ```typescript
344
+ const ProductPage = Prerender(async (ctx) => {
345
+ const product = await fetchProduct(ctx.params.slug);
346
+ return <ProductView product={product} />;
347
+ });
348
+ ProductPage.use = () => [loader(ProductLoader)];
349
+ ```
350
+
351
+ - **Items can be flat or nested arrays.** `handler.use()` results are flattened with `.flat(3)` before validation, so factory helpers that return arrays inline work the same as in regular `use()` callbacks.
352
+ - **Validation runs at registration / first match**, not at handler definition. A handler doesn't know its mount site at definition time — the same handler used in a `path()` and an `intercept()` is validated against each mount's allowed-types set when registered.
353
+ - **No silent shadowing.** If a disallowed item slips through (e.g., a layout factory returning `cache()` from a slot's `handler.use`), the runtime throws with the offending type and mount site named.
354
+
355
+ ## Cross-references
356
+
357
+ - `skills/route` — `path()` mount site basics
358
+ - `skills/layout` — `layout()` mount site basics
359
+ - `skills/parallel` — parallel slot semantics, slot override rules, streaming behavior
360
+ - `skills/intercept` — intercept mount site basics
361
+ - `skills/loader` — defining `createLoader` and reading via `ctx.use()`
362
+ - `skills/middleware` — middleware semantics and ordering
@@ -311,3 +311,23 @@ export const shopPatterns = urls(({
311
311
  ]),
312
312
  ]);
313
313
  ```
314
+
315
+ ## Handler-attached `.use`
316
+
317
+ Intercept handlers can carry their own middleware, loaders, loading state, error/notFound boundaries, and even nested `layout`/`route`/`when` defaults via `.use` — useful for self-contained modal components that travel with their own data and chrome.
318
+
319
+ ```typescript
320
+ const QuickViewModal: Handler = async (ctx) => {
321
+ const product = await ctx.use(ProductLoader);
322
+ return <QuickView product={product} />;
323
+ };
324
+ QuickViewModal.use = () => [
325
+ loader(ProductLoader),
326
+ loading(<QuickViewSkeleton />),
327
+ layout(<ModalChrome />),
328
+ ];
329
+
330
+ intercept("@modal", "product", QuickViewModal);
331
+ ```
332
+
333
+ Explicit `use()` at the mount site merges with `handler.use` (handler defaults first, explicit second). See [skills/handler-use](../handler-use/SKILL.md) for merge order and the per-mount-site allowed-types table.
@@ -308,3 +308,25 @@ export const shopPatterns = urls(({ path, layout, parallel, loader, revalidate }
308
308
  ]),
309
309
  ]);
310
310
  ```
311
+
312
+ ## Handler-attached `.use`
313
+
314
+ Layout handlers can carry their own middleware, default parallels, and includes via `.use` so a layout becomes a self-contained unit reusable across mount sites.
315
+
316
+ ```typescript
317
+ const AdminLayout: Handler = (ctx) => {
318
+ const user = ctx.get(CurrentUser);
319
+ return <Admin user={user} />;
320
+ };
321
+ AdminLayout.use = () => [
322
+ middleware(requireAdmin),
323
+ parallel({ "@adminNotifs": AdminNotifsSlot }),
324
+ ];
325
+
326
+ // Mount site declares structure only; defaults travel with the layout.
327
+ layout(AdminLayout, () => [
328
+ path("/admin", AdminIndex, { name: "admin.index" }),
329
+ ]);
330
+ ```
331
+
332
+ Allowed item types in a layout's `.use` mirror the layout `use()` callback (the broadest set). Explicit `use()` at the mount site merges with `handler.use` (handler defaults first, explicit second). See [skills/handler-use](../handler-use/SKILL.md) for merge order and per-mount-site allowed types.
@@ -137,17 +137,46 @@ export const urlpatterns = urls(({ path, layout, middleware }) => [
137
137
  ## Middleware with Multiple Handlers
138
138
 
139
139
  ```typescript
140
- // Spread multiple middleware from a single export
140
+ // Group multiple middleware in an array
141
141
  export const shopMiddleware = [loggerMiddleware, mockAuthMiddleware];
142
142
 
143
- // In routes
143
+ // In routes — pass the array directly
144
144
  layout(<ShopLayout />, () => [
145
- middleware(...shopMiddleware),
145
+ middleware(shopMiddleware),
146
146
 
147
147
  path("/shop", ShopIndex, { name: "shop" }),
148
148
  ])
149
149
  ```
150
150
 
151
+ ## Wrapping Middleware (Scoped to Children)
152
+
153
+ Use the wrapping form to scope middleware to a subset of routes without
154
+ introducing a visible layout:
155
+
156
+ ```typescript
157
+ urls(({ path, middleware }) => [
158
+ // authMw only applies to /admin and /admin/settings
159
+ middleware(authMw, () => [
160
+ path("/admin", AdminPage, { name: "admin" }),
161
+ path("/admin/settings", SettingsPage, { name: "settings" }),
162
+ ]),
163
+
164
+ // Public route — no authMw
165
+ path("/", HomePage, { name: "home" }),
166
+ ]);
167
+ ```
168
+
169
+ Multiple middleware with wrapping:
170
+
171
+ ```typescript
172
+ middleware([authMw, loggingMw], () => [
173
+ path("/admin", AdminPage, { name: "admin" }),
174
+ ]);
175
+ ```
176
+
177
+ This creates a transparent layout (`<Outlet />`) that carries the middleware.
178
+ The middleware does not affect sibling routes outside the callback.
179
+
151
180
  ## Middleware Context
152
181
 
153
182
  ```typescript