@rangojs/router 0.0.0-experimental.8 → 0.0.0-experimental.80

package/skills/cache-guide/SKILL.md

@@ -0,0 +1,294 @@
+---
+name: cache-guide
+description: When to use cache() DSL vs "use cache" directive — key differences and decision guide
+argument-hint:
+---
+
+# cache() vs "use cache" — When to Use Which
+
+Both mechanisms share the same backing store, cache profiles, and tag-based
+invalidation. They differ in scope, cache key, execution model, and runtime control.
+
+## Key Differences
+
+|                      | `cache()` DSL                                         | `"use cache"` directive                            |
+| -------------------- | ----------------------------------------------------- | -------------------------------------------------- |
+| **Scope**            | Route segment tree (handler + children + parallels)   | Single function return value                       |
+| **Defined at**       | Route definition site (`urls.ts`)                     | Inside function body or at file top                |
+| **Cache key**        | Request type + pathname + params (+ optional custom)  | Function identity + serialized non-tainted args    |
+| **Execution on hit** | All-or-nothing: entire handler skipped                | Partial: function body skipped, calling code runs  |
+| **Runtime control**  | `condition` to disable, custom `key` function         | None — if the directive is present, it caches      |
+| **Side effects**     | No guards needed — handler doesn't run on hit         | `ctx.header()`, `ctx.set()`, etc. throw at runtime |
+| **Handle data**      | Captured and replayed                                 | Captured and replayed                              |
+| **Loaders**          | Always fresh — excluded from cache, opt-in per loader | Can be used inside loaders                         |
+| **Nesting**          | Nest `cache()` boundaries with different TTLs         | Compose by calling cached functions from uncached  |
+
+### cache() Cache Key
+
+The key is `{requestType}:{pathname}:{params}` where requestType is one of
+`doc:`, `partial:`, or `intercept:`. This means the same URL cached separately
+for full document loads, client navigations, and intercept navigations.
+
+Custom `key` functions can segment the cache further (e.g., by user role or locale).
+`condition` can disable caching entirely at runtime (e.g., skip for authenticated users).
+
+### "use cache" Cache Key
+
+The key is `use-cache:{functionId}:{serializedArgs}` where functionId is a stable
+ID from the Vite transform (module path + export name) and args are serialized via
+RSC `encodeReply()`. Tainted arguments (ctx, env, req) are excluded.
+
+## Execution Model
+
+This is the most important distinction.
+
+### cache() — all-or-nothing
+
+On cache hit, the cache-lookup middleware short-circuits the entire pipeline.
+No handler code runs. On miss, all handlers execute normally and segments are
+stored.
+
+```
+HIT  → cached segments served, loaders resolved fresh, no handler runs
+MISS → all handlers run, segments cached, response built normally
+```
+
+Headers, cookies, and ctx.set() calls inside handlers naturally don't execute on
+hit. There is no partial execution, so no runtime guards are needed.
+
+### "use cache" — partial execution
+
+Only the wrapped function body is skipped on hit. The code that calls the
+cached function still runs. This means ctx side effects inside the cached body
+would silently disappear on hit.
+
+```
+HIT  → function body skipped, calling code runs, handle data replayed
+MISS → function body runs, return value + handle data cached
+```
+
+Runtime guards throw if you call cookies(), headers(), ctx.header(), ctx.set(),
+ctx.onResponse(), ctx.setTheme(), or ctx.setLocationState() inside a "use cache"
+function. cookies() and headers() are blocked because per-request data is not in the
+cache key. Side-effect methods are blocked because their effects are lost on hit.
+Use ctx.use(Handle) instead for data — handle data is captured and replayed.
+
+## When to Use cache()
+
+Use the route-level `cache()` DSL when:
+
+- **Caching entire routes or sections** — wrap a set of paths with one TTL.
+- **You need runtime control** — disable caching for authenticated users with
+  `condition`, or segment cache keys by user/locale with `key`.
+- **UI rendering is expensive** — the cached segments include the rendered
+  component tree, skipping RSC rendering on hit.
+- **You want one cache entry per URL** — keyed on pathname + params, not on
+  function arguments.
+
+```typescript
+export const urlpatterns = urls(({ path, cache }) => [
+  cache({ ttl: 300, condition: (ctx) => !ctx.get("user") }, () => [
+    path("/blog", BlogIndex, { name: "blog" }),
+    path("/blog/:slug", BlogPost, { name: "blogPost" }),
+  ]),
+]);
+```
+
+## When to Use "use cache"
+
+Use the `"use cache"` directive when:
+
+- **Caching a specific data fetch** — one database query used across multiple
+  routes or components.
+- **Different call sites need different cache entries** — the cache key includes
+  all non-tainted arguments, so `getProduct("a")` and `getProduct("b")` cache
+  separately.
+- **Fine-grained caching within a handler** — cache the expensive part, keep
+  ctx side effects outside.
+- **Caching an RSC component** — a component that fetches its own data can cache
+  its entire render.
+
+```typescript
+async function getProductData(slug: string) {
+  "use cache: short";
+  return await db.query("SELECT * FROM products WHERE slug = ?", [slug]);
+}
+
+// Handler calls cached function, sets headers outside
+async function ProductPage(ctx) {
+  const data = await getProductData(ctx.params.slug);
+  ctx.header("X-Product", data.id);
+  return <Product data={data} />;
+}
+```
+
+## Combining Both
+
+They compose naturally. Use `cache()` for the route boundary and `"use cache"`
+for shared data functions:
+
+```typescript
+// urls.tsx — route-level cache for the rendered segment tree
+cache({ ttl: 60 }, () => [
+  path("/product/:slug", ProductPage, { name: "product" }),
+]);
+
+// data.ts — function-level cache for the database query
+export async function getProductData(slug: string) {
+  "use cache: long";
+  return await db.query("SELECT * FROM products WHERE slug = ?", [slug]);
+}
+```
+
+On cache hit for the route, the handler doesn't run and `getProductData` is never
+called. On cache miss, the handler runs and `getProductData` may itself return a
+cached value from a previous call with the same slug.
+
+## Headers and Cookies
+
+Neither mechanism caches response headers or cookies.
+
+- **cache()**: Headers set by handlers are naturally absent on hit because no
+  handler runs. If you need headers on every response, set them in middleware
+  (which runs before cache lookup).
+- **"use cache"**: cookies() and headers() throw inside the cached function
+  (both reads and writes). ctx.header() also throws. Move them outside.
+
+```typescript
+// Set headers that must appear on every response in middleware
+middleware(async (ctx, next) => {
+  ctx.header("X-Frame-Options", "DENY");
+  await next();
+});
+```
+
+## Context Variable Cache Safety
+
+Context variables created with `createVar()` are cacheable by default and can
+be read freely inside `cache()` and `"use cache"` scopes. Non-cacheable vars
+throw at read time to prevent request-specific data from being captured.
+
+There are two ways to mark a value as non-cacheable:
+
+```typescript
+// Var-level policy — inherently request-specific data
+const Session = createVar<SessionData>({ cache: false });
+
+// Write-level escalation — this specific write is non-cacheable
+ctx.set(Theme, derivedTheme, { cache: false });
+```
+
+"Least cacheable wins": if either the var definition or the `ctx.set()` call
+specifies `cache: false`, the value is non-cacheable.
+
+**Behavior inside cache scopes:**
+
+| Operation                           | Inside `cache()` / `"use cache"` |
+| ----------------------------------- | -------------------------------- |
+| `ctx.get(cacheableVar)`             | Allowed                          |
+| `ctx.get(nonCacheableVar)`          | Throws                           |
+| `ctx.set(var, value)` (cacheable)   | Allowed                          |
+| `ctx.header()`, `ctx.cookie()`, etc | Throws (response side effects)   |
+
+Write is dumb — `ctx.set()` stores the cache metadata but does not enforce.
+Enforcement happens at read time (`ctx.get()`), where ALS detects the cache
+scope and rejects non-cacheable reads.
+
+## Loaders Are Always Fresh
+
+Loaders are **never cached** by route-level `cache()`. Even on a full cache hit
+where all UI segments are served from cache, loaders are re-resolved fresh on
+every request. This is enforced at two levels:
+
+1. **Storage**: `cacheRoute()` filters out loader segments before serialization
+   (`segments.filter(s => s.type !== "loader")`).
+2. **Retrieval**: On cache hit, `resolveLoadersOnly()` runs after yielding cached
+   UI segments, ensuring fresh data regardless of cache state.
+
+This means `cache()` gives you cached UI + fresh data by default. To also cache
+a loader's data, explicitly opt in with `loader(Fn, () => [cache({...})])`.
+
+## cache() Placement Patterns
+
+### Wrapping children of a path
+
+An orphan `cache()` inside a path's children becomes the parent for all
+subsequent siblings. Everything below the cache boundary is cached as one unit:
+
+```typescript
+path("/dashboard", DashboardPage, { name: "dashboard" }, () => [
+  cache("long"),
+  layout(DashboardSidebar, () => [
+    parallel("@stats", StatsPanel),
+    parallel("@activity", ActivityFeed),
+  ]),
+]),
+```
+
+On hit: DashboardPage, DashboardSidebar, StatsPanel, and ActivityFeed are all
+served from cache. On miss: all handlers run, all segments cached together.
+
+### Uncached layout with cached children
+
+The cache boundary only covers what's inside it. Parent segments above the
+boundary are not cached and always re-render:
+
+```typescript
+layout(RootLayout, () => [
+  // RootLayout is NOT cached — runs every request
+  path("/products/:slug", ProductPage, { name: "product" }, () => [
+    cache("long"),
+    layout(ProductSidebar),
+    parallel("@reviews", ReviewsPanel),
+    parallel("@related", RelatedProducts),
+  ]),
+]),
+```
+
+RootLayout renders fresh every request. ProductPage, ProductSidebar,
+ReviewsPanel, and RelatedProducts are all inside the cache boundary and
+served from cache on hit. This is useful when the root layout depends on
+request-specific data (user session, theme) but the product content is
+cacheable.
+
+### Loader-level caching
+
+Loaders are excluded from route-level `cache()` by default — they always
+resolve fresh. To opt a specific loader into caching, give it its own
+`cache()` child:
+
+```typescript
+path("/product/:slug", ProductPage, { name: "product" }, () => [
+  // This loader is cached for 5 minutes
+  loader(ProductLoader, () => [cache({ ttl: 300 })]),
+
+  // This loader is always fresh
+  loader(CartLoader),
+]),
+```
+
+This attaches the cache config directly to the loader entry. The loader's
+data is cached independently from the route's segment cache. Loader caching
+supports custom keys, tags, SWR, conditional bypass, and per-loader store
+overrides — see `/loader` for the full reference.
+
+## Decision Flowchart
+
+1. Do you want to cache an entire route or group of routes?
+   **Yes** -> `cache()`
+2. Do you need runtime conditions (skip for auth users, key by locale)?
+   **Yes** -> `cache()` with `condition` / `key`
+3. Do you want to cache a data fetch shared across routes?
+   **Yes** -> `"use cache"`
+4. Do you need different cache entries for different arguments?
+   **Yes** -> `"use cache"` (keyed by args)
+5. Is the expensive part rendering, not data fetching?
+   **Yes** -> `cache()` (caches rendered segments)
+6. Is the expensive part a single query inside a larger handler?
+   **Yes** -> `"use cache"` on the query function
+
+## See Also
+
+- `/caching` — cache() DSL setup, stores, nested boundaries
+- `/use-cache` — "use cache" directive details, profiles, transforms, guards
+- `/document-cache` — Edge caching with Cache-Control headers (different layer)

package/skills/caching/SKILL.md

@@ -30,14 +30,45 @@ export const urlpatterns = urls(({ path, cache }) => [
 ## Cache Options
 
 ```typescript
-cache({
-  ttl: 60,      // Time-to-live in seconds (default: 60)
-  swr: 300,     // Stale-while-revalidate window (default: 300)
-}, () => [
-  // Cached routes
-])
+cache(
+  {
+    ttl: 60, // Time-to-live in seconds (default: 60)
+    swr: 300, // Stale-while-revalidate window (default: 300)
+  },
+  () => [
+    // Cached routes
+  ],
+);
+```
+
+## Named Profile Shorthand
+
+Use a named cache profile string instead of an options object. The profile must be
+defined in `createRouter({ cacheProfiles })`. Unknown names throw at boot time.
+
+```typescript
+// Define profiles in router
+createRouter({
+  cacheProfiles: {
+    default: { ttl: 900, swr: 1800 },
+    short: { ttl: 60, swr: 120 },
+    long: { ttl: 3600, swr: 7200 },
+  },
+});
+
+// Use by name in urls
+export const urlpatterns = urls(({ path, cache }) => [
+  cache("long", () => [path("/blog", BlogIndex, { name: "blog" })]),
+
+  // Also works without children (orphan cache boundary)
+  cache("short"),
+  path("/feed", FeedPage, { name: "feed" }),
+]);
 ```
 
+These profile names are shared with the `"use cache: <name>"` directive. See
+`/use-cache` for function-level caching.
+
 ## Loader-Level Caching
 
 Cache individual loaders:
@@ -45,13 +76,11 @@ Cache individual loaders:
 ```typescript
 path("/product/:slug", ProductPage, { name: "product" }, () => [
   // Cache this loader's results
-  loader(ProductLoader, () => [
-    cache({ ttl: 300 }),
-  ]),
+  loader(ProductLoader, () => [cache({ ttl: 300 })]),
 
   // This loader is not cached
   loader(CartLoader),
-])
+]);
 ```
 
 ## Global Cache Configuration
@@ -60,7 +89,7 @@ Configure a cache store in the router:
 
 ```typescript
 import { createRouter } from "@rangojs/router";
-import { MemorySegmentCacheStore } from "@rangojs/router/rsc";
+import { MemorySegmentCacheStore } from "@rangojs/router/cache";
 
 const store = new MemorySegmentCacheStore({
   defaults: { ttl: 60, swr: 300 },
@@ -83,34 +112,75 @@ const router = createRouter({
 For single-instance deployments:
 
 ```typescript
-import { MemorySegmentCacheStore } from "@rangojs/router/rsc";
+import { MemorySegmentCacheStore } from "@rangojs/router/cache";
 
 const store = new MemorySegmentCacheStore({
   defaults: { ttl: 60, swr: 300 },
-  maxSize: 1000,  // Max entries
+  maxSize: 1000, // Max entries
 });
 ```
 
-### Cloudflare KV Store
+### Cloudflare Edge Cache Store
 
-For distributed caching on Cloudflare Workers:
+For distributed caching on Cloudflare Workers using the Cache API:
 
 ```typescript
-import { CFCacheStore } from "@rangojs/router/cache/cf";
+import { CFCacheStore } from "@rangojs/router/cache";
 
-const router = createRouter({
+const router = createRouter<AppBindings>({
+  document: Document,
+  urls: urlpatterns,
+  cache: (env, ctx) => ({
+    store: new CFCacheStore({
+      ctx,
+      defaults: { ttl: 60, swr: 300 },
+    }),
+    enabled: true,
+  }),
+});
+```
+
+### With KV L2 Persistence
+
+Add a KV namespace for global cross-colo persistence. On Cache API miss, KV is
+checked and hits are promoted back to L1. Writes go to both layers.
+
+```typescript
+import { CFCacheStore } from "@rangojs/router/cache";
+
+const router = createRouter<AppBindings>({
   document: Document,
   urls: urlpatterns,
-  cache: (env) => ({
+  cache: (env, ctx) => ({
     store: new CFCacheStore({
-      kv: env.Bindings.CACHE_KV,
-      waitUntil: (fn) => env.ctx.waitUntil(fn),
+      ctx,
+      kv: env.CACHE_KV, // optional KV namespace binding
+      defaults: { ttl: 60, swr: 300 },
     }),
     enabled: true,
   }),
 });
 ```
 
+**How the two layers work:**
+
+| Scenario     | L1 (Cache API) | L2 (KV) | Result                        |
+| ------------ | -------------- | ------- | ----------------------------- |
+| Hot request  | HIT            | —       | Serve from L1 (fast)          |
+| Cold colo    | MISS           | HIT     | Serve from KV, promote to L1  |
+| First render | MISS           | MISS    | Render, write to both L1 + KV |
+
+KV entries require `expirationTtl >= 60s`. Short-lived entries (< 60s total TTL)
+are only cached in L1.
+
+## Context Variables Inside Cache Boundaries
+
+Context variables (`createVar`) are cacheable by default and can be read and
+written inside `cache()` scopes. Variables marked with `{ cache: false }` (at
+the var level or write level) throw when read inside a cache scope. Response
+side effects (`ctx.header()`, `ctx.cookie()`) always throw inside cache
+boundaries. See `/cache-guide` for the full cache safety table.
+
 ## Nested Cache Boundaries
 
 Override cache settings for specific sections:
@@ -124,7 +194,7 @@ cache({ ttl: 300 }, () => [
   cache({ ttl: 30 }, () => [
     path("/blog/:slug", BlogPost, { name: "blogPost" }),
   ]),
-])
+]);
 ```
 
 ## Custom Cache Store
@@ -139,14 +209,14 @@ const checkoutCache = new MemorySegmentCacheStore({
 // In urls
 cache({ store: checkoutCache }, () => [
   path("/checkout", CheckoutPage, { name: "checkout" }),
-])
+]);
 ```
 
 ## Complete Example
 
 ```typescript
 import { urls } from "@rangojs/router";
-import { MemorySegmentCacheStore } from "@rangojs/router/rsc";
+import { MemorySegmentCacheStore } from "@rangojs/router/cache";
 
 // Custom store for checkout (short TTL)
 const checkoutCache = new MemorySegmentCacheStore({

package/skills/composability/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: composability
+description: Reusable composition patterns with globally importable route helpers in @rangojs/router
+argument-hint: "pattern-name"
+---
+
+# Composability
+
+Route helpers can be imported directly from `@rangojs/router` and used to build reusable composition factories. This enables sharing common route configurations across multiple routes and modules.
+
+## Globally Importable Helpers
+
+These helpers can be imported and called outside the `urls()` callback parameter:
+
+```typescript
+import {
+  layout,
+  cache,
+  middleware,
+  revalidate,
+  loader,
+  loading,
+  parallel,
+  intercept,
+  when,
+  errorBoundary,
+  notFoundBoundary,
+} from "@rangojs/router";
+```
+
+They work because they use AsyncLocalStorage internally and resolve context at call time, not import time.
+
+## Why path() and include() Are Not Global
+
+`path()` and `include()` remain exclusive to the `urls()` callback:
+
+```typescript
+urls(({ path, include }) => [
+  path("/blog", BlogPage, { name: "blog" }),
+  include("/shop", shopPatterns, { name: "shop" }),
+]);
+```
+
+They define the route structure -- the URL patterns and how modules compose. Keeping them in the `urls()` callback makes the route tree readable at a glance. When scanning a URL file, `path()` and `include()` calls show what renders where. Moving them into factories would hide the routing structure and make it harder to understand which URLs exist and how they nest.
+
+The globally importable helpers (`cache`, `middleware`, `loading`, etc.) are configuration -- they modify behavior of routes but don't define routes themselves. Extracting them into factories doesn't obscure the route structure.
+
+## Composition Factories
+
+Define reusable factories that return arrays of use items:
+
+```typescript
+import { cache, revalidate, loading, errorBoundary, middleware } from "@rangojs/router";
+
+// Shared caching configuration
+const withCaching = () => [
+  cache({ ttl: 600_000 }),
+  revalidate(({ actionId }) => !!actionId),
+];
+
+// Shared loading and error handling
+const withLoadingAndError = (skeleton: ReactNode) => [
+  loading(skeleton),
+  errorBoundary(() => <div>Something went wrong</div>),
+];
+
+// Shared auth middleware
+const withAuth = () => [
+  middleware(authMiddleware),
+  middleware(loggingMiddleware),
+];
+```
+
+## Using Factories in Routes
+
+Place factory calls inside `path()` or `layout()` use callbacks. The returned arrays are flattened automatically (up to 3 levels):
+
+```typescript
+import { urls } from "@rangojs/router";
+import { withCaching, withLoadingAndError, withAuth } from "./route-config";
+
+export const urlpatterns = urls(({ path, layout }) => [
+  layout(<AppLayout />, () => [
+    withAuth(),
+
+    path("/blog", BlogIndex, { name: "blog" }, () => [
+      withCaching(),
+      withLoadingAndError(<BlogSkeleton />),
+    ]),
+
+    path("/shop", ShopIndex, { name: "shop" }, () => [
+      withCaching(),
+      withLoadingAndError(<ShopSkeleton />),
+    ]),
+  ]),
+]);
+```
+
+## Sharing Across Modules
+
+Factories can be defined in shared modules and reused across separate `urls()` definitions:
+
+```typescript
+// src/route-config.ts
+import { cache, revalidate, middleware } from "@rangojs/router";
+import { authMiddleware } from "./middleware/auth";
+
+export const withPublicDefaults = () => [
+  cache({ ttl: 300 }),
+  revalidate(({ actionId }) => !!actionId),
+];
+
+export const withProtectedDefaults = () => [
+  middleware(authMiddleware),
+  cache({ ttl: 60 }),
+];
+```
+
+```typescript
+// src/urls/blog.ts
+import { urls } from "@rangojs/router";
+import { withPublicDefaults } from "../route-config";
+
+export const blogPatterns = urls(({ path }) => [
+  path("/", BlogIndex, { name: "index" }, () => [withPublicDefaults()]),
+]);
+```
+
+```typescript
+// src/urls/admin.ts
+import { urls } from "@rangojs/router";
+import { withProtectedDefaults } from "../route-config";
+
+export const adminPatterns = urls(({ path }) => [
+  path("/", AdminDashboard, { name: "index" }, () => [withProtectedDefaults()]),
+]);
+```
+
+## Composition Types
+
+For typed factories, import the composition types:
+
+```typescript
+import type { RouteUseItem, LayoutUseItem, UseItems } from "@rangojs/router";
+
+// Factory for path() use callbacks
+const withCaching = (): RouteUseItem[] => [
+  cache({ ttl: 600_000 }),
+];
+
+// Factory for layout() use callbacks
+const withAuth = (): LayoutUseItem[] => [
+  middleware(authMiddleware),
+];
+
+// Factory that nests other factories (use UseItems for nested arrays)
+const withEverything = (): UseItems<RouteUseItem> => [
+  withCaching(),
+  loading(<Skeleton />),
+];
+```
+
+- `RouteUseItem[]` -- flat array for `path()` use callbacks
+- `LayoutUseItem[]` -- flat array for `layout()` use callbacks
+- `UseItems<T>` -- allows nested arrays from composing factories together
+
+## Rules
+
+- Helpers execute lazily -- factory functions are defined anywhere, but only called inside a `urls()` context (within `path()` or `layout()` use callbacks)
+- Calling helpers outside a `urls()` context throws an error
+- Nested arrays from factories are flattened automatically via `.flat(3)`
+- `path()` and `include()` cannot be used in factories -- they define route structure and must remain visible in the `urls()` callback