LWC Slots — Complete Guide

Posted by Vinay Vernekar 7th December 2025

A practical guide to using slots in Lightning Web Components (LWC). Learn unnamed and named slots, examples, best practices, and when to use them for flexible, reusable components.

What are slots in LWC?

Slots are placeholders in a child component template that let parent components inject content. They enable content projection so you can build flexible, reusable UI primitives like cards, modals, and layout containers without hard-coding child content.

Types of slots

There are two main types:

  • Unnamed (default) slot — accepts any content passed without a slot name.
  • Named slot — identified with a name attribute to allow multiple distinct insertion points.

Unnamed slot example

Child component (card) with a default slot where any parent markup is projected:

// cardComponent.js
import { LightningElement } from 'lwc';

export default class CardComponent extends LightningElement {}

Named slot example (modal)

Use named slots to provide header, body, and footer regions that parents can override:

// modalComponent.js
import { LightningElement, api } from 'lwc';

export default class ModalComponent extends LightningElement {
  @api title = 'Modal Title';
  @api isOpen = false;

  handleClose() {
    this.dispatchEvent(new CustomEvent('close'));
  }
}

Accessing slotted content in JS

To detect whether a slot contains content, query the slot and use assignedElements():

get hasHeaderSlot() {
  const slot = this.template.querySelector('slot[name="header"]');
  return slot && slot.assignedElements().length > 0;
}

Best practices

  • Use named slots for clearly defined content areas (header, footer, sidebar).
  • Provide default content inside slots so the component is resilient when no content is passed.
  • Keep slot names descriptive and limited in number — don’t overuse slots.
  • Don’t rely on slotted content for critical component logic; treat it as presentation/content projection.
  • Handle empty slots gracefully with conditional rendering if needed.

Common use cases

  • Layout components — headers, sidebars, footers.
  • Cards — title, body, actions slots for flexible card composition.
  • Modals/dialogs — header/body/footer slots for custom controls.
  • Lists/tables — custom row templates and action areas.
  • Forms — dynamic or optional field sections.

Key takeaways

  • Slots promote composition over inheritance and increase reusability.
  • Slotted content maintains the parent context, so styles and event listeners from the parent behave as expected.
  • Use slots to separate structure from content while keeping components flexible.

Why this matters: Slots let Salesforce developers and admins build reusable UI primitives that can be composed in many ways without rewriting child components. For teams, this reduces duplication, speeds development, and makes maintenance easier.

Further reading: