Intro to the Lightning Component Library: Stop Guessing at Component Attributes

At some point every LWC developer does the same thing: types lightning-input into a template, guesses at an attribute name based on vibes, saves, and watches nothing happen. The fix isn't trial and error. It's one page you should have open in a tab every time you build a component — the Lightning Component Library.

What the Component Library Actually Is

The Lightning Component Library, at developer.salesforce.com/docs/component-library, is Salesforce's official reference for every base Lightning component available to you — both the older Aura versions and the current LWC versions. For each component it gives you a live, interactive preview, a full attributes table, every event the component fires, and code examples you can copy directly into your own template. It is not a tutorial. It's a specification — the single source of truth for what a component can and can't do.

This matters because base Lightning components are not arbitrary HTML tags you can decorate however you like. Each one is a pre-built, Salesforce-maintained component with a fixed, documented contract. If an attribute isn't listed on that component's page, it doesn't exist for that component — no amount of typing it into your markup will make it work.

How to Actually Browse It

The library is organized around two tabs: Components and UI Guidelines. You'll live in the Components tab. Components are grouped by category — Action, Data, Form, Layout, Navigation, Media, and so on — and each one has its own page with a consistent structure: a live preview at the top you can interact with directly in the browser, then an Attributes section, then a Details section covering events and slots, then code examples at the bottom.

The search bar at the top of the library is faster than browsing categories once you know roughly what you're looking for. Searching "button" surfaces lightning-button, lightning-button-icon, lightning-button-menu, and every other button variant in one list, with a one-line description of what makes each one different.

Reading a Component Spec Properly

Take lightning-input as an example. Its Attributes table lists things like label, type, value, required, disabled, and max-length — each with its expected data type and a short description of what it does. This table is what you check before writing markup, not after something fails to render correctly.

<lightning-input
  label="Deal Name"
  type="text"
  value={dealName}
  required
  max-length="80"
  onchange={handleChange}>
</lightning-input>

The Details section below the attributes table covers events — for lightning-input, that's mainly onchange, which fires with the current value in event.target.value. Knowing which event a component fires, and what data lands on that event, is exactly as important as knowing its attributes. Guessing at event names is the second most common cause of "my handler never runs."

The Base Components You'll Use Constantly

A small handful of base components cover most of what you'll build in your first few months of LWC work:

• lightning-button and lightning-button-icon — every clickable action in a Lightning screen, from form submission to row-level actions in a table.
• lightning-input — the standard form field for text, number, date, checkbox, and more, all through the same component with a different type attribute.
• lightning-datatable — the default way to render a list of records as an interactive, sortable table, with support for inline editing and row actions.
• lightning-card — the standard container for grouping related content, with a built-in title, icon slot, and footer slot.
• lightning-record-edit-form and lightning-record-view-form — record-bound forms that read your object's field-level security and layout automatically, without you writing a single SOQL query.

You will not memorize every attribute of every one of these on day one, and you don't need to. What you need is the habit of checking the library's page for the exact component you're using before you guess.

Where This Fits Into What You're Building Next

Nearly everything you'll build as an LWC developer is composition — taking base components like the ones above and arranging them inside your own custom template, wiring their events to your own JavaScript logic. The Component Library is the reference for the half of that equation Salesforce already built for you. The next thing to get comfortable with is the other half: the core LWC building blocks — decorators, wire adapters, and component composition patterns — which is exactly where this series goes next.

For now, the habit that actually matters: before you write a line of markup for a base component you haven't used before, open its page in the library first. It costs thirty seconds and saves the hour you'd otherwise spend debugging an attribute that was never real.