create-slot

Features declare what they render. Layouts decide where it appears.

A feature contributes UI to a named slot. A layout mounts a host for that slot and gets every contribution, in order, with its own props. Neither side imports the other, and nothing is drilled through the tree to connect them.

npm install create-slot

See it work

Toggle a feature. It is mounted somewhere else entirely — the sidebar never imports it, and it never imports the sidebar. The host renders its own children until something is contributed, and every contributed item reads the host's live props.

import { createSlot } from "create-slot"
 
export const Slots = {
  Menu: createSlot<{ current: string }>(),
}
 
export function Sidebar({ current }: { current: string }) {
  return (
    <nav>
      <ul>
        <li>Home</li>
        <Slots.Menu.Host current={current}>
          <li>Nothing installed yet</li>
        </Slots.Menu.Host>
      </ul>
    </nav>
  )
}
 
export function PricingFeature() {
  return (
    <Slots.Menu order={10}>
      <PricingNavItem />
    </Slots.Menu>
  )
}
 
function PricingNavItem() {
  const { current } = Slots.Menu.useProps()
 
  return (
    <li aria-current={current === "/pricing" ? "page" : undefined}>Pricing</li>
  )
}

Two channels

A contribution can be registered in two ways, and the difference is what a contribution is.

Each channel keeps its own hosts — the registry never merges fills — and a single application uses both: the registry for anything that must be in the HTML, the façade for chrome that depends on live tree state. Two channels is the whole comparison, with the decision written out.

The declarative half of the same idea — a named slot, a plugin that declares a contribution under an id, one resolvePlugins call, and a provider the application mounts once:

// slots.ts — pure data, importable from server modules too
import { defineSlot } from "create-slot/core"
 
export const NavMenu = defineSlot<{ current: string }>("nav-menu")
export const StatusBar = defineSlot("status-bar")
 
 
// plugins/pricing.tsx
import { definePlugin } from "create-slot/core"
 
export const pricing = definePlugin({
  id: "pricing",
  contributes: [
    // "nav-item" is the contribution's id: required, unique inside the plugin.
    // The full id is "pricing/nav-item" — the React key and override target.
    NavMenu.contribute("nav-item", { order: 10, component: PricingNavItem }),
  ],
})
 
function PricingNavItem({ current }: { current: string }) {
  // An ordinary component: hooks, context, data fetching, all of it.
  if (current === "/checkout") {
    return null
  }
 
  return <li>Pricing</li>
}
 
 
// app.tsx
import { resolvePlugins, SlotHost, SlotProvider } from "create-slot"
 
// One pure function turns the plugin list into a Resolution. Resolve at
// module scope or in a `useMemo` — the provider never rebuilds anything.
const resolution = resolvePlugins([pricing])
 
export function App({ route }: { route: string }) {
  return (
    <SlotProvider resolution={resolution}>
      <ul>
        <SlotHost slot={NavMenu} props={{ current: route }}>
          <li>No plugins installed</li>
        </SlotHost>
      </ul>
    </SlotProvider>
  )
}

The Resolution is plain data, and resolvePlugins is React-free — a server component can resolve the graph and hand it across the RSC boundary whole.

What it does not do

The library knows who contributes what, in what order, and what happens when a contribution breaks. Everything else is yours:

• No when predicate. A contribution returns null.
• No exclusive slots and no routing. "Exactly one owner" is a table your application resolves before render, where it can report the plugin it refused.
• No inventory helper. The manifest is data, so an inventory is a .map.
• No state, no lifecycle, no command registry. The manifest is open data you extend with your own fields, and they keep their types.

Zero dependencies, two entry points — one of them React-free — and any React with useSyncExternalStore: 18 and up.

Where to go next

1. Get started — a first contribution in three steps.
2. Slots, hosts & fills — the four words this library uses, and what each one does.
3. Plugin registry — the declarative channel end to end, and what you need for server rendering.
4. API — every export, with the types twoslash infers from the published package.