Page component slots

Built-in pages own their queries, route lifecycle, authorization and loading boundaries. Use StackProvider.overrides[pluginId].pageOverrides[pageKey] to replace a supported presentation component within a page.

Page keys follow the client route keys listed below. They are not URL paths or the shorter names accepted by some plugins' pageComponents configuration. TypeScript checks both page keys and component props.

Change one page

import type { JobBoardPluginOverrides } from "@btst/plugin-job-board/client";

const jobBoard = {
  pageOverrides: {
    jobBoardList: {
      JobRow: ({ job }) => (
        <li>
          <h2>{job.title}</h2>
          <p>{job.department} · {job.location}</p>
        </li>
      ),
    },
  },
} satisfies JobBoardPluginOverrides;

<StackProvider stack={clientStack} router={router} overrides={{ jobBoard }}>
  {children}
</StackProvider>

The main Job Board list uses this row. The department list keeps its built-in row because jobBoardDepartment has no override. A replacement receives the documented presentation props; include any links or controls that your replacement needs, using your application's navigation adapter.

Resolution and compatibility

For each supported slot, resolution is:

pageOverrides[pageKey][slot]
  ?? compatible existing shared override
  ?? built-in component

Blog's shared PostCard is one example of the middle fallback. The other slots introduced in this rollout have no compatible shared component override and fall back directly to their built-in component. No new shared override is required.

Built-in pages supply scope explicitly. Reusable components rendered without a page scope keep their shared/default behavior; the current URL does not select an override. Scope is a component prop, not a global context inferred from the route. Existing content slots, localization, styling and whole-page pageComponents replacements continue to work. Ejected views retain their existing composition; regenerated registry views include the explicit scope wiring, while existing copies only use it if their code opts in.

The framework router stays on StackProvider.router. These slots do not change loaders, query keys, authorization checks, route hooks or SSR/hydration behavior.

Plugin audit

The audit covers the first-party plugins present on main when issue #373 was implemented, including Notifications and Ecommerce. Each plugin guide documents its slot prop types and examples. Pages without slots retain their existing configuration; no arbitrary internal component tree is exposed.