npm - @rsc-kit/mcp - Versions diffs - 0.14.0 → 0.16.0 - Mend

@rsc-kit/mcp 0.14.0 → 0.16.0

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 (52) hide show

package/dist/answers.d.ts +7 -0
package/dist/answers.js +28 -0
package/dist/answers.js.map +1 -1
package/dist/bundleGuides.d.ts +27 -0
package/dist/bundleGuides.js +138 -0
package/dist/bundleGuides.js.map +1 -0
package/dist/index.js +21 -1
package/dist/index.js.map +1 -1
package/dist/recipes.js +138 -17
package/dist/recipes.js.map +1 -1
package/dist/report.d.ts +13 -0
package/dist/report.js +1 -1
package/dist/report.js.map +1 -1
package/guides/api-routes.md +168 -0
package/guides/authorization.md +288 -0
package/guides/caching.md +57 -0
package/guides/coming-from-next.md +151 -0
package/guides/connection.md +98 -0
package/guides/edge-caching.md +159 -0
package/guides/errors.md +109 -0
package/guides/file-uploads.md +119 -0
package/guides/fonts.md +117 -0
package/guides/forms.md +528 -0
package/guides/getting-started.md +132 -0
package/guides/images.md +83 -0
package/guides/index.json +187 -0
package/guides/installation.md +338 -0
package/guides/introduction.md +119 -0
package/guides/mcp.md +113 -0
package/guides/metadata.md +289 -0
package/guides/navigation.md +84 -0
package/guides/no-javascript.md +76 -0
package/guides/offline.md +215 -0
package/guides/ppr.md +181 -0
package/guides/pwa.md +260 -0
package/guides/queries.md +340 -0
package/guides/quick-start.md +99 -0
package/guides/react-compiler.md +153 -0
package/guides/redirects.md +143 -0
package/guides/response-headers.md +66 -0
package/guides/route-interception.md +206 -0
package/guides/routing.md +458 -0
package/guides/sections.md +74 -0
package/guides/server-actions.md +444 -0
package/guides/static-generation.md +347 -0
package/guides/testing.md +158 -0
package/guides/third-party-scripts.md +105 -0
package/guides/typed-routes.md +139 -0
package/guides/url-validation.md +143 -0
package/guides/validation.md +175 -0
package/guides/view-transitions.md +120 -0
package/package.json +4 -3

package/guides/introduction.md ADDED Viewed

@@ -0,0 +1,119 @@
+# Introduction
+> React Server Components as a Vite plugin, deployed wherever you like.
+`rsc-kit` is a Vite plugin that gives you React Server Components. You write
+pages, layouts and server actions the way you would in the Next.js App Router;
+it renders them, streams the HTML, and turns links into navigations that replace
+only the part of the page that changed.
+It brings no build system of its own — it is a Vite plugin — and it does not
+write a server for you either. [Nitro](https://nitro.build) builds one around
+your route tree, so where an app runs is a preset: Bun, Node, a Cloudflare
+Worker, Vercel, Netlify, Deno.
+## What an app looks like
+```text
+src/app/
+  layout.tsx         the document — <html>, <head>, <body>
+  loading.tsx        Suspense fallback for everything below
+  page.tsx           GET /
+  posts/
+    [slug]/
+      page.tsx       GET /posts/:slug
+  @modal/
+    default.tsx      a parallel slot, empty until something fills it
+```
+Nothing registers those files. The plugin reads the directory at build time and
+generates the entry that knows about them.
+```tsx title="src/app/posts/[slug]/page.tsx"
+import { findPost } from '../../../data'
+export default async function PostPage({ params }: { params: Promise<{ slug: string }> }) {
+  const { slug } = await params
+  const post = await findPost(slug)
+  if (!post) return <h1>No such post</h1>
+  return (
+    <article>
+      <h1>{post.title}</h1>
+      <p>{post.body}</p>
+    </article>
+  )
+}
+```
+A server component is an ordinary async function. It imports its data module
+directly, and neither the module nor its secrets reach the browser.
+## What you get
+<CardGrid>
+  <Card title="Streaming, not waterfalls" icon="ph:waves">
+    The shell paints before the data resolves. Suspense boundaries fill in as
+    they finish, in whatever order they finish.
+  </Card>
+  <Card title="Navigations that keep the page" icon="ph:arrows-left-right">
+    A navigation sends the layout chain it already has, and the server answers
+    with only the part that changed. Scroll, focus and half-typed forms survive.
+  </Card>
+  <Card title="Parallel routes and interception" icon="ph:frame-corners">
+    `@slot` directories render alongside the page. `(.)folder` opens a route as
+    a modal over the page you were on, and as a real page on refresh.
+  </Card>
+  <Card title="Server actions" icon="ph:lightning">
+    `"use server"` makes an async function callable from a client component.
+    The body never ships; the call becomes one POST.
+  </Card>
+  <Card title="Queries, without an endpoint" icon="ph:magnifying-glass">
+    `query()` marks a read. It travels as a GET, so it can be cached and
+    prefetched — and reads that happen together leave as one request.
+  </Card>
+  <Card title="Frozen where it can be" icon="ph:snowflake">
+    Pages that ask for nothing dynamic are rendered at build time. Pages that do
+    get their shell frozen and their data streamed.
+  </Card>
+  <Card title="An export target" icon="ph:folder-open">
+    The same app can build to a directory of files and be served by anything —
+    including a CDN with no origin at all.
+  </Card>
+</CardGrid>
+## Where it runs
+You do not write a server. [Nitro](https://nitro.build) builds one from your
+route tree, and where it runs is one line in your Vite config:
+```ts title="vite.config.ts"
+nitro({ preset: 'bun' })
+```
+Swap the preset for `node`, `cloudflare_module`, `vercel`, `netlify` or `deno`
+and the same app deploys there instead. The build produces a `.output`
+directory; nothing else changes.
+## What it is not
+<Aside type="note" title="No data layer, no CSS pipeline, no dev server of its own">
+  The build runs your project's Vite config, so Tailwind, PostCSS and the rest
+  are configured the way they are in any Vite app. Data access is an import.
+  There is no `getServerSideProps` equivalent, and no request context to learn.
+</Aside>
+## Where to go next
+<CardGrid>
+  <Card title="Getting started" icon="ph:play">
+    [Build and deploy your first app →](/getting-started)
+  </Card>
+  <Card title="Routing" icon="ph:tree-structure">
+    [Pages, layouts, slots and navigation →](/guides/routing)
+  </Card>
+  <Card title="How it works" icon="ph:gear">
+    [What happens between a request and a page →](/reference/how-it-works)
+  </Card>
+</CardGrid>

package/guides/mcp.md ADDED Viewed

@@ -0,0 +1,113 @@
+# Working with an AI agent
+> An MCP server that answers from your actual build, and the AGENTS.md written into every project.
+Two things ship for this, and they do different jobs.
+`AGENTS.md` is written into your project by the scaffold. It is short on
+purpose — it sits in an agent's context on every turn, so it states the rules
+and nothing more.
+The **MCP server** is for everything that does not fit in that budget: what your
+build actually did, and the long-form answer to "how do I do X here".
+## Connecting it
+The scaffold already did. Every project gets a `.mcp.json` at its root:
+```json title=".mcp.json"
+{
+  "mcpServers": {
+    "rsc-kit": { "command": "npx", "args": ["-y", "@rsc-kit/mcp"] }
+  }
+}
+```
+Claude Code reads that as project-scoped configuration and asks you to approve
+it the first time it starts the server. Nothing is installed until then, and
+nothing about your build or dev server changes — it is a file an agent reads.
+Commit it; it is the same for everyone on the project.
+For a project that predates the file, `create-rsc-kit init` writes it (and
+leaves one that is already there alone), or add it by hand:
+```sh
+claude mcp add rsc-kit -- npx -y @rsc-kit/mcp
+```
+Any other MCP client takes the same entry — a stdio server, command `npx`,
+arguments `-y @rsc-kit/mcp` — in its own file: `.cursor/mcp.json` under
+`mcpServers`, `.vscode/mcp.json` under `servers`.
+## What it answers about your app
+Every build writes `build-report.json` — the same rows it printed, plus every
+server action and whether a client built it. These read
+it, so nothing runs a build or imports your code:
+| tool | answers |
+| --- | --- |
+| `list_routes` | every route, what happened to it, what it ships |
+| `explain_route` | why one url is stored or rendered per request |
+| `what_is_dynamic` | the routes that are not stored, with reasons |
+| `heaviest_routes` | what costs the browser most |
+The reason a page is dynamic is **recorded, not guessed**:
+```
+/locale — a stored shell, with the rest rendered per request (from the last build, 5 minutes ago)
+Rendered by app/locale/page.
+Ships 85 kB of javascript, gzipped.
+Why it is not stored whole: dynamic — called cookies(), headers()
+```
+That matters more than it sounds. Asked to "make this page faster", an agent
+without this guesses at a cause and edits something. With it, the call that did
+it is on the screen.
+## What it answers about the framework
+| tool | answers |
+| --- | --- |
+| `list_topics` | every topic it can explain |
+| `how_to` | the short answer: forms, prefetch, validation, the action client, data with TanStack Query or SWR, Suspense, offline, pwa, no-javascript, api routes, authorization, why a page is dynamic |
+| `list_guides` | every guide on this site, one line each |
+| `read_guide` | the full text of one, exactly as published here — bundled with the server, so it matches the version installed |
+| `search_guides` | every line in the guides mentioning a word, with the guide it is in |
+`how_to` is the opinionated summary an agent should read first; `read_guide`
+is for when the summary is not enough. Both come from the same source, and the
+guides are copied in at build time, so what an agent reads is what this site
+says for the version it has.
+These exist because the patterns here differ from Next and plain React **in
+ways that compile either way** — a check written in the component instead of the
+action, a hand-parsed query string, `"use server"` at the top of a page. An
+agent that has not been told writes those confidently.
+## Two things worth knowing
+**Every answer says how old it is.** It reports the last build, and your files
+may have changed since — so `(from the last build, 5 minutes ago)` is on every
+response. With no build at all it says to run one, rather than reporting that
+there are no routes.
+**It is read-only.** Nothing here edits, builds or deploys. Your agent already
+has a shell for those, and a server that can change a project is one that can
+change it while answering a question about it.
+## The docs are markdown too
+Every page on this site is also a markdown file at the same url with
+`index.md` added — `/guides/forms/index.md` — and
+[`/llms.txt`](/llms.txt) is an index of all of them, with
+[`/llms-full.txt`](/llms-full.txt) as one document. An agent without the MCP
+server, or one asked about a version other than the one installed, reads
+those. `read_guide` is the same text, offline, at the installed version.
+## Without an agent
+`build-report.json` is an ordinary file. A CI step can assert on it — that
+nothing stopped being prerendered, that no route crossed a size budget — which
+is the check most likely to catch a regression nobody would otherwise see.

package/guides/metadata.md ADDED Viewed

@@ -0,0 +1,289 @@
+# Page metadata
+> Titles, descriptions and Open Graph tags, exported from the page.
+Titles and meta tags are exported by the page that needs them. There is no
+document template to edit and nothing to register — React hoists the resulting
+elements into `<head>`, so they stream with the page rather than waiting for
+it.
+## Static metadata
+```tsx title="src/app/about/page.tsx"
+export const metadata: Metadata = {
+  title: 'About us',
+  description: 'Learn more about our team.',
+  keywords: ['about', 'team', 'company'],
+  openGraph: {
+    title: 'About us',
+    description: 'Learn more about our team.',
+  },
+};
+export default function AboutPage() {
+  return <h1>About us</h1>;
+}
+```
+`Metadata` is imported from the package:
+```tsx
+import type { Metadata } from '@rsc-kit/core/metadata';
+```
+It used to be ambient, written into your project by the build. An import
+resolves as soon as dependencies are installed, where a generated file does not
+exist until something has been built once — so a freshly cloned project no
+longer reports an error on every page it has not built yet.
+:::tip[Custom meta tags go under `other`]
+```tsx
+export const metadata: Metadata = {
+  title: 'Pricing',
+  other: { 'fb:app_id': '1234', 'theme-color': '#111' },
+};
+```
+The named keys are a closed set on purpose. When any key was legal, a typo like
+`titel` was accepted in silence — and your editor offered no completions at
+all.
+:::
+## Metadata from data
+When the values depend on what the page loaded, export `generateMetadata`. It
+receives the route params:
+```tsx title="src/app/posts/[slug]/page.tsx"
+import { findPost } from '../../../data';
+export const generateMetadata: GenerateMetadata<{ slug: string }> = async ({ params }) => {
+  const { slug } = await params;
+  const post = await findPost(slug);
+  return {
+    title: post.title,
+    description: post.excerpt,
+    openGraph: { title: post.title, description: post.excerpt, images: post.cover },
+  };
+};
+export default async function PostPage({ params }: { params: Promise<{ slug: string }> }) {
+  const { slug } = await params;
+  const post = await findPost(slug);
+  return <h1>{post.title}</h1>;
+}
+```
+It receives the same `params` and `searchParams` a page does, so there is one
+shape to learn rather than two. Unlike a page's, these always resolve — a
+`<title>` has no fallback, so there is nothing to suspend into.
+Metadata always resolves against the **full** layout chain, even when the
+render is partial. A navigation that replaces one segment still produces the
+same `<title>` a full load would, because the template on the outer layout is
+consulted either way.
+## Title templates
+A layout can define the shape every title beneath it takes. `%s` stands in for
+the page's own title:
+```tsx title="src/app/layout.tsx"
+export const metadata: Metadata = {
+  title: {
+    template: '%s | Acme',
+    default: 'Acme',
+  },
+  description: 'The Acme dashboard.',
+};
+```
+```tsx title="src/app/settings/page.tsx"
+export const metadata: Metadata = { title: 'Settings' };
+// <title>Settings | Acme</title>
+```
+The nearest layout with a template wins, so a nested layout can override the
+one above it. A page that exports no title gets the `default`.
+## Supported keys
+| Key | Becomes |
+| --- | --- |
+| `title` | `<title>` — a string on a page, a template on a layout |
+| `description` | `<meta name="description">` |
+| `keywords` | `<meta name="keywords">`, joined with commas if you pass an array |
+| `author` | `<meta name="author">` |
+| `robots` | `<meta name="robots">` |
+| `metadataBase` | nothing itself — it is what makes every relative url below absolute |
+| `openGraph` | `<meta property="og:…">`, one per field; each image brings its size and alt |
+| `twitter` | `<meta name="twitter:…">` |
+| `icons` | `<link rel="icon">`, `apple-touch-icon` and so on |
+| `other` | `<meta name="…">`, or `property=` for an `og:`/`fb:`/`article:` key |
+| anything else | `<meta name="…">` |
+`keywords` takes either form — `'react, rsc'` and `['react', 'rsc']` produce
+the same tag.
+The flat spellings — `'og:title'`, `'twitter:card'` — still work and render
+correctly, but the structured objects are the ones to write: they are typed,
+they take an image object with a width and height, and they are what a Next
+app already has.
+## The share card
+```tsx title="src/app/layout.tsx"
+export const metadata: Metadata = {
+  metadataBase: new URL('https://remorva.com'),
+  openGraph: {
+    siteName: 'Remorva',
+    type: 'website',
+  },
+  twitter: {
+    card: 'summary_large_image',
+    site: '@remorva',
+  },
+};
+```
+```tsx title="src/app/posts/[slug]/page.tsx"
+export async function generateMetadata({ params }): Promise<Metadata> {
+  const post = await findPost((await params).slug);
+  return {
+    title: post.title,
+    openGraph: {
+      title: post.title,
+      description: post.excerpt,
+      url: `/posts/${post.slug}`,
+      images: [{ url: post.cover, width: 1200, height: 630, alt: post.title }],
+    },
+  };
+}
+```
+Layouts merge outward-in, so `metadataBase`, `siteName` and the card type are
+set once and every page gets them.
+:::caution[`metadataBase` is not optional in production]
+A share-card scraper needs an **absolute** image url. Facebook, Slack and
+LinkedIn all refuse a relative one, silently — the link unfurls with no image
+and nothing says why.
+Set `metadataBase` on the root layout and every relative `url`, image and icon
+below it is made absolute. Without it, an `opengraph-image.png` in `app/` goes
+out as `/_app/opengraph-image.png`, which works in a browser and nowhere else.
+It is the same name as Next's, so a port carries it across unchanged.
+:::
+`og:` tags render with `property=` and `twitter:` with `name=`, because that is
+what each scraper reads. It is worth stating because it is easy to get
+backwards, and a tag with the wrong attribute is not an error — it is a card
+that never shows.
+## Icons
+A string, a list, or a categorised object:
+```tsx
+// One favicon
+export const metadata: Metadata = { icons: '/favicon.ico' };
+// Several, with attributes
+export const metadata: Metadata = {
+  icons: [
+    { url: '/favicon.ico', sizes: '32x32' },
+    { url: '/icon-192.png', sizes: '192x192', type: 'image/png' },
+  ],
+};
+// By role
+export const metadata: Metadata = {
+  icons: {
+    icon: '/favicon.ico',
+    apple: '/apple-touch-icon.png',
+    other: { rel: 'mask-icon', url: '/safari-pinned-tab.svg', color: '#5bbad5' },
+  },
+};
+```
+Each descriptor takes `url`, `type`, `sizes`, `color`, `rel`, `media` and
+`fetchPriority`.
+## How it reaches the document
+```text
+Build     the plugin finds the metadata exports and generates a resolver
+Render    the resolver runs alongside the page, against the full layout chain
+Load      React hoists <title> and <meta> into <head> as they are emitted
+Navigate  the resolved metadata rides on the X-RSC-Meta header, and the
+          client updates document.title and the tags in place
+```
+The last line is why a title is correct after an SPA navigation without the
+page having been re-rendered from the root.
+## Icons and share images
+Put them in `src/app/` and the build finds them. There is nothing to register
+and no layout to edit:
+| file | what it becomes |
+| --- | --- |
+| `favicon.ico` | served at `/favicon.ico` |
+| `icon.png`, `icon-192.png`, `icon-512.png` | `<link rel="icon">`, and the [manifest](/guides/offline/)'s icons |
+| `apple-icon.png` | `<link rel="apple-touch-icon">` |
+| `opengraph-image.png` | `<meta property="og:image">` |
+| `twitter-image.png` | `<meta name="twitter:image">`, with the large-card type |
+The names are Next's. There is nothing to gain from inventing different ones —
+an app moving between the two should not have to rename its favicon.
+**Sizes are read from the filename**, so `icon-192.png` needs no entry anywhere
+saying it is 192 pixels. Which is why a manifest usually lists no icons at all:
+```ts title="src/app/manifest.ts"
+export default {
+  name: 'Orders',
+  themeColor: '#0b0b0c',
+  // icons omitted — the build uses the icon-*.png beside this file
+} satisfies WebManifest
+```
+Listing them as well would be the same set written twice, and the copy that
+goes stale is the one nobody looks at.
+### Why `app/` and not `public/`
+`public/` means "serve this file unchanged". These are *read* as well as
+served: an icon's filename decides what goes in the manifest, and its presence
+decides what goes in the head. A file whose name the build interprets belongs
+with the other files whose names the build interprets.
+They are copied into the build output under `/_app/`, so they never collide
+with something you put in `public/` yourself. The favicon is the exception —
+it is served at `/favicon.ico`, because browsers ask for that url whatever the
+markup says.
+:::note[Set `metadataBase`]
+The image is emitted as `/_app/opengraph-image.png`, which a scraper will not
+fetch. With `metadataBase` on the root layout it goes out absolute — see [the
+share card](#the-share-card) above.
+:::
+### Not `opengraph-image.tsx`
+Next also accepts a *component* by that name and renders it to a PNG at build
+time. This package does not, on purpose. Rendering an image means bundling a
+layout engine and a rasteriser — a couple of megabytes of dependencies, and
+seconds added to every build for every image — for a picture that changes
+when the design does, which is to say rarely.
+Make the image once with whatever you like, and commit the file. If a page
+needs a *different* image per record — a card for each post — that is an
+[api route](/guides/api-routes/) that returns one, cached, and the
+`openGraph.images` url points at it. Neither touches the build.

package/guides/navigation.md ADDED Viewed

@@ -0,0 +1,84 @@
+# Navigation
+> What happens when someone clicks a link, and why state survives it.
+`Link` does not reload the page. It asks the server for the part of the tree
+that actually changed, and swaps it in.
+```tsx
+import Link from '@rsc-kit/core/Link'
+<Link href="/about">About</Link>
+```
+## What a navigation actually sends
+Going from `/posts/one` to `/posts/two`, the root layout and the posts layout
+are already mounted and identical. The client says which layouts it holds, the
+server compares that with the new route's chain, and answers with the deepest
+piece that differs — the page alone.
+You get this for free. There is nothing to configure and no `loading` prop to
+thread.
+Two things follow from it, and they are the reason it works this way:
+**State above the swap survives.** A sidebar's scroll position, an open menu, a
+half-typed form in a layout — none of it is touched, because none of it was
+re-rendered.
+**A page you return to is still there.** Recently visited pages are kept mounted
+and hidden rather than thrown away, so going back restores a half-filled form
+exactly as you left it. Only a handful are kept, ordered by last visit.
+## Programmatic navigation
+```tsx
+'use client'
+import { visit, prefetch } from '@rsc-kit/core/router'
+<button onClick={() => visit('/checkout')}>Checkout</button>
+```
+Links prefetch on hover already. `prefetch` is for when you know where someone
+is going before they hover:
+```tsx
+useEffect(() => { prefetch('/step-2') }, [])
+```
+## Showing progress
+```tsx
+'use client'
+import { useLinkStatus } from '@rsc-kit/core/useLinkStatus'
+function Spinner() {
+  const { pending } = useLinkStatus()
+  return pending ? <span>Loading…</span> : null
+}
+```
+A `loading.tsx` beside a page is shown while that page's data resolves:
+```tsx title="src/app/posts/loading.tsx"
+export default function Loading() {
+  return <p>Loading posts…</p>
+}
+```
+## Refreshing the current page
+```tsx
+'use client'
+import { refresh } from '@rsc-kit/core/router'
+<button onClick={() => refresh()}>Reload</button>
+```
+Scroll positions are restored afterwards — the window's and any element with
+its own overflow, such as a sidebar.

package/guides/no-javascript.md ADDED Viewed

@@ -0,0 +1,76 @@
+# A page with no JavaScript
+> Rendering a route to HTML and stopping there.
+Some pages have nothing to hydrate. A marketing page, a changelog, an article.
+For those, shipping React is paying about 70 kB gzipped for nothing — so the
+build does not.
+## It is automatic
+A route that freezes whole, renders **no client component** of yours, and has
+**no server action** in its tree is stored without the bootstrap script. No
+React, no Flight client, no router. The build says so:
+```
+  ○  /about    no js
+     no client components, so ships no javascript
+```
+Nothing to declare. The check is made on the rendered tree, not the source,
+so a client component reached through a shared layout counts — which is why
+most pages in an app with a `<Link>` in its header keep the runtime, and a
+route group with its own plain layout can drop it.
+The line is drawn at what the runtime would *do*. A client component needs
+hydrating. A `<form action={serverFn}>` written in a server component needs
+React to submit it. A `<Suspense>` hole that was not filled at build time
+needs the client to fill it, which is why only a route stored whole
+qualifies. Everything else — anchors, styles, a third-party `<script>` — works
+the same with or without.
+Navigation is unchanged in both directions. A page with no client component
+has no `<Link>`, so its anchors were already full loads. A `<Link>` elsewhere
+that points *at* it still fetches its flight payload and swaps the segment,
+because that payload is still written from the render with the runtime.
+## Declaring it
+To force it on, for a page that renders a client component you are content
+to leave inert:
+```tsx title="src/app/about/page.tsx"
+export const clientJs = false
+```
+A page stored this way still registers the [service worker](/guides/offline)
+when the app has one: the runtime's one-line registration is inlined in its
+place, so a visitor who lands here first gets the worker the second visit is
+for. What such a page cannot show is the update prompt, which is a client
+component. To keep the runtime on a page the build would otherwise strip, say
+so:
+```tsx
+export const clientJs = true
+```
+## What stops working when you declare it
+With `clientJs = false`, anything interactive stops working, which is why the
+build refuses the combination rather than shipping it:
+```
+app/about/page.tsx declares clientJs = false but renders client components:
+  src/components/Counter.tsx
+```
+That is a build failure, not a warning. A client component with no runtime is
+inert markup — a button that does nothing — and it is usually inherited from a
+shared layout rather than written on the page, so the message names the
+components responsible.
+## It cannot be a PPR route
+With no client runtime there is nothing to fill a Suspense hole after the
+shell arrives. A `clientJs = false` route should be fully static: fetch what it
+needs at build time and freeze the whole page.