Slots

A slot is a named extension point. One plugin defines it; others contribute into it as plain data, with no import between them.

// shell/admin defines it
export const SIDEBAR_NAV_SLOT = createSlot<NavItem>('sidebar.nav');

// any plugin contributes
slots: [
    {
        slot: SIDEBAR_NAV_SLOT,
        items: [{ id: 'reviews', label: 'Reviews', to: '/reviews', order: 40 }]
    }
];

Contributions are wired once at boot and read sorted by whoever renders them.

The catalogue

The app shell

Inside a workspace

The content library

Elsewhere

Two examples of what this buys

The rich-text editor is a slot contribution. The wysiwyg plugin contributes one item to ENTRY_FIELD_CONTROL_SLOT, and that is its entire surface — no route, no navigation entry, no page. It appears everywhere an entry form does without knowing about any of them.

The Insights dashboard ships no widgets. It provides the frame and defines the slots; content, media and localization each fill them. A dashboard is the module most likely to slowly become the one that knows about every other one, and the slot is what prevents it.

Slots are boot-frozen

Contributions are registered once at boot. Nothing adds or removes an item at runtime.

That constraint is what makes an item safe to expose a hook that the render site calls in a loop: the set of items cannot change between renders, so calling a hook per item does not violate the rules of hooks.

Gate on the item, and again inside

An item carries a permission, and the component checks it too.

The duplication is deliberate: the renderer has to know whether a section has any visible items before it draws that section’s heading, or a user without the permission gets a heading over nothing.

Defining your own

export const REVIEWS_PANEL_SLOT = createSlot<ReviewsPanel>('reviews.panel');

Export the token from your package index so another plugin can import it, and document the item shape. An item is data — an id, an order, a permission, and a zero-prop component that reads what it needs.